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
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
网络安全功能接口（I2NSF）：问题陈述和用例
Abstract
摘要
This document sets out the problem statement for Interface to Network Security Functions (I2NSF) and outlines some companion use cases.
本文档阐述了网络安全功能接口（I2NSF）的问题陈述，并概述了一些配套用例。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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].
本文档阐述了网络安全功能接口（I2NSF）的问题陈述，并概述了一些用例。[I2NSF-ANALYSIS]中记录了与I2NSF工作相关的行业和IETF的最新技术状态摘要。
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.
据[Gartner]称，对托管（或基于云的）安全服务的需求正在增长。中小型企业（SMB）越来越多地采用基于云的安全服务来取代内部部署的安全工具，而大型企业正在部署传统安全服务和基于云的安全服务的混合。
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.
为了满足需求，越来越多的服务提供商正在提供托管安全解决方案，以向企业客户提供经济高效的托管安全服务。托管安全服务主要针对企业（尤其是中小型企业），但也可以提供给任何类型的大众市场客户。因此，网络安全功能（NSF）可以在各种各样的环境中提供和使用。NSF的用户可以使用由一个或多个提供商托管的网络安全服务，这些提供商可以是他们自己的企业、服务提供商或两者的组合。
This document also briefly describes the following use cases summarized by [I2NSF-USECASES]:
本文档还简要描述了[I2NSF-USECASES]总结的以下用例：
o I2NSF Access Use Cases [OAM-USECASE],
o I2NSF访问用例[OAM-USECASE]，
o I2NSF Data Center Use Cases [DC-USECASE], and
o I2NSF数据中心用例[DC-USECASE]，以及
o Integrated Security with Access Network Use Case [ACCESS-USECASE].
o 与接入网络用例集成的安全性[Access-USECASE]。
AAA: Authentication, Authorization, and Accounting [RFC2904]
AAA：身份验证、授权和记帐[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
I2NSF：网络安全功能接口
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.
NSF：网络安全功能。NSF是用于确保网络通信的完整性、机密性或可用性的功能；检测不需要的网络活动；或者阻止，或者至少减轻不必要活动的影响。
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.)
基于流的NSF：根据安全策略检查网络流的NSF。基于流的安全性还意味着按照数据包接收的顺序检查数据包，并且不会由于检查过程（例如，媒体访问控制（MAC）重写、TTL减量操作或NAT检查或更改）而改变数据包。（注意：一些现有防火墙存储数据包，并按逻辑顺序查看数据包，而不是按时间接收数据包的顺序。本文档将基于流的NSF限制在此定义中。）
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.
安全服务提供商：使用从供应商处购买或由服务提供商创建的NSF设备向客户（最终用户或企业）提供安全服务的提供商。
SDN: Software-Defined Networking. (See [RFC7426] for architecture and terminology or [RFC7149] for a service provider view.)
SDN：软件定义的网络。（架构和术语请参见[RFC7426]，服务提供商视图请参见[RFC7149]）
vCPE: virtual Customer Premises Equipment
虚拟客户场所设备
vEPC: virtual Evolved Packet Core [EPC-3GPP]
vEPC：虚拟演进包核心[EPC-3GPP]
vNSF: Virtual NSF. An NSF that is deployed as a distributed virtual resource.
虚拟国家科学基金会。部署为分布式虚拟资源的NSF。
vPE: virtual Provider Edge
虚拟提供者边缘
VPN: Virtual Private Network
虚拟专用网
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".
安全服务提供商可以是公司内部或外部。例如，大型企业中的内部IT安全组可以充当企业的安全服务提供商。相反，企业可以将所有安全服务外包给外部安全服务提供商。在本文档中，安全服务提供商功能（无论是内部还是外部）将被称为“服务提供商”。
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.
I2NSF工作的目标是解决这些问题和挑战。
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.
国家科学基金有多种类型。不同供应商的NSF可以具有不同的功能和接口。NSF可以部署在给定网络中的多个位置，并且可能具有不同的角色。
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.
外部入侵和攻击保护：此功能的示例包括防火墙/ACL身份验证、IPS、IDS和端点保护。
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.
非军事区（DMZ）中的安全功能：此功能的示例包括防火墙/ACL、IDS/IPS、一个或所有AAA服务、NAT、转发代理和应用程序过滤。这些功能可能在DMZ点的服务器提供商网络中或位于“虚拟”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.
安全网关和VPN集中器：这些功能的示例包括IPsec网关、处理桥接安全VPN的安全VPN集中器以及用于数据流的安全VPN控制器。
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.
鉴于安全功能的多样性、可部署这些功能的环境以及这些功能的不断演变，安全功能的各个方面的标准化具有挑战性，可能不可行。幸运的是，并非所有方面都需要标准化。例如，从I2NSF的角度来看，没有必要标准化每个防火墙的过滤是如何创建或应用的。特定供应商筛选中的某些功能可能是供应商产品独有的，因此无需标准化这些功能。
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.
我们需要一个标准化的接口来控制和监视NSF用来处理通过这些NSF的数据包的规则集。因此，标准化接口将为标准化已建立的安全功能提供动力。
I2NSF may specify some filters, but these filters will be linked to specific common functionality developed by I2NSF in information models or data models.
I2NSF可能会指定一些过滤器，但这些过滤器将链接到I2NSF在信息模型或数据模型中开发的特定通用功能。
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.
由于目前没有广泛接受的NSF行业标准接口，NSF的管理（设备和策略提供、监控等）往往是由产品供应商提供的定制安全管理。因此，这些服务的自动化（如果存在的话）也是定制的。因此，即使在部署安全特性的传统方式中，也存在需要填补的缺口；这将需要来自不同供应商的实现之间的协调。
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.
在缓解安全入侵之前进行监控的一个挑战是，NSF无法监控其无法查看的内容。例如，启用安全功能以缓解入侵（例如，防火墙）必须包括提供监控反馈的机制，以确定入侵已停止。因此，有必要建立一种机制来监控NSF的执行状态，并将其提供给安全和法规遵从性管理工具。此类机制存在于特定于供应商的用于取证和故障排除的网络安全接口中，但行业标准接口可以跨各种NSF提供监控。
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.
欧洲电信标准协会（ETSI）网络功能虚拟化（NFV）计划[ETSI-NFV]为分布式VNSF实施的安全策略带来了新的管理挑战。
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.
vNSF的主机虚拟机（VM）正在创建、移动或停用时，网络连接、接口或通信状态发生变化的风险较高。
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.
随着软件定义网络（SDN）（参见[SDN-SECURITY]）的出现，更多的客户端、应用程序或应用程序控制器需要动态更新NSF强制实施的安全策略。安全服务提供商在收到来自其客户机的安全相关请求后，必须动态更新其决策过程（例如，在NSF资源分配和调用方面）。
Service providers may need to deploy several NSF controllers to control and monitor the NSFs, especially when NSFs become distributed and virtualized.
服务提供商可能需要部署多个NSF控制器来控制和监控NSF，尤其是当NSF变得分布式和虚拟化时。
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.
为了提供有效的安全服务，服务提供商需要激活多个供应商生产的NSF或VNSF中的各种安全功能。即使在一个产品类别（如防火墙）内，不同供应商提供的安全功能也可能具有不同的特性和功能。例如，可以由防火墙设计和激活的过滤器可能支持IPv6，也可能不支持IPv6，具体取决于防火墙技术。
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.
服务提供商的管理系统（或控制器）需要一种方法来检索不同供应商提供的服务功能的功能，以便能够构建有效的安全解决方案。这些服务功能可以以静态方式（例如，文件）或通过访问NSF供应商动态更新的安全功能存储库的接口进行记录。
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.
动态功能注册对于自动化非常有用，因为安全功能可能会受到软件和硬件更新的影响。这些更新可能会对NSF实施的政策产生影响。
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.
如今，供应商没有标准的方法来描述其安全功能的功能。如果没有一个通用的技术框架来描述安全功能的功能，服务提供商就无法自动化不同供应商选择NSF以满足客户安全需求的过程。
The I2NSF work will focus on developing a standard method to describe capabilities of security functions.
I2NSF的工作重点是开发一种标准方法来描述安全功能的能力。
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).
许多安全功能依赖于签名文件或配置文件（例如IPS/IDS签名和DDoS开放威胁信号（DOTS）过滤器）。不同的策略可能需要不同的签名或配置文件。如今，黑名单数据库对所有相关方（攻击者除外）都是一种有益的策略，但在未来，可能会有开源签名和配置文件作为IDS系统的一部分分发（例如，通过Snort、Suricata、Bro和Kismet）。
There is a need to have a standard envelope (i.e., a message format) to allow NSFs to use external profiles.
需要有一个标准信封（即消息格式），以允许NSF使用外部配置文件。
3.1.8. Lack of Mechanisms to Accept External Alerts to Trigger Automatic Rule and Configuration Changes
3.1.8. 缺少接受外部警报以触发自动规则和配置更改的机制
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.
NSF可以要求I2NSF安全控制器更改特定规则和/或配置。例如，分布式拒绝服务（DDoS）警报可能会触发对路由系统的更改，以将流量发送到流量清理服务以缓解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防护分为两部分：a）开放威胁的信令配置和b）DDoS缓解。DOTS控制器管理DDoS的信令部分。I2NSF控制器将控制对受影响策略的任何更改（例如，转发和路由、筛选等）。通过监测有关DDoS攻击的网络警报（例如，来自DOTS服务器或客户端），I2NSF控制器可以向警报分析引擎发送警报，该引擎可以识别攻击，以便I2NSF可以实施适当的策略。
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.
如果提供商的网络安全控制器能够监控、分析和调查异常事件，并向客户提供信息或自动更改网络配置，则DDoS抵御功能将得到增强。
[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.
[CAP-INTERFACE]提供了有关基于流量的网络安全功能（NSF）的监控方面如何使用I2NSF接口接收流量报告和实施适当策略的详细信息。
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.
需要一个控制器来创建、管理和分发各种密钥到分布式NSF。虽然有许多密钥管理方法和加密套件（例如，加密算法、密钥派生函数等）以及其他功能，但缺乏提供和管理安全关联的标准接口。
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]).
密钥可用于消息认证和完整性，以保护数据流。此外，密钥可用于保护核心路由基础设施中的协议和消息（参见[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.
从概念上讲，必须为路由/信令协议定义一个接口，该接口可以a）在使用自动密钥管理时发出请求，b）在密钥表中的密钥可用时通知协议。这种接口的一个潜在用途是在软件定义的网络上管理IPsec安全关联。
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.
1. I2NSF需要设计密钥表抽象、密钥管理协议和路由/其他协议之间的接口，以及可能的其他层的安全协议。
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.
2. 对于每个路由/其他协议，I2NSF需要定义协议如何表示密钥材料和协议独立密钥表抽象之间的映射。如果多个协议共享通用的身份验证机制（例如，TCP身份验证选项[RFC5925]），则相同的映射可用于该机制的所有用途。
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).
3. 自动密钥管理需要通过第1项和第2项提供的抽象密钥服务支持成对密钥和组密钥。NSF内需要与NSF交换数据的I2NSF控制器可以使用单个成对密钥与单个NSF交换数据，或者使用由组安全密钥保护的IP组地址与一组NSF同时交换数据。
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 哪些关键通信将在关键事件期间保留，哪些主机将通过网络继续服务，
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 在DDoS期间，为了请求缓解服务（在DOTS工作组的范围内），将哪些信令信息传递给控制器，
o reporting of attacks to CERT (within the scope of the MILE Working Group), and
o 向CERT报告攻击（在MILE工作组的范围内），以及
o managing network connectivity of systems out of compliance (within the scope of the SACM Working Group).
o 管理不合规系统的网络连接（在SACM工作组的范围内）。
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.
许多大中型企业已经部署了各种本地安全功能，希望继续使用这些功能。这些企业希望将本地安全功能与远程托管的安全功能结合起来，以实现对源自Internet和企业网络的攻击的更高效和即时的对策。
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.
一些企业可能只需要为其远程分支机构提供托管安全服务，而这些分支机构的安全基础设施/功能非常有限。安全解决方案将包括在客户网络和服务提供商网络上部署NSF。
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:
客户可以使用多个服务提供商提供的NSF。客户需要向服务提供商表达他们的安全要求、指导方针和期望。反过来，服务提供商必须将此客户信息转换为客户安全策略和其网络中一组安全功能的相关配置任务。如果没有提供清晰技术特征的标准化接口，服务提供商将面临许多挑战：
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.
没有标准的技术特性、API或接口：即使对于最常见的安全服务，也没有标准的技术特性、API或接口。大多数安全服务只能通过不同的专有接口（如门户或API）以供应商选择的任何格式访问。服务提供商必须使用这些广泛变化的接口和不同的安全设备和安全策略配置模型来处理客户的输入。如果没有标准的界面，新的创新安全产品进入市场会遇到很大的障碍。
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.
缺乏即时反馈：客户可能还需要一种机制来轻松更新/修改他们的安全需求，并在涉及的底层NSF中立即生效。
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.
为了了解标准接口如何帮助实现更快的实现时间周期，让我们考虑一个客户，希望通过防火墙/IPS动态地允许具有特定端口、SRC/DST地址或协议类型的加密流，以便在呼叫期间仅启用加密的视频会议呼叫。如图1所示，如果没有普遍接受的接口，客户将不得不了解特定提供商的防火墙/IPS接口，并以提供商要求的格式发送请求。
+------------+
| Security |
| Management |
| System |
+----||------+
|| Proprietary
|| or I2NSF Standard
Video: ||
Port 10 +--------+
--------| FW/IPS |-------------
Encrypted +--------+
Video Flow
+------------+
| Security |
| Management |
| System |
+----||------+
|| Proprietary
|| or I2NSF Standard
Video: ||
Port 10 +--------+
--------| FW/IPS |-------------
Encrypted +--------+
Video Flow
Figure 1: Example of Non-standard vs. Standard Interface
图1：非标准与标准接口示例
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.
相反，如图1所示，如果存在防火墙/IPS接口标准，客户将能够向安全管理系统发送请求，安全管理将通过I2NSF标准接口发送请求。服务提供商现在可以使用相同的标准接口来表示使用许多供应商的产品实现的防火墙/IPS服务。
3.2.3. Difficulty for Customers to Monitor the Execution of Desired Policies
3.2.3. 客户难以监控所需策略的执行
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
I2NSF工作的目标是提供获取安全服务保障系统所需信息的标准方法
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.
为客户提供有关当前安全系统的评估，并根据今天的信息，使用“假设”方案快速规划未来的安全策略。
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.
如今，NSF中的许多安全功能，如IPS、IDS、DDoS缓解和防病毒，严重依赖于相关的配置文件。如果这些NSF设备具有这些功能的最新配置文件，则NSF设备可以执行更有效的保护。如今，没有标准接口为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.
随着更复杂的威胁出现，保护将取决于企业、供应商和服务提供商是否能够合作开发最佳配置文件；这种合作的一个例子是网络威胁联盟[CTA]。向NSF提供安全配置文件的标准接口应与组织间交换安全配置文件的格式相互配合。
One objective of the I2NSF work is to provide this type of standard interface to security profiles.
I2NSF工作的一个目标是为安全配置文件提供这种类型的标准接口。
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.
在某些情况下，由于资源限制，选定的NSF无法执行安全控制器请求的策略。客户和安全服务提供商应在安全服务开始之前协商适当的资源约束。但是，可能会发生意外事件，导致NSF耗尽这些协商资源。此时，NSF应通知安全控制员分配的资源已用尽。为了支持SDN时代的自动控制，有必要在安全控制器和NSF之间提供一组用于正确通知（以及对该通知的响应）的消息。
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.
如前四小节所述，服务提供商和客户都需要表达策略和配置文件、监控系统、验证安全策略是否已安装在安全域内的NSF中，并为NSF可以安全执行的服务建立限制。本小节和下一小节（第3.6节）将研究两种特定网络场景中发生的情况：a）虚拟和非虚拟NSF上托管的安全设备的多域控制，以及b）软件定义的网络。
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.
托管安全服务可以在虚拟机中实例化NSF，这些虚拟机有时广泛分布在网络中，有时组合在一个设备中，以执行一组用于提供服务的任务。托管安全服务可以在单个服务提供商内连接，也可以通过多个服务提供商连接。要确保客户购买的安全服务遵守客户策略，需要此服务的中央控制器跨NSF上的多个网络（其中一些可能是虚拟机上的虚拟网络）监视和验证此服务。要设置此跨域服务，安全控制器必须能够与其域内和跨域的NSF和/或控制器通信，以协商所需的服务。
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.
确保政策在各个领域的一致实施也是一项挑战。标准数据模型可能有助于解决这一问题。
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.
软件定义的网络通过引入覆盖网络（overlay Networks）来改变数据中心的设计格局，覆盖网络部署在机架顶部（Top-of-Rack，ToR）交换机上，这些交换机连接到虚拟机监控程序。SDN技术旨在提高工作负载管理的灵活性，而不影响应用程序及其工作方式。因此，可以轻松无缝地跨私有云和公共云管理工作负载。SDN技术优化了资源使用，目前已部署在除云基础设施之外的各种网络环境中。然而，这种SDN可能会引发特定的安全问题。例如，安全管理员必须确保无论工作负载的位置如何，都可以实施安全策略，从而引起对SDN计算逻辑向参与NSF发送安全策略设置信息的能力的关注。第二个例子是工作负载迁移到公共云基础设施，这可能会在迁移过程中增加额外的安全要求。
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.
用于监视和控制NSF行为的标准接口是安全服务提供商和企业自动化其安全管理实体使用来自多个供应商的不同NSF的基本构建块。I2NSF可由任何（授权）客户端调用。授权客户端的示例包括上游应用程序（控制器）、编排系统和安全门户。
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:
用户通过特定客户端（例如，客户应用程序、网络服务提供商（NSP）的业务支持系统/运营支持系统（BSS/OSS）或管理平台）请求安全服务，相应的NSP网络实体将根据用户服务请求调用（v）NSF。此网络实体在本文档中表示为安全控制器。上面讨论的实体（客户端、安全控制器和NSF）之间的交互如图2所示：
+----------+
+-------+ | | +-------+
| | Interface 1 |Security | Interface 2 | NSF(s)|
|Client <--------------> <------------------> |
| | |Controller| | |
+-------+ | | +-------+
+----------+
+----------+
+-------+ | | +-------+
| | Interface 1 |Security | Interface 2 | NSF(s)|
|Client <--------------> <------------------> |
| | |Controller| | |
+-------+ | | +-------+
+----------+
Figure 2: Interaction between Entities
图2：实体之间的交互
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.
接口1用于从客户端接收安全需求，并将其转换为NSF可以理解和执行的命令。安全控制器还将安全控制器从NSF收集的NSF安全报告（如统计数据）传回给客户端。接口2用于根据命令与NSF交互（例如，制定/撤销安全策略或分发策略），并收集NSF的状态信息。
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
当用户想要获得安全服务的执行状态时，他们可以从客户端请求NSF状态。安全控制器将通过接口2收集NSF信息，整合信息，并通过接口1向客户提供反馈。这个接口可以
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:
客户可能需要验证NSF的可用性、来源和执行情况。该验证过程，尤其是与vNSFs相关的验证过程，至少包括：
Integrity of the NSF: Ensuring that the NSF is not compromised;
NSF的完整性：确保NSF不受损害；
Isolation: Ensuring the execution of the NSF is self-contained for privacy requirements in multi-tenancy scenarios; and
隔离：确保NSF的执行是独立的，以满足多租户场景中的隐私要求；和
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.
NSF来源：可能需要向客户提供有关NSF来源、状态（例如可用、空闲、停机等）和反馈机制的严格保证，以便客户能够检查给定NSF或NSF集是否正确符合客户的要求和后续配置任务。
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.
为了实现这一点，安全控制器可以收集安全度量并与独立和可信的第三方共享它们（通过接口1），以便允许使用第三方添加的信息对NSF功能进行认证。
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.
这意味着可能有以下两种类型的客户端使用Interface 1：最终用户和受信任的独立第三方。I2NSF工作可确定接口1创建两个子接口以支持这两种类型的客户端。
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.
此场景描述了请求和管理NSP基础设施中托管的安全服务的用户（例如，住宅用户、企业用户、移动用户和管理系统）的用例。鉴于NSP客户基本上是其接入网络的用户，该场景基本上与他们的特征以及VNSF的使用相关。图3显示了不同类型的客户如何通过虚拟访问节点（vCPE、vPE和vEPC）连接到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.
[NFVUC]中用例#7中描述的vCPE需要访问虚拟化模型，该模型包括移动和住宅访问网络，其中运营商可以将安全服务从客户的本地环境（例如，设备或终端）卸载到自己的基础设施。
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.
这些用例通过支持客户和提供商之间或两个业务实体之间的业务通信的自动化接口定义了运营商和vNSFs之间的交互。
Customer + Access + PoP / Data Center
| | +--------+
| ,-----+--. |Network |
| ,' | `-|Operator|
+-------------+ | /+----+ | |Mgmt Sys|
| Residential |-+------/-+vCPE+----+ +--------+
+-------------+ | / +----+ | \ | :
| / | \ | |
+----------+ | ; +----+ | +----+ |
|Enterprise|---+---+----+ vPE+--+----+ NSF| |
+----------+ | : +----+ | +----+ |
| : | / |
+--------+ | : +----+ | / ;
| Mobile |-+-----\--+vEPC+----+ /
+--------+ | \ +----+ | Service /
| `--. | Provider /
| `----+---------..
+ + ^^
||
Service Provider
encompasses
everything
in circle
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
vCPE-虚拟客户场所设备vPE-虚拟提供商边缘vEPC-虚拟演进包核心流行点
Figure 3: NSF and Actors
图3：NSF和参与者
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.
威胁内容管理可能包括识别和阻止来自web内容、邮件或下载文件的恶意活动。威胁管理可能包括识别和阻止僵尸网络或恶意软件。
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.
流安全策略在访问（或隔离）网站或社交媒体应用程序期间识别并阻止恶意活动。企业的托管安全服务可能包括检测和缓解外部和内部威胁。外部威胁可能包括应用程序或网络钓鱼攻击、恶意软件、僵尸网络、DDoS等。
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.
服务提供商：针对保护服务提供商网络免受各种威胁（包括DDoS、僵尸网络和恶意软件）的策略的服务请求。此类政策旨在安全可靠地向各种客户（包括住宅、移动和公司客户）交付内容（如数据、语音和视频）。这些安全策略也被强制执行，以确保多个租户之间的隔离，而不管相应连接服务的性质如何。
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).
移动设备的内容管理包括识别和阻止来自上传/下载的web内容、邮件和文件的恶意活动。基础架构的威胁管理包括检测和删除恶意程序（如僵尸网络、恶意软件和其他造成DDoS攻击的程序）。
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.
一些access客户可能不关心使用哪些NSF来实现他们请求的服务。在这种情况下，提供商网络编排系统可以在内部选择NSF（或VNSF）以强制执行客户端请求的安全策略。
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:
其他访问客户，特别是一些企业客户，可能希望为直接控制目的单独签订专用NSF（最有可能是VNSF）合同。在这种情况下，以下是将VNSF与特定客户关联的步骤：
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部署：部署过程包括在NFV基础设施（NFVI）、NSP管理域内或其他外部域上实例化NSF。在客户可以订阅vNSF中支持的安全服务之前，这是必需的步骤。
vNSF Customer Provisioning: Once a vNSF is deployed, any customer can subscribe to it. The provisioning life cycle includes the following:
vNSF客户资源调配：一旦部署了vNSF，任何客户都可以订阅它。资源调配生命周期包括以下内容：
* Customer enrollment and cancellation of the subscription to a vNSF.
* 客户注册和取消对vNSF的订阅。
* Configuration of the vNSF, based on specific configurations or derived from common security policies defined by the NSP.
* vNSF的配置，基于特定配置或源自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.
* 从清单或描述符中提取的vNSF功能的检索。NSP管理系统可以要求这些信息通过商业渠道向客户提供详细信息。
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.
在数据中心中，出于多种原因，可能需要动态添加或删除防火墙等网络安全机制。这些更改可以由用户明确请求，也可以由用户和服务提供商之间的服务级别协议（SLA）中预先约定的需求级别触发。例如，每当带宽利用率在指定时间段内达到某个阈值时，服务提供商可能需要在一组时间帧内添加更多防火墙容量。这种容量扩展可能会导致在现有计算机上添加新的防火墙实例，或在不同的计算机上提供全新的防火墙实例。
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.
安全服务交付的随需应变、动态性本质上鼓励网络安全“设备”采用软件或虚拟形式，而不是物理设备形式。此要求是提供商方面的问题。防火墙服务的用户对于防火墙服务是否在VM或任何其他形式因素上运行是不可知的（他们应该如此）。事实上，他们甚至可能没有意识到他们的流量穿越了防火墙。
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.
此外，新的防火墙实例需要放置在“正确区域”（域）中。这一问题不仅适用于多租户环境，在多租户环境中，让租户进入正确的域至关重要，而且也适用于由具有自己的服务隔离策略的单个组织拥有和运营的环境。例如，企业可以要求将服务于组织内互联网流量的防火墙与组织间流量分开。另一个例子是IPS/IDS服务，它将投资银行流量与其他数据流量分离，以符合投资银行信息传输的监管限制。
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
由服务提供商运营的云数据中心可以为成千上万的客户提供服务。客户机的计算服务器通常托管在虚拟机上，虚拟机可以部署在位于数据中心不同部分的不同服务器机架上。部署专用物理设备在技术和/或财务上通常不可行
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.
防火墙，以满足每个客户端的安全策略要求，可以是多种多样的。所需要的是能够根据已建立的安全策略和底层网络拓扑为每个客户端的服务器集动态部署虚拟防火墙。图4显示了数据中心内虚拟防火墙的示例拓扑。
---+-----------------------------+-----
| |
+---+ +-+-+
|vFW| |vFW|
+---+ +-+-+
| Client #1 | Client #2
---+-------+--- ---+-------+---
+-+-+ +-+-+ +-+-+ +-+-+
|VM | |VM | |VM | |VM |
+---+ +---+ +---+ +---+
---+-----------------------------+-----
| |
+---+ +-+-+
|vFW| |vFW|
+---+ +-+-+
| Client #1 | Client #2
---+-------+--- ---+-------+---
+-+-+ +-+-+ +-+-+ +-+-+
|VM | |VM | |VM | |VM |
+---+ +---+ +---+ +---+
Figure 4: NSF in Data Centers
图4：数据中心中的NSF
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.
尽管大多数供应商支持类似的防火墙功能，但不同供应商的特定规则配置关键字不同，这使得自动化变得困难。当自动化能够利用多个供应商跨NSF工作的通用标准集并利用动态密钥管理时，它的工作效果最佳。
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
服务提供商运营的云数据中心的客户端需要保护虚拟专用网络（VPN）和应用客户端安全策略的虚拟安全功能。安全策略可以管理客户端自己的虚拟网络内的通信以及与外部网络的通信。例如，VPN服务提供商可能需要向其VPN客户端提供防火墙和其他安全服务。如今，客户通常不可能做到这一点
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.
如上所述，动态密钥管理对于保护VPN和策略分发至关重要。
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.
有许多类型的内部流量监视器可由安全控制器管理。这包括被称为数据丢失预防（DLP）或声誉保护服务（RPS）的服务类别。根据事件的类别，警报可能会发送给内部管理员或外部服务。
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.
在万物相连的互联网上，防止可能导致DoS攻击或DDoS攻击的不必要流量已成为一项挑战。类似地，网络可能暴露于恶意软件攻击，并成为例如通过远程命令危害其他网络操作的攻击向量。许多承载信息组的网络（如物联网（IoT）网络、以信息为中心的网络（ICN）、内容交付网络（CDN）、IP语音（VoIP）分组网络和LTE语音（VoLTE））也面临此类远程攻击。这些网络上有许多远程攻击的例子，但下面的例子将说明这些问题。携带传感器读数和指令的物联网网络上的恶意软件攻击可能试图改变传感器指令，以禁用关键传感器。对VoIP或VoLTE网络的恶意软件攻击涉及试图拨打未经授权的长途电话的软件。僵尸网络可能会覆盖ICN和CDN中的节点，使网络无法传递关键数据。
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.
为了使组织能够更好地保护其网络免受此类攻击，I2NSF框架应该提供一个独立于用例且与技术无关的客户端接口。技术不可知被定义为通用的、独立于技术的，并且能够支持多种协议和数据模型。例如，这样的I2NSF接口可用于提供安全策略配置信息，以查找特定的恶意软件签名。类似地，通过使用I2NSF客户端接口提供安全策略，可以很容易地防止僵尸网络攻击，该接口阻止访问僵尸网络命令和控制服务器。
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.
组织必须保护其网络免受攻击，还必须遵守各种行业法规：任何属于特定法规的组织，如支付行业的支付卡行业-数据安全标准（PCI-DSS）[PCI-DSS]或健康保险便携性和责任法案[HIPAA]对于医疗行业，必须能够隔离各种流量。他们还必须在审核时显示其安全策略的记录。
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.
I2NSF客户端接口可用于提供监管和合规相关的安全策略。安全控制器将跟踪何时何地应用特定策略，以及是否存在任何违反策略的情况；在进行审计时，可以提供此信息，以证明在完全符合要求的法规的情况下，特定端点之间的通信是隔离的。
Management of NSFs usually include the following:
NSF的管理通常包括以下内容：
o Life-cycle management and resource management of NSFs,
o NSF的生命周期管理和资源管理，
o Device configuration, such as address configuration, device internal attributes configuration, etc.,
o 设备配置，如地址配置、设备内部属性配置等。，
o Signaling of events, notifications, and changes, and
o 事件、通知和变更的信号，以及
o Policy rule provisioning.
o 策略规则设置。
I2NSF will only focus on the policy provisioning part of NSF management.
I2NSF将只关注NSF管理的策略提供部分。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
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).
安全访问控制和监视NSF对于托管安全服务至关重要。I2NSF安全控制器带来了新的安全威胁。它需要具有抵御攻击的能力，并从攻击中快速恢复。因此，必须仔细指定适当的安全通信信道，以承载、控制和监控NSF及其管理实体（或多个实体）之间的通信量。
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.
客户指定的流量安全策略可能与提供商的内部流量安全策略冲突。此冲突可以通过以下两种方式之一解决：a）如果客户流量安全策略或提供商的内部安全策略限制流量，则安装的策略可以限制流量，或b）如果客户流量安全策略和提供商的内部流量安全策略都限制数据，则安装的策略只能限制流量。任何一种选择都可能导致潜在的问题。管理系统向客户和服务提供商标记这些冲突是至关重要的。
It is important to proper AAA [RFC2904] to authorize access to the network and access to the I2NSF management stream.
正确的AAA[RFC2904]授权访问网络和I2NSF管理流非常重要。
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.
实施适当的隐私是所有IETF协议的关键（请参见[RFC6973]），对于IETF安全管理协议尤其重要，因为这些协议的部署是为了保护网络。在某些情况下，可以使用安全管理协议来保护个人的家庭、电话或其他个人数据。在这种情况下，任何解决方案都应该仔细考虑组合管理流是否遵循[RCF693]推荐的数据最小化、用户参与和安全性。
[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.
[ACCESS-USECASE]Wang，K.和X.Zhuang，“接入网络集成安全用例”，正在进行的工作，草稿-qi-i2nsf-ACCESS-Network-USECASE-022015年3月。
[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.
[CAP-INTERFACE]Zhou，C.，Xia，L.，Boucadair，M.，和J.Xiong，“I2NSF中监控网络安全功能（NSF）的能力接口”，正在进行的工作，草稿-Zhou-I2NSF-Capability-INTERFACE-Monitoring-00，2015年10月。
[CTA] "Cyber Threat Alliance", <http://cyberthreatalliance.org>.
[CTA]“网络威胁联盟”<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.
[DC-USECASE]Zarny，M.，Majee，S.，Leymann，N.，和L.Dunbar，“I2NSF数据中心用例”，正在进行的工作，草稿-Zarny-I2NSF-Data-Center-Use-Cases-002014年10月。
[EPC-3GPP] Firmin, F., "The Evolved Packet Core", January 2017.
[EPC-3GPP]菲尔曼，F.，“进化包核心”，2017年1月。
[ETSI-NFV] ETSI, "Network Functions Virtualisation (NFV); Architectural Framework", ETSI GS NFV 002 V1.2.1, December 2014.
[ETSI-NFV]ETSI，“网络功能虚拟化（NFV）；体系结构框架”，ETSI GS NFV 002 V1.2.12014年12月。
[FIREWALLS] Baker, F. and P. Hoffman, "On Firewalls in Internet Security", Work in Progress, draft-ietf-opsawg-firewalls-01, October 2012.
[防火墙]Baker，F.和P.Hoffman，“关于互联网安全中的防火墙”，正在进行的工作，草稿-ietf-opsawg-FIREWALLS-01，2012年10月。
[Gartner] Messmer, E., "Gartner: Cloud-based security as a service set to take off", October 2013.
[Gartner]Messmer，E.，“Gartner:Cloud-based security as a service即将起飞”，2013年10月。
[HIPAA] US Congress, "Health Insurance Portability and Accountability Act of 1996 (Public Law 104-191)", August 1996, <https://www.hhs.gov/hipaa/>.
[HIPAA]美国国会，“1996年健康保险可携带性和责任法案（公法104-191）”，1996年8月<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-ANALYSIS]Hares，S.，Moskowitz，R.，和D.Zhang，“I2NSF现有工作分析”，正在进行的工作，草案-ietf-I2NSF-gap-ANALYSIS-032017年3月。
[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.
[I2NSF-USECASES]Pastor，A.，Lopez，D.，Wang，K.，Zhuang，X.，Qi，M.，Zarny，M.，Majee，S.，Leymann，N.，Dunbar，L.，和M.Georgiades，“网络安全功能接口的用例和要求”，正在进行中，草稿-Pastor-I2NSF-merged-Use-Cases-00，2015年6月。
[NFVUC] ETSI, "Network Functions Virtualization (NFV); Use Cases", ETSI GR NFV 001 V1.2.1, May 2017.
[NFVUC]ETSI，“网络功能虚拟化（NFV）；用例”，ETSI GR NFV 001 V1.2.1，2017年5月。
[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.
[OAM-USECASE]Pastor，A.和D.Lopez，“虚拟化安全服务开放OAM接口的访问用例”，正在进行的工作，草稿-Pastor-i2nsf-Access-usecases-00，2014年10月。
[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/>.
[PCI-DSS]PCI安全标准委员会，“支付卡行业（PCI）数据安全标准——要求和安全评估程序”，PCS DSS v3.2，2016年4月<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>.
[RFC2904]Vollbrecht，J.，Calhoun，P.，Farrell，S.，Gommans，L.，Gross，G.，de Bruijn，B.，de Laat，C.，Holdrege，M.，和D.Spence，“AAA授权框架”，RFC 2904，DOI 10.17487/RFC29042000年8月<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>.
[RFC4948]Andersson，L.，Davies，E.，和L.Zhang，“国际律师协会2006年3月9日至10日不必要交通研讨会报告”，RFC 4948，DOI 10.17487/RFC4948，2007年8月<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>.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 5925，DOI 10.17487/RFC5925，2010年6月<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>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<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>.
[RFC7149]Boucadair，M.和C.Jacquenet，“软件定义的网络：服务提供商环境中的视角”，RFC 7149，DOI 10.17487/RFC7149，2014年3月<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>.
[RFC7426]Haleplis，E.，Ed.，Pentikousis，K.，Ed.，Denazis，S.，Hadi Salim，J.，Meyer，D.，和O.Koufopavlou，“软件定义网络（SDN）：层和架构术语”，RFC 7426，DOI 10.17487/RFC7426，2015年1月<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.
[SDN-SECURITY]Jeong，J.，Kim，H.，Park，J.，Ahn，T.，和S.Lee，“使用网络安全功能接口的软件定义的基于网络的安全服务”，正在进行的工作，草稿-Jeong-i2nsf-SDN-SECURITY-Services-052016年7月。
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).
本文件得到了信息和通信技术促进研究所（IITP）的支持，该研究所由科学、ICT和未来规划部（MSIP）资助（R0166-15-1041，基于网络安全的SDN标准开发）。
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是一项集体努力。以下人员积极参与了最初的用例文本：庄晓军（中国移动）、苏曼德拉·马杰（F5）、埃德·洛佩兹（Curveball Networks）和罗伯特·莫斯科维茨（华为）。
I2NSF has had a number of contributing authors. The following are considered co-authors:
I2NSF有许多贡献作者。以下被视为共同作者：
o Linda Dunbar (Huawei)
o 琳达·邓巴（华为）
o Antonio Pastur (Telefonica I+D)
o 安东尼奥·帕斯图（西班牙电视台I+D）
o Mohamed Boucadair (France Telecom)
o Mohamed Boucadair（法国电信）
o Michael Georgiades (Prime Tel)
o 迈克尔·乔治亚德斯（Prime Tel）
o Minpeng Qi (China Mobile)
o 齐敏鹏（中国移动）
o Shaibal Chakrabarty (US Ignite)
o Shaibal Chakrabarty（美国点燃）
o Nic Leymann (Deutsche Telekom)
o 尼克·莱曼（德国电信）
o Anil Lohiya (Juniper)
o 阿尼尔·洛希亚（杜松）
o David Qi (Bloomberg)
o 齐大卫（彭博社）
o Hyoungshick Kim (Sungkyunkwan University)
o 金亨希克（成均馆大学）
o Jung-Soo Park (ETRI)
o 郑秀公园（ETRI）
o Tae-Jin Ahn (Korea Telecom)
o Tae Jin Ahn（韩国电信）
o Se-Hui Lee (Korea Telecom)
o 李世辉（韩国电信）
Authors' Addresses
作者地址
Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 United States of America
Susan Hares Huawei 7453美国密歇根州山核桃山盐碱地48176
Phone: +1-734-604-0332
Email: shares@ndzh.com
Phone: +1-734-604-0332
Email: shares@ndzh.com
Diego R. Lopez Telefonica I+D Don Ramon de la Cruz, 82 Madrid 28006 Spain
Diego R.Lopez Telefonica I+D Don Ramon de la Cruz，82马德里28006西班牙
Email: diego.r.lopez@telefonica.com
Email: diego.r.lopez@telefonica.com
Myo Zarny vArmour 800 El Camino Real, Suite 3000 Mountain View, CA 94040 United States of America
迈奥·扎尼·瓦尔莫800 El Camino Real，美国加利福尼亚州山景城3000套房，邮编94040
Email: myo@varmour.com
Email: myo@varmour.com
Christian Jacquenet France Telecom Rennes, 35000 France
Christian Jacquenet法国电信雷恩，35000法国
Email: Christian.jacquenet@orange.com
Email: Christian.jacquenet@orange.com
Rakesh Kumar Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America
Rakesh Kumar Juniper Networks 1133 Innovation Way Sunnyvale，加利福尼亚州，美利坚合众国94089
Email: rakeshkumarcloud@gmail.com
Email: rakeshkumarcloud@gmail.com
Jaehoon Paul Jeong Department of Software Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea
韩国京畿道江根古水原，成均馆大学软件系2066 Seobu Ro，邮编：16419
Phone: +82 31 299 4957
Fax: +82 31 290 7996
Email: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
Phone: +82 31 299 4957
Fax: +82 31 290 7996
Email: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php