Internet Engineering Task Force (IETF) D. Lopez
Request for Comments: 8329 Telefonica I+D
Category: Informational E. Lopez
ISSN: 2070-1721 Curveball Networks
L. Dunbar
J. Strassner
Huawei
R. Kumar
Juniper Networks
February 2018
Internet Engineering Task Force (IETF) D. Lopez
Request for Comments: 8329 Telefonica I+D
Category: Informational E. Lopez
ISSN: 2070-1721 Curveball Networks
L. Dunbar
J. Strassner
Huawei
R. Kumar
Juniper Networks
February 2018
Framework for Interface to Network Security Functions
网络安全功能接口框架
Abstract
摘要
This document describes the framework for Interface to Network Security Functions (I2NSF) and defines a reference model (including major functional components) for I2NSF. Network Security Functions (NSFs) are packet-processing engines that inspect and optionally modify packets traversing networks, either directly or in the context of sessions to which the packet is associated.
本文档描述了网络安全功能接口（I2NSF）的框架，并定义了I2NSF的参考模型（包括主要功能组件）。网络安全功能（NSF）是数据包处理引擎，可直接或在与数据包相关联的会话上下文中检查并选择性地修改穿越网络的数据包。
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 candidates 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 https://www.rfc-editor.org/info/rfc8329.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8329.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3. I2NSF Reference Model . . . . . . . . . . . . . . . . . . . . 5
3.1. I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 6
3.2. I2NSF NSF-Facing Interface . . . . . . . . . . . . . . . 6
3.3. I2NSF Registration Interface . . . . . . . . . . . . . . 7
4. Threats Associated with Externally Provided NSFs . . . . . . 8
5. Avoiding NSF Ossification . . . . . . . . . . . . . . . . . . 9
6. The Network Connecting I2NSF Components . . . . . . . . . . . 10
6.1. Network Connecting I2NSF Users and the I2NSF Controller . 10
6.2. Network Connecting the I2NSF Controller and NSFs . . . . 10
6.3. Interface to vNSFs . . . . . . . . . . . . . . . . . . . 11
6.4. Consistency . . . . . . . . . . . . . . . . . . . . . . . 12
7. I2NSF Flow Security Policy Structure . . . . . . . . . . . . 13
7.1. Customer-Facing Flow Security Policy Structure . . . . . 13
7.2. NSF-Facing Flow Security Policy Structure . . . . . . . . 14
7.3. Differences from ACL Data Models . . . . . . . . . . . . 16
8. Capability Negotiation . . . . . . . . . . . . . . . . . . . 16
9. Registration Considerations . . . . . . . . . . . . . . . . . 17
9.1. Flow-Based NSF Capability Characterization . . . . . . . 17
9.2. Registration Categories . . . . . . . . . . . . . . . . . 18
10. Manageability Considerations . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3. I2NSF Reference Model . . . . . . . . . . . . . . . . . . . . 5
3.1. I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 6
3.2. I2NSF NSF-Facing Interface . . . . . . . . . . . . . . . 6
3.3. I2NSF Registration Interface . . . . . . . . . . . . . . 7
4. Threats Associated with Externally Provided NSFs . . . . . . 8
5. Avoiding NSF Ossification . . . . . . . . . . . . . . . . . . 9
6. The Network Connecting I2NSF Components . . . . . . . . . . . 10
6.1. Network Connecting I2NSF Users and the I2NSF Controller . 10
6.2. Network Connecting the I2NSF Controller and NSFs . . . . 10
6.3. Interface to vNSFs . . . . . . . . . . . . . . . . . . . 11
6.4. Consistency . . . . . . . . . . . . . . . . . . . . . . . 12
7. I2NSF Flow Security Policy Structure . . . . . . . . . . . . 13
7.1. Customer-Facing Flow Security Policy Structure . . . . . 13
7.2. NSF-Facing Flow Security Policy Structure . . . . . . . . 14
7.3. Differences from ACL Data Models . . . . . . . . . . . . 16
8. Capability Negotiation . . . . . . . . . . . . . . . . . . . 16
9. Registration Considerations . . . . . . . . . . . . . . . . . 17
9.1. Flow-Based NSF Capability Characterization . . . . . . . 17
9.2. Registration Categories . . . . . . . . . . . . . . . . . 18
10. Manageability Considerations . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
This document describes the framework for Interface to Network Security Functions (I2NSF) and defines a reference model (including major functional components) for I2NSF. This includes an analysis of the threats implied by the deployment of Network Security Functions (NSFs) that are externally provided. It also describes how I2NSF facilitates implementing security functions in a technology- and vendor-independent manner in Software-Defined Networking (SDN) and Network Function Virtualization (NFV) environments, while avoiding potential constraints that could limit the capabilities of NSFs.
本文档描述了网络安全功能接口（I2NSF）的框架，并定义了I2NSF的参考模型（包括主要功能组件）。这包括对外部提供的网络安全功能（NSF）部署所隐含的威胁的分析。它还描述了I2NSF如何在软件定义网络（SDN）和网络功能虚拟化（NFV）环境中以独立于技术和供应商的方式实现安全功能，同时避免可能限制NSF功能的潜在限制。
I2NSF use cases [RFC8192] call for standard interfaces for users of an I2NSF system (e.g., applications, overlay or cloud network management system, or enterprise network administrator or management system) to inform the I2NSF system which I2NSF functions should be applied to which traffic (or traffic patterns). The I2NSF system realizes this as a set of security rules for monitoring and controlling the behavior of different traffic. It also provides standard interfaces for users to monitor flow-based security functions hosted and managed by different administrative domains.
I2NSF用例[RFC8192]为I2NSF系统的用户（例如，应用程序、覆盖或云网络管理系统，或企业网络管理员或管理系统）调用标准接口，以通知I2NSF系统应将哪些I2NSF功能应用于哪些流量（或流量模式）。I2NSF系统将此作为一组安全规则来实现，用于监视和控制不同流量的行为。它还为用户提供标准接口，以监控由不同管理域托管和管理的基于流的安全功能。
[RFC8192] also describes the motivation and the problem space for an Interface to Network Security Functions system.
[RFC8192]还描述了网络安全功能系统接口的动机和问题空间。
This memo does not propose a protocol standard, and the use of words such as "should" follow their ordinary English meaning and not that for normative languages defined in [RFC2119] [RFC8174].
本备忘录未提出协议标准，诸如“应”等词语的使用遵循其普通英语含义，而不是[RFC2119][RFC8174]中定义的规范性语言的含义。
The following acronyms are used in this document:
本文件中使用了以下首字母缩略词：
DOTS: Distributed Denial-of-Service Open Threat Signaling IDS: Intrusion Detection System IoT: Internet of Things IPS: Intrusion Protection System NSF: Network Security Function
DOTS:分布式拒绝服务开放威胁信号IDS:入侵检测系统IoT:物联网IPS:入侵防护系统NSF:网络安全功能
The following terms, which are used in this document, are defined in the I2NSF terminology document [I2NSF-TERMS]:
本文件中使用的以下术语在I2NSF术语文件[I2NSF-terms]中定义：
Capability Controller Firewall I2NSF Consumer I2NSF NSF-Facing Interface I2NSF Policy Rule I2NSF Producer I2NSF Registration Interface I2NSF Registry Interface Interface Group Intrusion Detection System Intrusion Protection System Network Security Function Role
能力控制器防火墙I2NSF用户I2NSF面向接口I2NSF策略规则I2NSF生产者I2NSF注册接口I2NSF注册表接口组入侵检测系统入侵保护系统网络安全功能角色
Figure 1 shows a reference model (including major functional components and interfaces) for an I2NSF system. This figure is drawn from the point of view of the Network Operator Management System; hence, this view does not assume any particular management architecture for either the NSFs or how the NSFs are managed (on the developer's side). In particular, the Network Operator Management System does not participate in NSF data-plane activities.
图1显示了I2NSF系统的参考模型（包括主要功能组件和接口）。该图是从网络运营商管理系统的角度绘制的；因此，该视图不假设NSF的任何特定管理体系结构，也不假设NSF的管理方式（在开发人员方面）。特别是，网络运营商管理系统不参与NSF数据平面活动。
+-------------------------------------------------------+
| I2NSF User (e.g., Overlay Network Mgmt, Enterprise |
| Network Mgmt, another network domain's mgmt, etc.) |
+--------------------+----------------------------------+
|
| I2NSF Consumer-Facing Interface
|
| I2NSF
+------------+---------+ Registration +-------------+
| Network Operator Mgmt| Interface | Developer's |
| System | < --------- > | Mgmt System |
+----------------+-----+ +-------------+
|
| I2NSF NSF-Facing Interface
|
+---------------+----+------------+---------------+
| | | |
+---+---+ +---+---+ +---+---+ +---+---+
| NSF-1 | ... | NSF-m | | NSF-1 | ... | NSF-m | ...
+-------+ +-------+ +-------+ +-------+
+-------------------------------------------------------+
| I2NSF User (e.g., Overlay Network Mgmt, Enterprise |
| Network Mgmt, another network domain's mgmt, etc.) |
+--------------------+----------------------------------+
|
| I2NSF Consumer-Facing Interface
|
| I2NSF
+------------+---------+ Registration +-------------+
| Network Operator Mgmt| Interface | Developer's |
| System | < --------- > | Mgmt System |
+----------------+-----+ +-------------+
|
| I2NSF NSF-Facing Interface
|
+---------------+----+------------+---------------+
| | | |
+---+---+ +---+---+ +---+---+ +---+---+
| NSF-1 | ... | NSF-m | | NSF-1 | ... | NSF-m | ...
+-------+ +-------+ +-------+ +-------+
Developer Mgmt System A Developer Mgmt System B
开发者管理系统A开发者管理系统B
Figure 1: I2NSF Reference Model
图1:I2NSF参考模型
When defining I2NSF Interfaces, this framework adheres to the following principles:
定义I2NSF接口时，此框架遵循以下原则：
o It is agnostic of network topology and NSF location in the network
o 它不知道网络拓扑和NSF在网络中的位置
o It is agnostic of provider of the NSF (i.e., independent of the way that the provider makes an NSF available, as well as how the provider allows the NSF to be managed)
o 它不知道NSF的提供者（即，独立于提供者提供NSF的方式，以及提供者如何允许管理NSF）
o It is agnostic of any vendor-specific operational, administrative, and management implementation; hosting environment; and form factor (physical or virtual)
o 它与任何供应商特定的运营、管理和管理实施无关；托管环境；和形状因素（物理或虚拟）
o It is agnostic to NSF control-plane implementation (e.g., signaling capabilities)
o 它与NSF控制平面实现无关（例如，信令能力）
o It is agnostic to NSF data-plane implementation (e.g., encapsulation capabilities)
o 它与NSF数据平面实现无关（例如，封装能力）
In general, all I2NSF Interfaces should require at least mutual authentication and authorization for their use. Other security and privacy considerations are specified in Section 11.
一般来说，所有I2NSF接口的使用至少需要相互认证和授权。第11节规定了其他安全和隐私注意事项。
The I2NSF Consumer-Facing Interface is used to enable different users of a given I2NSF system to define, manage, and monitor security policies for specific flows within an administrative domain. The location and implementation of I2NSF policies are irrelevant to the consumer of I2NSF policies.
I2NSF面向消费者的接口用于使给定I2NSF系统的不同用户能够定义、管理和监视管理域内特定流的安全策略。I2NSF策略的位置和实施与I2NSF策略的使用者无关。
Some examples of I2NSF Consumers include:
I2NSF用户的一些示例包括：
o A video-conference network manager that needs to dynamically inform the underlay network to allow, rate-limit, or deny flows (some of which are encrypted) based on specific fields in the packets for a certain time span.
o 一种视频会议网络管理器，需要根据数据包中的特定字段在一定时间跨度内动态通知参考底图网络允许、限制或拒绝流量（其中一些是加密的）。
o Enterprise network administrators and management systems that need to request their provider network to enforce specific I2NSF policies for particular flows.
o 企业网络管理员和管理系统需要请求其提供商网络为特定流实施特定I2NSF策略。
o An IoT management system sending requests to the underlay network to block flows that match a set of specific conditions.
o 物联网管理系统向底层网络发送请求，以阻止符合一组特定条件的流量。
The I2NSF NSF-Facing Interface (NSF-Facing Interface for short) is used to specify and monitor flow-based security policies enforced by one or more NSFs. Note that the I2NSF Management System does not need to use all features of a given NSF, nor does it need to use all available NSFs. Hence, this abstraction enables NSF features to be treated as building blocks by an NSF system; thus, developers are free to use the security functions defined by NSFs independent of vendor and technology.
I2NSF面向NSF接口（简称NSF面向接口）用于指定和监视一个或多个NSF强制实施的基于流的安全策略。请注意，I2NSF管理系统不需要使用给定NSF的所有功能，也不需要使用所有可用NSF。因此，这种抽象使NSF特性能够被NSF系统视为构建块；因此，开发人员可以独立于供应商和技术，自由使用NSF定义的安全功能。
Flow-based NSFs [RFC8192] inspect packets in the order that they are received. Note that all Interface Groups require the NSF to be registered using the Registration Interface. The interface to flow-based NSFs can be categorized as follows:
基于流的NSF[RFC8192]按接收顺序检查数据包。请注意，所有接口组都要求使用注册接口注册NSF。基于流的NSF的接口可分类如下：
1. NSF Operational and Administrative Interface: an Interface Group used by the I2NSF Management System to program the operational state of the NSF; this also includes administrative control functions. I2NSF Policy Rules represent one way to change this Interface Group in a consistent manner. Since applications and I2NSF Components need to dynamically control the behavior of traffic that they send and receive, much of the I2NSF effort is focused on this Interface Group.
1. NSF运行和管理接口：I2NSF管理系统用于编程NSF运行状态的接口组；这还包括行政控制职能。I2NSF策略规则表示以一致方式更改此接口组的一种方法。由于应用程序和I2NSF组件需要动态控制它们发送和接收的流量的行为，I2NSF的大部分工作都集中在这个接口组上。
2. Monitoring Interface: an Interface Group used by the I2NSF Management System to obtain monitoring information from one or more selected NSFs. Each interface in this Interface Group could be a query- or a report-based interface. The difference is that a query-based interface is used by the I2NSF Management System to obtain information, whereas a report-based interface is used by the NSF to provide information. The functionality of this Interface Group may also be defined by other protocols, such as SYSLOG and DOTS. The I2NSF Management System may take one or more actions based on the receipt of information; this should be specified by an I2NSF Policy Rule. This Interface Group does NOT change the operational state of the NSF.
2. 监控接口：I2NSF管理系统用于从一个或多个选定NSF获取监控信息的接口组。此接口组中的每个接口都可以是查询接口或基于报表的接口。区别在于I2NSF管理系统使用基于查询的接口来获取信息，而NSF使用基于报告的接口来提供信息。此接口组的功能也可以由其他协议定义，如SYSLOG和DOTS。I2NSF管理系统可根据收到的信息采取一项或多项措施；这应该由I2NSF策略规则指定。此接口组不会更改NSF的运行状态。
This document uses the flow-based paradigm to develop the NSF-Facing Interface. A common trait of flow-based NSFs is in the processing of packets based on the content (e.g., header/payload) and/or context (e.g., session state and authentication state) of the received packets. This feature is one of the requirements for defining the behavior of I2NSF.
本文档使用基于流的范例来开发面向NSF的接口。基于流的nsf的一个共同特征是基于所接收分组的内容（例如，报头/有效载荷）和/或上下文（例如，会话状态和认证状态）来处理分组。此功能是定义I2NSF行为的要求之一。
NSFs provided by different vendors may have different capabilities. In order to automate the process of utilizing multiple types of security functions provided by different vendors, it is necessary to have a dedicated interface for vendors to define the capabilities of (i.e., register) their NSFs. This interface is called the I2NSF Registration Interface.
不同供应商提供的NSF可能具有不同的功能。为了自动化利用不同供应商提供的多种类型安全功能的过程，有必要为供应商提供一个专用接口，以定义（即注册）其NSF的功能。该接口称为I2NSF注册接口。
An NSF's capabilities can be either pre-configured or retrieved dynamically through the I2NSF Registration Interface. If a new function that is exposed to the consumer is added to an NSF, then the capabilities of that new function should be registered in the I2NSF
NSF的能力可以预先配置，也可以通过I2NSF注册接口动态检索。如果向使用者公开的新功能被添加到NSF，则该新功能的功能应在I2NSF中注册
Registry via the I2NSF Registration Interface, so that interested management and control entities may be made aware of them.
通过I2NSF注册接口进行注册，以便相关管理和控制实体了解这些信息。
While associated with a much higher flexibility, and in many cases a necessary approach given the deployment conditions, the usage of externally provided NSFs implies several additional concerns in security. The most relevant threats associated with a security platform of this nature are:
尽管与更高的灵活性相关，而且在许多情况下，考虑到部署条件，这是一种必要的方法，但使用外部提供的NSF意味着安全方面的一些额外问题。与这种性质的安全平台相关的最相关的威胁是：
o An unknown/unauthorized user can try to impersonate another user that can legitimately access external NSF services. This attack may lead to accessing the I2NSF Policy Rules and applications of the attacked user and/or generating network traffic outside the security functions with a falsified identity.
o 未知/未经授权的用户可以尝试模拟另一个可以合法访问外部NSF服务的用户。此攻击可能导致访问受攻击用户的I2NSF策略规则和应用程序，和/或使用伪造身份在安全功能之外生成网络流量。
o An authorized user may misuse assigned privileges to alter the network traffic processing of other users in the NSF underlay or platform.
o 授权用户可能会滥用分配的权限来更改NSF参考底图或平台中其他用户的网络流量处理。
o A user may try to install malformed elements (e.g., I2NSF Policy Rules or configuration files) to directly take control of an NSF or the whole provider platform. For example, a user may exploit a vulnerability on one of the functions or may try to intercept or modify the traffic of other users in the same provider platform.
o 用户可能试图安装格式错误的元素（例如I2NSF策略规则或配置文件），以直接控制NSF或整个提供商平台。例如，用户可能利用其中一个功能上的漏洞进行攻击，或者可能尝试拦截或修改同一提供商平台中其他用户的流量。
o A malicious provider can modify the software (e.g., the operating system or the specific NSF implementation) to alter the behavior of one or more NSFs. This event has a high impact on all users accessing NSFs, since the provider has the highest level of privileges controlling the operation of the software.
o 恶意提供商可以修改软件（例如，操作系统或特定NSF实现）以改变一个或多个NSF的行为。此事件对访问NSF的所有用户都有很大影响，因为提供商拥有控制软件操作的最高级别权限。
o A user that has physical access to the provider platform can modify the behavior of the hardware/software components or the components themselves. For example, the user can access a serial console (most devices offer this interface for maintenance reasons) to access the NSF software with the same level of privilege of the provider.
o 具有提供商平台物理访问权限的用户可以修改硬件/软件组件或组件本身的行为。例如，用户可以访问串行控制台（大多数设备出于维护原因提供此接口），以使用与提供商相同级别的权限访问NSF软件。
The use of authentication, authorization, accounting, and audit mechanisms is recommended for all users and applications to access the I2NSF environment. This can be further enhanced by requiring attestation to be used to detect changes to the I2NSF environment by authorized parties. The characteristics of these procedures will define the level of assurance of the I2NSF environment.
建议所有用户和应用程序使用身份验证、授权、记帐和审核机制来访问I2NSF环境。这可以通过要求认证用于检测授权方对I2NSF环境的更改来进一步增强。这些程序的特点将确定I2NSF环境的保证水平。
A basic tenet in the introduction of I2NSF standards is that the standards should not make it easier for attackers to compromise the network. Therefore, in constructing standards for I2NSF Interfaces as well as I2NSF Policy Rules, it is equally important to allow support for specific functions, as this enables the introduction of NSFs that evolve to meet new threats. Proposed standards for I2NSF Interfaces to communicate with NSFs, as well as I2NSF Policy Rules to control NSF functionality, should not:
I2NSF标准介绍的一个基本原则是，这些标准不应使攻击者更容易危害网络。因此，在为I2NSF接口以及I2NSF策略规则构建标准时，允许支持特定功能同样重要，因为这样可以引入NSF，以应对新的威胁。与NSF通信的I2NSF接口的拟定标准以及控制NSF功能的I2NSF策略规则不应：
o Narrowly define NSF categories, or their roles, when implemented within a network. Security is a constantly evolving discipline. The I2NSF framework relies on an object-oriented information model, which provides an extensible definition of NSF information elements and categories; it is recommended that implementations follow this model.
o 在网络中实施时，狭义地定义NSF类别或其角色。安全是一门不断发展的学科。I2NSF框架依赖于面向对象的信息模型，该模型提供了NSF信息元素和类别的可扩展定义；建议实现遵循此模型。
o Attempt to impose functional requirements or constraints, either directly or indirectly, upon NSF developers. Implementations should be free to realize and apply NSFs in a way that best suits the needs of the applications and environment using them.
o 试图直接或间接地将功能需求或约束强加给NSF开发人员。实现应该可以自由地以最适合应用程序和使用NSF的环境的方式实现和应用NSF。
o Be a limited lowest common denominator approach, where interfaces can only support a limited set of standardized functions, without allowing for developer-specific functions. NSFs, interfaces, and the data communicated should be extensible, so that they can evolve to protect against new threats.
o 是一种有限的最低公分母方法，其中接口只能支持有限的一组标准化功能，而不允许特定于开发人员的功能。NSF、接口和通信的数据应该是可扩展的，以便它们能够发展以抵御新的威胁。
o Be seen as endorsing a best common practice for the implementation of NSFs; rather, this document describes the conceptual structure and reference model of I2NSF. The purpose of this reference model is to define a common set of concepts in order to facilitate the flexible implementation of an I2NSF system.
o 被视为认可实施NSF的最佳通用实践；相反，本文件描述了I2NSF的概念结构和参考模型。此参考模型的目的是定义一组通用概念，以便于灵活实施I2NSF系统。
To prevent constraints on NSF developers' creativity and innovation, this document recommends flow-based NSF interfaces to be designed from the paradigm of processing packets in the network. Flow-based NSFs are ultimately packet-processing engines that inspect packets traversing networks, either directly or in the context of sessions in which the packet is associated. The goal is to create a workable interface to NSFs that aids in their integration within legacy, SDN, and/or NFV environments, while avoiding potential constraints that could limit their functional capabilities.
为了防止限制NSF开发人员的创造力和创新能力，本文档建议根据网络中处理数据包的范例设计基于流的NSF接口。基于流的NSF最终是数据包处理引擎，可以直接或在与数据包相关联的会话上下文中检查通过网络的数据包。目标是为NSF创建一个可行的接口，帮助其在遗留、SDN和/或NFV环境中集成，同时避免可能限制其功能能力的潜在约束。
As a general principle, in the I2NSF environment, users directly interact with the I2NSF Controller. Given the role of the I2NSF Controller, a mutual authentication of users and the I2NSF Controller is required. I2NSF does not mandate a specific authentication scheme; it is up to the users to choose available authentication schemes based on their needs.
一般来说，在I2NSF环境中，用户直接与I2NSF控制器交互。鉴于I2NSF控制器的作用，需要用户和I2NSF控制器的相互身份验证。I2NSF不要求特定的认证方案；用户可以根据自己的需要选择可用的身份验证方案。
Upon successful authentication, a trusted connection between the user and the I2NSF Controller (or an endpoint designated by it) will be established. This means that a direct, physical point-to-point connection, with physical access restricted according to access control, must be used. All traffic to and from the NSF environment will flow through this connection. The connection is intended not only to be secure but trusted in the sense that it should be bound to the mutual authentication between the user and the I2NSF Controller, as described in [I2NSF-ATTESTATION]. The only possible exception is when the required level of assurance is lower (see Section 4.1 of [I2NSF-ATTESTATION]), in which case the user must be made aware of this circumstance.
认证成功后，将在用户和I2NSF控制器（或其指定的端点）之间建立可信连接。这意味着必须使用直接的物理点对点连接，并根据访问控制限制物理访问。所有进出NSF环境的流量都将通过此连接。连接不仅要安全，而且要可信，因为它应该绑定到用户和I2NSF控制器之间的相互认证，如[I2NSF-认证]中所述。唯一可能的例外情况是，所需的保证水平较低（见[I2NSF-认证]第4.1节），在这种情况下，必须让用户了解这种情况。
Most likely, the NSFs are not directly attached to the I2NSF Controller; for example, NSFs can be distributed across the network. The network that connects the I2NSF Controller with the NSFs can be the same network that carries the data traffic, or it can be a dedicated network for management purposes only. In either case, packet loss could happen due to failure, congestion, or other reasons.
最有可能的是，NSF未直接连接到I2NSF控制器；例如，NSF可以跨网络分布。将I2NSF控制器与NSFs连接的网络可以是承载数据流量的同一网络，也可以是仅用于管理目的的专用网络。无论哪种情况，数据包丢失都可能是由于故障、拥塞或其他原因造成的。
Therefore, the transport mechanism used to carry management data and information must be secure. It does not have to be a reliable transport; rather, a transport-independent reliable messaging mechanism is required, where communication can be performed reliably (e.g., by establishing end-to-end communication sessions and by introducing explicit acknowledgement of messages into the communication flow). Latency requirements for control message delivery must also be evaluated. Note that monitoring does not require reliable transport.
因此，用于传输管理数据和信息的传输机制必须是安全的。它不一定是可靠的运输工具；相反，需要独立于传输的可靠消息传递机制，其中可以可靠地执行通信（例如，通过建立端到端通信会话和通过将消息的明确确认引入通信流）。还必须评估控制消息传递的延迟要求。注意，监控不需要可靠的传输。
The network connection between the I2NSF Controller and NSFs can rely on either:
I2NSF控制器和NSF之间的网络连接可以依赖于：
o Open environments, where one or more NSFs can be hosted in one or more external administrative domains that are reached via secure external network connections. This requires more restrictive security control to be placed over the I2NSF Interface. The information over the I2NSF Interfaces shall be exchanged by using the trusted connection described in Section 6.1, or
o 开放环境，其中一个或多个NSF可以托管在一个或多个通过安全外部网络连接访问的外部管理域中。这需要对I2NSF接口进行更严格的安全控制。I2NSF接口上的信息应使用第6.1节所述的可信连接进行交换，或
o Closed environments, where there is only one administrative domain. Such environments provide a more **isolated** environment but still communicate over the same set of I2NSF Interfaces present in open environments (see above). Hence, the security control and access requirements for closed environments are the same as those for open environments.
o 封闭环境，其中只有一个管理域。这样的环境提供了一个更加**隔离**的环境，但仍然通过开放环境中存在的同一组I2NSF接口进行通信（见上文）。因此，封闭环境的安全控制和访问要求与开放环境相同。
The network connection between the I2NSF Controller and NSFs will use the trusted connection mechanisms described in Section 6.1. Following these mechanisms, the connections need to rely on the use of properly verified peer identities (e.g., through an Authentication, Authorization, and Accounting (AAA) framework). The implementations of identity management functions, as well as the AAA framework, are out of scope for I2NSF.
I2NSF控制器和NSF之间的网络连接将使用第6.1节所述的可信连接机制。遵循这些机制，连接需要依赖于正确验证的对等身份的使用（例如，通过身份验证、授权和记帐（AAA）框架）。身份管理功能的实现以及AAA框架超出I2NSF的范围。
There are some unique characteristics in interfacing to virtual NSFs (vNSFs):
与虚拟NSF（VNSF）的接口有一些独特的特点：
o There could be multiple instantiations of one single NSF that has been distributed across a network. When different instantiations are visible to the I2NSF Controller, different policies may be applied to different instantiations of an individual NSF (e.g., to reflect the different roles that each vNSF is designated for). Therefore, it is recommended that Roles, in addition to the use of robust identities, be used to distinguish between different instantiations of the same vNSF. Note that this also applies to physical NSFs.
o 一个NSF可能有多个实例，这些实例分布在网络上。当I2NSF控制器可以看到不同的实例化时，可以对单个NSF的不同实例化应用不同的策略（例如，反映每个vNSF指定的不同角色）。因此，建议除了使用健壮的标识外，还使用角色来区分相同vNSF的不同实例化。请注意，这也适用于物理NSF。
o When multiple instantiations of one single NSF appear as one single entity to the I2NSF Controller, the I2NSF Controller may need to get assistance from other entities in the I2NSF Management System and/or delegate the provisioning of the multiple instantiations of the (single) NSF to other entities in the I2NSF Management System. This is shown in Figure 2 below.
o 当一个单一NSF的多个实例化作为一个单一实体出现在I2NSF控制器中时，I2NSF控制器可能需要从I2NSF管理系统中的其他实体获得帮助和/或将（单个）NSF的多个实例化的供应委托给I2NSF管理系统中的其他实体。这如下图2所示。
o Policies enforced by one vNSF instance may need to be retrieved and moved to another vNSF of the same type when user flows are moved from one vNSF to another.
o 当用户流从一个vNSF移动到另一个vNSF时，可能需要检索由一个vNSF实例强制执行的策略并将其移动到同一类型的另一个vNSF。
o Multiple vNSFs may share the same physical platform.
o 多个VNSF可以共享同一物理平台。
o There may be scenarios where multiple vNSFs collectively perform the security policies needed.
o 可能存在多个VNSF共同执行所需安全策略的场景。
+------------------------+
| I2NSF Controller |
+------------------------+
^ ^
| |
+-----------+ +------------+
| |
v v
+ - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - +
| NSF-A +--------------+ | | NSF-B +--------------+ |
| | NSF Manager | | | | NSF Manager | |
| +--------------+ | | +--------------+ |
| + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + |
| |+---------+ +---------+| | | |+---------+ +---------+| |
| || NSF-A#1 | ... | NSF-A#n || | | || NSF-B#1 | ... | NSF-B#m || |
| |+---------+ +---------+| | | |+---------+ +---------+| |
| | NSF-A cluster | | | | NSF-B cluster | |
| + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + |
+ - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - +
+------------------------+
| I2NSF Controller |
+------------------------+
^ ^
| |
+-----------+ +------------+
| |
v v
+ - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - +
| NSF-A +--------------+ | | NSF-B +--------------+ |
| | NSF Manager | | | | NSF Manager | |
| +--------------+ | | +--------------+ |
| + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + |
| |+---------+ +---------+| | | |+---------+ +---------+| |
| || NSF-A#1 | ... | NSF-A#n || | | || NSF-B#1 | ... | NSF-B#m || |
| |+---------+ +---------+| | | |+---------+ +---------+| |
| | NSF-A cluster | | | | NSF-B cluster | |
| + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + |
+ - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - +
Figure 2: Cluster of NSF Instantiations Management
图2:NSF实例化管理集群
There are three basic models of consistency:
有三种基本的一致性模型：
o centralized, which uses a single manager to impose behavior
o 集中式，使用单个管理器强制实施行为
o decentralized, in which managers make decisions without being aware of each other (i.e., managers do not exchange information)
o 分散式管理，管理者在相互不知情的情况下做出决策（即，管理者不交换信息）
o distributed, in which managers make explicit use of information exchange to arrive at a decision
o 分布式的，管理者明确利用信息交换达成决策
This document does NOT make a recommendation on which of the above three models to use. I2NSF Policy Rules, coupled with an appropriate management strategy, is applicable to the design and integration of any of the above three consistency models.
本文件不建议使用上述三种模型中的哪一种。I2NSF策略规则以及适当的管理策略适用于上述三种一致性模型的设计和集成。
Even though security functions come in a variety of form factors and have different features, provisioning to flow-based NSFs can be standardized by using policy rules.
尽管安全功能有多种形式，并具有不同的功能，但可以通过使用策略规则对基于流的NSF进行标准化配置。
In this version of I2NSF, policy rules are limited to imperative paradigms. I2NSF is using an Event-Condition-Action (ECA) policy, where:
在此版本的I2NSF中，策略规则仅限于命令式范例。I2NSF正在使用事件条件操作（ECA）策略，其中：
o An Event clause is used to trigger the evaluation of the Condition clause of the I2NSF Policy Rule.
o 事件子句用于触发对I2NSF策略规则的条件子句的求值。
o A Condition clause is used to determine whether or not the set of Actions in the I2NSF Policy Rule can be executed or not.
o Condition子句用于确定I2NSF策略规则中的操作集是否可以执行。
o An Action clause defines the type of operations that may be performed on this packet or flow.
o Action子句定义可在此数据包或流上执行的操作类型。
Each of the above three clauses are defined to be Boolean clauses. This means that each is a logical statement that evaluates to either TRUE or FALSE.
上述三个子句都定义为布尔子句。这意味着每个语句都是一个逻辑语句，其计算结果为TRUE或FALSE。
The above concepts are described in detail in [I2NSF-CAPABILITIES].
[I2NSF-CAPABILITIES]中详细描述了上述概念。
This layer is for the user's network management system to express and monitor the needed flow security policies for their specific flows.
这一层用于用户的网络管理系统，以表达和监控其特定流所需的流安全策略。
Some customers may not have the requisite security skills to express security requirements or policies that are precise enough to implement in an NSF. These customers may instead express expectations (e.g., goals or intent) of the functionality desired by their security policies. Customers may also express guidelines, such as which types of destinations are (or are not) allowed for certain users. As a result, there could be different levels of content and abstractions used in Service Layer policies. Here are some examples of more abstract security policies that can be developed based on the I2NSF-defined Customer-Facing Interface:
一些客户可能没有必要的安全技能来表达安全需求或策略，这些需求或策略足够精确，无法在NSF中实施。这些客户可能会转而表达其安全策略所需功能的期望（例如，目标或意图）。客户还可以表达指导原则，例如某些用户允许（或不允许）哪些类型的目的地。因此，服务层策略中可能会使用不同级别的内容和抽象。以下是一些可以基于I2NSF定义的面向客户接口开发的更抽象的安全策略示例：
o Enable Internet access for authenticated users
o 为经过身份验证的用户启用Internet访问
o Any operation on a HighValueAsset must use the corporate network
o 对高价值资产的任何操作都必须使用公司网络
o The use of FTP from any user except the CxOGroup must be audited
o 必须审核除CxOGroup之外的任何用户使用FTP的情况
o Streaming media applications are prohibited on the corporate network during business hours
o 在营业时间内，禁止在公司网络上使用流媒体应用程序
o Scan email for malware detection; protect traffic to corporate network with integrity and confidentiality
o 扫描电子邮件以检测恶意软件；以完整性和保密性保护到公司网络的流量
o Remove tracking data from Facebook [website = *.facebook.com]
o 从Facebook删除跟踪数据[website=*.Facebook.com]
One flow policy over the Customer-Facing Interface may need multiple NSFs at various locations to achieve the desired enforcement. Some flow security policies from users may not be granted because of resource constraints. [I2NSF-DEMO] describes an implementation of translating a set of 1) user policies to flow policies and 2) flow policies to individual NSFs.
面向客户的接口上的一个流策略可能需要多个NSF位于不同的位置，以实现所需的实施。由于资源限制，可能无法授予用户的某些流安全策略。[I2NSF-DEMO]描述了将一组1）用户策略转换为流策略和2）流策略转换为单个NSF的实现。
I2NSF will first focus on user policies that can be modeled as closely as possible to the flow security policies used by individual NSFs. An I2NSF user flow policy should be similar in structure to the structure of an I2NSF Policy Rule, but with more of a user-oriented expression for the packet content, the context, and other parts of an ECA policy rule. This enables the user to construct an I2NSF Policy Rule without having to know the exact syntax of the desired content (e.g., actual tags or addresses) to match in the packets. For example, when used in the context of policy rules over the Client-Facing Interface:
I2NSF将首先关注用户策略，这些用户策略可以尽可能与单个NSF使用的流安全策略建模。I2NSF用户流策略的结构应与I2NSF策略规则的结构相似，但更多的是针对数据包内容、上下文和ECA策略规则的其他部分的面向用户的表达式。这使得用户能够构造I2NSF策略规则，而不必知道要在分组中匹配的所需内容（例如，实际标记或地址）的确切语法。例如，当在面向客户端的接口上的策略规则上下文中使用时：
o An Event can be "the client has passed the AAA process"
o 事件可以是“客户端已通过AAA进程”
o A Condition can be matching the user identifier or from specific ingress or egress points
o 条件可以与用户标识符匹配，也可以来自特定的入口或出口点
o An Action can be establishing an IPsec tunnel
o 操作可以是建立IPsec隧道
The NSF-Facing Interface is to pass explicit rules to individual NSFs to treat packets, as well as methods to monitor the execution status of those functions.
面向NSF的接口是将显式规则传递给各个NSF以处理数据包，以及监视这些函数的执行状态的方法。
Here are some examples of Events over the NSF-Facing Interface:
以下是一些面向NSF的接口上的事件示例：
o time == 08:00
o 时间==08:00
o notification that a NSF state changes from standby to active
o NSF状态从待机变为活动的通知
o user logon or logoff
o 用户登录或注销
Here are some examples of Conditions over the NSF-Facing Interface:
以下是一些面向NSF接口的条件示例：
o Packet content values that look for one or more packet headers, data from the packet payload, bits in the packet, or data that are derived from the packet.
o 数据包内容值，用于查找一个或多个数据包头、来自数据包有效负载的数据、数据包中的位或来自数据包的数据。
o Context values that are based on measured and/or inferred knowledge, which can be used to define the state and environment in which a managed entity exists or has existed. In addition to state data, this includes data from sessions, direction of the traffic, time, and geo-location information. State refers to the behavior of a managed entity at a particular point in time. Hence, it may refer to situations in which multiple pieces of information that are not available at the same time must be analyzed. For example, tracking established TCP connections (connections that have gone through the initial three-way handshake).
o 基于测量和/或推断知识的上下文值，可用于定义托管实体存在或已存在的状态和环境。除了状态数据外，还包括来自会话、交通方向、时间和地理位置信息的数据。状态是指受管实体在特定时间点的行为。因此，它可能指的是必须分析同时不可用的多条信息的情况。例如，跟踪已建立的TCP连接（经过初始三方握手的连接）。
Actions to individual flow-based NSFs include:
针对单个基于流的NSF的措施包括：
o Actions performed on ingress packets, such as pass, drop, rate limiting, and mirroring.
o 对入口数据包执行的操作，如通过、丢弃、速率限制和镜像。
o Actions performed on egress packets, such as invoke signaling, tunnel encapsulation, packet forwarding, and/or transformation.
o 对出口数据包执行的操作，例如调用信令、隧道封装、数据包转发和/或转换。
o Applying a specific functional profile or signature -- e.g., an IPS Profile, a signature file, an anti-virus file, or a URL filtering file. Many flow-based NSFs utilize profile and/or signature files to achieve more effective threat detection and prevention. It is not uncommon for an NSF to apply different profiles and/or signatures for different flows. Some profiles/ signatures do not require any knowledge of past or future activities, while others are stateful and may need to maintain state for a specific length of time.
o 应用特定的功能配置文件或签名--例如IPS配置文件、签名文件、防病毒文件或URL过滤文件。许多基于流的NSF利用配置文件和/或签名文件来实现更有效的威胁检测和预防。NSF为不同的流应用不同的配置文件和/或签名并不少见。一些配置文件/签名不需要了解过去或未来的活动，而另一些配置文件/签名是有状态的，可能需要在特定时间内保持状态。
The functional profile or signature file is one of the key properties that determine the effectiveness of the NSF and is mostly NSF specific today. The rulesets and software interfaces of I2NSF aim to specify the format to pass profile and signature files while supporting specific functionalities of each.
功能配置文件或签名文件是决定NSF有效性的关键属性之一，目前主要针对NSF。I2NSF的规则集和软件接口旨在指定传递配置文件和签名文件的格式，同时支持每个配置文件和签名文件的特定功能。
Policy consistency among multiple security function instances is very critical because security policies are no longer maintained by one central security device; instead, they are enforced by multiple security functions instantiated at various locations.
多个安全功能实例之间的策略一致性非常关键，因为安全策略不再由一个中央安全设备维护；相反，它们由在不同位置实例化的多个安全函数强制执行。
Policy rules are very different from Access Control Lists (ACLs). An ACL is NOT a policy. Rather, policies are used to manage the construction and life cycle of an ACL.
策略规则与访问控制列表（ACL）非常不同。ACL不是策略。相反，策略用于管理ACL的构造和生命周期。
[ACL-YANG] has defined rules for ACLs supported by most routers/ switches that forward packets based on their L2, L3, or sometimes L4 headers. The actions for ACLs include Pass, Drop, or Redirect.
[ACL-YANG]为大多数路由器/交换机支持的ACL定义了规则，这些路由器/交换机根据其L2、L3或有时L4头转发数据包。ACL的操作包括传递、删除或重定向。
The functional profiles (or signatures) for NSFs are not present in [ACL-YANG] because the functional profiles are unique to specific NSFs. For example, most IPS/IDS implementations have their proprietary functions/profiles. One of the goals of I2NSF is to define a common envelope format for exchanging or sharing profiles among different organizations to achieve more effective protection against threats.
[ACL-YANG]中不存在NSF的功能配置文件（或签名），因为功能配置文件是特定NSF独有的。例如，大多数IPS/IDS实现都有其专有的功能/配置文件。I2NSF的目标之一是定义一种通用信封格式，用于在不同组织之间交换或共享配置文件，以实现更有效的威胁防护。
The "packet content matching" of the I2NSF policies should not only include the matching criteria specified by [ACL-YANG] but also the L4-L7 fields depending on the NSFs selected.
I2NSF策略的“数据包内容匹配”不仅应包括[ACL-YANG]指定的匹配标准，还应包括L4-L7字段，具体取决于选择的NSF。
Some flow-based NSFs need matching criteria that include the context associated with the packets. This may also include metadata.
一些基于流的NSF需要包括与数据包关联的上下文的匹配条件。这也可能包括元数据。
The I2NSF "actions" should extend the actions specified by [ACL-YANG] to include applying statistics functions, threat profiles, or signature files that clients provide.
I2NSF“操作”应扩展[ACL-YANG]指定的操作，以包括应用客户端提供的统计功能、威胁配置文件或签名文件。
It is very possible that the underlay network (or provider network) does not have the capability or resources to enforce the flow security policies requested by the overlay network (or enterprise network). Therefore, it is required that the I2NSF system support dynamic discovery capabilities, as well as a query mechanism, so that the I2NSF system can expose appropriate security services using I2NSF capabilities. This may also be used to support negotiation between a user and the I2NSF system. Such dynamic negotiation facilitates the delivery of the required security service(s). The outcome of the negotiation would feed the I2NSF Management System, which would then dynamically allocate appropriate NSFs (along with any resources needed by the allocated NSFs) and configure the set of security services that meet the requirements of the user.
很可能底层网络（或提供商网络）没有能力或资源来实施覆盖网络（或企业网络）请求的流安全策略。因此，需要I2NSF系统支持动态发现功能以及查询机制，以便I2NSF系统可以使用I2NSF功能公开适当的安全服务。这也可用于支持用户与I2NSF系统之间的协商。这种动态协商有助于提供所需的安全服务。协商的结果将提供给I2NSF管理系统，然后该系统将动态分配适当的NSF（以及分配的NSF所需的任何资源），并配置满足用户需求的安全服务集。
When an NSF cannot perform the desired provisioning (e.g., due to resource constraints), it must inform the I2NSF Management System. The protocol needed for this security function/capability negotiation
当NSF无法执行所需的供应（例如，由于资源限制），它必须通知I2NSF管理系统。此安全功能/能力协商所需的协议
may be somewhat correlated to the dynamic service parameter negotiation procedure described in [RFC7297]. The Connectivity Provisioning Profile (CPP) template, even though currently covering only connectivity requirements, includes security clauses such as isolation requirements and non-via nodes. Hence, it could be extended as a basis for the negotiation procedure. Likewise, the companion Connectivity Provisioning Negotiation Protocol (CPNP) could be a candidate for the negotiation procedure.
可能在某种程度上与[RFC7297]中描述的动态服务参数协商过程相关。连接性配置文件（CPP）模板，尽管目前仅涵盖连接性要求，但包括诸如隔离要求和非通过节点等安全条款。因此，可以将其作为谈判程序的基础加以扩展。同样，伴随连接供应协商协议（CPNP）也可以作为协商过程的候选协议。
"Security-as-a-Service" would be a typical example of the kind of (CPP-based) negotiation procedures that could take place between a corporate customer and a service provider. However, more security-specific parameters have to be considered.
“安全即服务”是公司客户和服务提供商之间可能发生的（基于CPP的）谈判程序的典型例子。但是，必须考虑更多特定于安全的参数。
[I2NSF-CAPABILITIES] describes the concepts of capabilities in detail.
[I2NSF-CAPABILITIES]详细描述了功能的概念。
There are many types of flow-based NSFs. Firewall, IPS, and IDS are the commonly deployed flow-based NSFs. However, the differences among them are definitely blurring, due to more powerful technology, integration of platforms, and new threats. Basic types of flow-based NSFs include:
有许多类型的基于流的NSF。防火墙、IPS和IDS是通常部署的基于流的NSF。然而，由于更强大的技术、平台集成和新的威胁，它们之间的差异显然正在模糊。基于流的NSF的基本类型包括：
o Firewall -- A device or a function that analyzes packet headers and enforces policy based on protocol type, source address, destination address, source port, destination port, and/or other attributes of the packet header. Packets that do not match policy are rejected. Note that additional functions, such as logging and notification of a system administrator, could optionally be enforced as well.
o 防火墙——根据协议类型、源地址、目标地址、源端口、目标端口和/或数据包头的其他属性，分析数据包头并实施策略的设备或功能。拒绝与策略不匹配的数据包。请注意，还可以选择强制执行其他功能，如系统管理员的日志记录和通知。
o IDS (Intrusion Detection System) -- A device or function that analyzes packets, both header and payload, looking for known events. When a known event is detected, a log message is generated detailing the event. Note that additional functions, such as notification of a system administrator, could optionally be enforced as well.
o IDS（入侵检测系统）——一种分析数据包（包括报头和有效载荷）以查找已知事件的设备或功能。当检测到已知事件时，将生成一条详细记录该事件的日志消息。请注意，还可以选择强制执行其他功能，例如通知系统管理员。
o IPS (Intrusion Prevention System) -- A device or function that analyzes packets, both header and payload, looking for known events. When a known event is detected, the packet is rejected. Note that additional functions, such as logging and notification of a system administrator, could optionally be enforced as well.
o IPS（入侵防御系统）——一种分析数据包（包括报头和有效载荷）以查找已知事件的设备或功能。当检测到已知事件时，数据包被拒绝。请注意，还可以选择强制执行其他功能，如系统管理员的日志记录和通知。
Flow-based NSFs differ in the depth of packet header or payload they can inspect, the various session/context states they can maintain, and the specific profiles and the actions they can apply. An example of a session is as follows: allowing outbound connection requests and only allowing return traffic from the external network.
基于流的NSF在可检查的数据包报头或有效负载深度、可维护的各种会话/上下文状态以及可应用的特定概要文件和操作方面有所不同。会话的示例如下：允许出站连接请求，只允许从外部网络返回流量。
Developers can register their NSFs using packet content matching categories. The Inter-Domain Routing (IDR) Flow Specification [RFC5575] has specified 12 different packet header matching types.
开发人员可以使用数据包内容匹配类别注册他们的NSF。域间路由（IDR）流规范[RFC5575]指定了12种不同的包头匹配类型。
IP Flow Information Export (IPFIX) data [IPFIX-D] defines IP flow information and mechanisms to transmit such information. This includes flow attributes as well as information about the metering and exporting processes. Such information may be stored in an IPFIX registry [IPFIX-R]. As such, IPFIX information should be considered when defining categories of registration information.
IP流信息导出（IPFIX）数据[IPFIX-D]定义IP流信息和传输此类信息的机制。这包括流属性以及有关计量和导出过程的信息。此类信息可存储在IPFIX注册表[IPFIX-R]中。因此，在定义注册信息类别时，应考虑IPFIX信息。
More packet content matching types have been proposed in the IDR WG. I2NSF should reuse the packet matching types being specified as much as possible. More matching types might be added for flow-based NSFs.
IDR WG中提出了更多的数据包内容匹配类型。I2NSF应尽可能重用指定的数据包匹配类型。可以为基于流的NSF添加更多匹配类型。
Figures 3-6 below list the applicable packet content categories that can be potentially used as packet matching types by flow-based NSFs:
下图3-6列出了基于流的NSF可能用作数据包匹配类型的适用数据包内容类别：
+-----------------------------------------------------------+
| Packet Content Matching Capability Index |
+---------------+-------------------------------------------+
| Layer 2 | Layer 2 header fields: |
| Header | Source |
| | Destination |
| | s-VID |
| | c-VID |
| | Ethertype |
|---------------+-------------------------------------------+
| Layer 3 | Layer 3 header fields: |
| | protocol |
| IPv4 Header | dest port |
| | src port |
| | src address |
| | dest address |
| | dscp |
| | length |
| | flags |
| | ttl |
+-----------------------------------------------------------+
| Packet Content Matching Capability Index |
+---------------+-------------------------------------------+
| Layer 2 | Layer 2 header fields: |
| Header | Source |
| | Destination |
| | s-VID |
| | c-VID |
| | Ethertype |
|---------------+-------------------------------------------+
| Layer 3 | Layer 3 header fields: |
| | protocol |
| IPv4 Header | dest port |
| | src port |
| | src address |
| | dest address |
| | dscp |
| | length |
| | flags |
| | ttl |
| IPv6 Header | |
| | protocol/nh |
| | src port |
| | dest port |
| | src address |
| | dest address |
| | length |
| | traffic class |
| | hop limit |
| | flow label |
| | dscp |
|---------------+-------------------------------------------+
| Layer 4 | Layer 4 header fields: |
| TCP | Port |
| SCTP | syn |
| DCCP | ack |
| | fin |
| | rst |
| | ? psh |
| | ? urg |
| | ? window |
| | sockstress |
| | Note: bitmap could be used to |
| | represent all the fields |
| UDP | |
| | flood abuse |
| | fragment abuse |
| | Port |
|---------------+-------------------------------------------+
| HTTP layer | |
| | | hash collision |
| | | http - get flood |
| | | http - post flood |
| | | http - random/invalid url |
| | | http - slowloris |
| | | http - slow read |
| | | http - r-u-dead-yet (rudy) |
| | | http - malformed request |
| | | http - xss |
| | | https - ssl session exhaustion |
| IPv6 Header | |
| | protocol/nh |
| | src port |
| | dest port |
| | src address |
| | dest address |
| | length |
| | traffic class |
| | hop limit |
| | flow label |
| | dscp |
|---------------+-------------------------------------------+
| Layer 4 | Layer 4 header fields: |
| TCP | Port |
| SCTP | syn |
| DCCP | ack |
| | fin |
| | rst |
| | ? psh |
| | ? urg |
| | ? window |
| | sockstress |
| | Note: bitmap could be used to |
| | represent all the fields |
| UDP | |
| | flood abuse |
| | fragment abuse |
| | Port |
|---------------+-------------------------------------------+
| HTTP layer | |
| | | hash collision |
| | | http - get flood |
| | | http - post flood |
| | | http - random/invalid url |
| | | http - slowloris |
| | | http - slow read |
| | | http - r-u-dead-yet (rudy) |
| | | http - malformed request |
| | | http - xss |
| | | https - ssl session exhaustion |
+---------------+----------+--------------------------------+
| IETF PCP | Configurable |
| | Ports |
+---------------+-------------------------------------------+
| IETF TRAM | profile |
+---------------+-------------------------------------------+
+---------------+----------+--------------------------------+
| IETF PCP | Configurable |
| | Ports |
+---------------+-------------------------------------------+
| IETF TRAM | profile |
+---------------+-------------------------------------------+
Notes: DCCP: Datagram Congestion Control Protocol PCP: Port Control Protocol TRAM: TURN Revised and Modernized, where TURN stands for Traversal Using Relays around NAT
注：DCCP：数据报拥塞控制协议PCP：端口控制协议TRAM：TURN经过修订和现代化，其中TURN表示使用NAT周围的中继进行遍历
Figure 3: Packet Content Matching Capability Index
图3：数据包内容匹配能力索引
+-----------------------------------------------------------+
| Context Matching Capability Index |
+---------------+-------------------------------------------+
| Session | Session State, |
| | Bidirectional State |
+---------------+-------------------------------------------+
| Time | Time span |
| | Time occurrence |
+---------------+-------------------------------------------+
| Events | Event URL, variables |
+---------------+-------------------------------------------+
| Location | Text string, GPS coords, URL |
+---------------+-------------------------------------------+
| Connection | Internet (unsecured), Internet |
| Type | (secured by VPN, etc.), Intranet, ... |
+---------------+-------------------------------------------+
| Direction | Inbound, Outbound |
+---------------+-------------------------------------------+
| State | Authentication State |
| | Authorization State |
| | Accounting State |
| | Session State |
+---------------+-------------------------------------------+
+-----------------------------------------------------------+
| Context Matching Capability Index |
+---------------+-------------------------------------------+
| Session | Session State, |
| | Bidirectional State |
+---------------+-------------------------------------------+
| Time | Time span |
| | Time occurrence |
+---------------+-------------------------------------------+
| Events | Event URL, variables |
+---------------+-------------------------------------------+
| Location | Text string, GPS coords, URL |
+---------------+-------------------------------------------+
| Connection | Internet (unsecured), Internet |
| Type | (secured by VPN, etc.), Intranet, ... |
+---------------+-------------------------------------------+
| Direction | Inbound, Outbound |
+---------------+-------------------------------------------+
| State | Authentication State |
| | Authorization State |
| | Accounting State |
| | Session State |
+---------------+-------------------------------------------+
Note: These fields are used to provide context information for I2NSF Policy Rules to make decisions on how to handle traffic. For example, GPS coordinates define the location of the traffic that is entering and exiting an I2NSF system; this enables the developer to apply different rules for ingress and egress traffic handling.
注意：这些字段用于为I2NSF策略规则提供上下文信息，以决定如何处理流量。例如，GPS坐标定义了进出I2NSF系统的交通的位置；这使开发人员能够为入口和出口流量处理应用不同的规则。
Figure 4: Context Matching Capability Index
图4：上下文匹配能力索引
+-----------------------------------------------------------+
| Action Capability Index |
+---------------+-------------------------------------------+
| Ingress port | SFC header termination, |
| | VxLAN header termination |
+---------------+-------------------------------------------+
| | Pass |
| Actions | Deny |
| | Mirror |
| | Simple Statistics: Count (X min; Day;..)|
| | Client-Specified Functions: URL |
+---------------+-------------------------------------------+
| Egress | Encap SFC, VxLAN, or other header |
+---------------+-------------------------------------------+
+-----------------------------------------------------------+
| Action Capability Index |
+---------------+-------------------------------------------+
| Ingress port | SFC header termination, |
| | VxLAN header termination |
+---------------+-------------------------------------------+
| | Pass |
| Actions | Deny |
| | Mirror |
| | Simple Statistics: Count (X min; Day;..)|
| | Client-Specified Functions: URL |
+---------------+-------------------------------------------+
| Egress | Encap SFC, VxLAN, or other header |
+---------------+-------------------------------------------+
Note: SFC: Service Function Chaining
注：SFC：服务功能链接
Figure 5: Action Capability Index
图5：行动能力指数
+-----------------------------------------------------------+
| Functional Profile Index |
+---------------+-------------------------------------------+
| Profile types | name, type, or flexible |
| | |
| Signature | Profile/signature URL command for the |
| | I2NSF Controller to enable/disable |
+---------------+-------------------------------------------+
+-----------------------------------------------------------+
| Functional Profile Index |
+---------------+-------------------------------------------+
| Profile types | name, type, or flexible |
| | |
| Signature | Profile/signature URL command for the |
| | I2NSF Controller to enable/disable |
+---------------+-------------------------------------------+
Figure 6: Functional Profile Index
图6：功能配置文件索引
Management of NSFs include:
国家科学基金的管理包括：
o Life-cycle management and resource management of NSFs
o NSF的生命周期管理和资源管理
o Configuration of devices, such as address configuration, device internal attributes configuration, etc.
o 设备配置，如地址配置、设备内部属性配置等。
o Signaling
o 信号
o Policy rules provisioning
o 策略规则设置
Currently, I2NSF only focuses on the policy rule provisioning part.
目前，I2NSF只关注策略规则提供部分。
The configuration, control, and monitoring of NSFs provide access to and information about security functions that are critical for delivering network security and for protecting end-to-end traffic. Therefore, it is important that the messages that are exchanged within this architecture utilize a trustworthy, robust, and fully secure communication channel. The mechanisms adopted within the solution space must include proper secure communication channels that are carefully specified for carrying the controlling and monitoring information between the NSFs and their management entity or entities. The threats associated with remotely managed NSFs are discussed in Section 4, and solutions must address those concerns.
NSF的配置、控制和监控提供了对安全功能的访问和信息，这些功能对于提供网络安全和保护端到端流量至关重要。因此，在此体系结构中交换的消息必须利用可靠、健壮和完全安全的通信通道。解决方案空间内采用的机制必须包括适当的安全通信通道，这些通道经过仔细指定，用于在NSF及其管理实体之间传输控制和监控信息。第4节讨论了与远程管理NSF相关的威胁，解决方案必须解决这些问题。
This framework is intended for enterprise users, with or without cloud service offerings. Privacy of users must be provided by using existing standard mechanisms, such as encryption; anonymization of data should also be done if possible (depending on the transport used). Such mechanisms require confidentiality and integrity.
此框架适用于企业用户，无论是否提供云服务。用户的隐私必须通过使用现有的标准机制提供，如加密；如果可能，还应进行数据匿名化（取决于所使用的传输）。这种机制要求保密和完整。
This document has no IANA actions.
本文档没有IANA操作。
[IPFIX-D] "IP Flow Information Export (ipfix)", <https://datatracker.ietf.org/wg/ipfix/documents/>.
[IPFIX-D]“IP流信息导出（IPFIX）”<https://datatracker.ietf.org/wg/ipfix/documents/>.
[IPFIX-R] IANA, "IP Flow Information Export (IPFIX) Entities", <https://www.iana.org/assignments/ipfix>.
[IPFIX-R]IANA，“IP流信息导出（IPFIX）实体”<https://www.iana.org/assignments/ipfix>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, <https://www.rfc-editor.org/info/rfc5575>.
[RFC5575]Marques，P.，Sheth，N.，Raszuk，R.，Greene，B.，Mauch，J.，和D.McPherson，“流量规范规则的传播”，RFC 5575，DOI 10.17487/RFC5575，2009年8月<https://www.rfc-editor.org/info/rfc5575>.
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-editor.org/info/rfc7297>.
[RFC7297]Boucadair，M.，Jacquenet，C.和N.Wang，“IP连接配置文件（CPP）”，RFC 7297，DOI 10.17487/RFC7297，2014年7月<https://www.rfc-editor.org/info/rfc7297>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[ACL-YANG] Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, "Network Access Control List (ACL) YANG Data Model", Work in Progress, draft-ietf-netmod-acl-model-15, January 2018.
[ACL-YANG]Jethanandani，M.，Huang，L.，Agarwal，S.，和D.Blair，“网络访问控制列表（ACL）YANG数据模型”，正在进行的工作，草稿-ietf-netmod-ACL-Model-15，2018年1月。
[I2NSF-ATTESTATION] Pastor, A., Lopez, D., and A. Shaw, "Remote Attestation Procedures for Network Security Functions (NSFs) through the I2NSF Security Controller", Work in Progress, draft-pastor-i2nsf-nsf-remote-attestation-02, September 2017.
[I2NSF-认证]Pastor，A.，Lopez，D.和A.Shaw，“通过I2NSF安全控制器的网络安全功能（nsf）远程认证程序”，正在进行的工作，草稿-Pastor-I2NSF-nsf-Remote-Detection-022017年9月。
[I2NSF-CAPABILITIES] Xia, L., Strassner, J., Basile, C., and D. Lopez, "Information Model of NSFs Capabilities", Work in Progress, draft-i2nsf-capability-00, September 2017.
[I2NSF-capability]Xia，L.，Strassner，J.，Basile，C.，和D.Lopez，“国家科学基金能力的信息模型”，在建工程，草案-I2NSF-capability-00，2017年9月。
[I2NSF-DEMO] Xie, Y., Xia, L., and J. Wu, "Interface to Network Security Functions Demo Outline Design", Work in Progress, draft-xie-i2nsf-demo-outline-design-00, April 2015.
[I2NSF-DEMO]Xie，Y.，Xia，L.，和J.Wu，“网络安全功能接口演示大纲设计”，正在进行的工作，草稿-Xie-I2NSF-DEMO-Outline-Design-00，2015年4月。
[I2NSF-TERMS] Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Birkholz, "Interface to Network Security Functions (I2NSF) Terminology", Work in Progress, draft-ietf-i2nsf-terminology-05, January 2018.
[I2NSF-TERMS]Hares，S.，Strassner，J.，Lopez，D.，Xia，L.，和H.Birkholz，“网络安全功能接口（I2NSF）术语”，正在进行的工作，草案-ietf-I2NSF-Terminology-05，2018年1月。
[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., and J. Jeong, "Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases", RFC 8192, DOI 10.17487/RFC8192, July 2017, <https://www.rfc-editor.org/info/rfc8192>.
[RFC8192]Hares，S.，Lopez，D.，Zarny，M.，Jacquenet，C.，Kumar，R.，和J.Jeong，“网络安全功能接口（I2NSF）：问题陈述和用例”，RFC 8192，DOI 10.17487/RFC8192，2017年7月<https://www.rfc-editor.org/info/rfc8192>.
Acknowledgements
致谢
This document includes significant contributions from Christian Jacquenet (Orange), Seetharama Rao Durbha (Cablelabs), Mohamed Boucadair (Orange), Ramki Krishnan (Dell), Anil Lohiya (Juniper Networks), Joe Parrott (BT), Frank Xialing (Huawei), and XiaoJun Zhuang (China Mobile).
本文件包括Christian Jacquenet（橙色）、Seetharama Rao Durbha（Cablelabs）、Mohamed Boucadair（橙色）、Ramki Krishnan（戴尔）、Anil Lohiya（Juniper Networks）、Joe Parrott（BT）、Frank Xialing（华为）和庄晓军（中国移动）的重要贡献。
Some of the results leading to this work have received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grant agreement no. 611458.
根据第611458号赠款协议，导致这项工作的一些成果得到了欧盟第七框架方案（FP7/2007-2013）的资助。
Authors' Addresses
作者地址
Diego R. Lopez Telefonica I+D Editor Jose Manuel Lara, 9 Seville, 41013 Spain
Diego R.Lopez Telefonica I+D编辑Jose Manuel Lara，西班牙塞维利亚9号，41013
Email: diego.r.lopez@telefonica.com
Email: diego.r.lopez@telefonica.com
Edward Lopez Curveball Networks Chantilly, Virginia United States of America
爱德华·洛佩兹曲线球网络美国弗吉尼亚州尚蒂利
Email: ed@curveballnetworks.com
Email: ed@curveballnetworks.com
Linda Dunbar Huawei Technologies United States of America
美国华为技术公司琳达·邓巴
Email: Linda.Dunbar@huawei.com
Email: Linda.Dunbar@huawei.com
John Strassner Huawei Technologies Santa Clara, CA United States of America
美国加利福尼亚州圣克拉拉市华为技术公司John Strassner
Email: John.sc.Strassner@huawei.com
Email: John.sc.Strassner@huawei.com
Rakesh Kumar Juniper Networks United States of America
Rakesh Kumar Juniper Networks美利坚合众国
Email: rakeshkumarcloud@gmail.com
Email: rakeshkumarcloud@gmail.com