[要約] RFC 8329は、ネットワークセキュリティ機能へのインターフェースのためのフレームワークを提供しています。その目的は、ネットワークセキュリティ機能の統合と相互運用性を向上させることです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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）の展開によって暗示される脅威の分析が含まれます。また、NSFの機能を制限する可能性のある制約を回避しながら、I2NSFがソフトウェア定義ネットワーク（SDN）およびネットワーク機能仮想化（NFV）環境でテクノロジーおよびベンダーに依存しない方法でセキュリティ機能を実装する方法についても説明します。
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]は、Network Security Functionsシステムへのインターフェースの動機と問題空間についても説明しています。
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：分散型サービス拒否のOpen Threat Signaling 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 NSFに面したインターフェイス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 | ...
+-------+ +-------+ +-------+ +-------+
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 一連の特定の条件に一致するフローをブロックするためにアンダーレイネットワークに要求を送信するIoT管理システム。
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-Facingインターフェイス（略してNSF-Facingインターフェイス）は、1つ以上の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ポリシールールは、このインターフェイスグループを一貫した方法で変更する1つの方法を表します。アプリケーションと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. 監視インターフェイス：1つ以上の選択されたNSFから監視情報を取得するためにI2NSF管理システムによって使用されるインターフェイスグループ。このインターフェイスグループの各インターフェイスは、クエリベースまたはレポートベースのインターフェイスにすることができます。違いは、情報を取得するためにレポートベースのインターフェイスがNSFによって使用されるのに対して、クエリベースのインターフェイスはI2NSF管理システムによって使用されることです。このインターフェイスグループの機能は、SYSLOGやDOTSなどの他のプロトコルで定義することもできます。 I2NSF管理システムは、情報の受信に基づいて1つ以上のアクションを実行できます。これは、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-Facingインターフェイスを開発します。フローベースのNSFの一般的な特性は、受信したパケットのコンテンツ（ヘッダー/ペイロードなど）やコンテキスト（セッション状態や認証状態など）に基づいてパケットを処理することです。この機能は、I2NSFの動作を定義するための要件の1つです。
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 Registry via the I2NSF Registration Interface, so that interested management and control entities may be made aware of them.
NSFの機能は、事前構成するか、I2NSF登録インターフェースを介して動的に取得できます。コンシューマに公開されている新しい機能をNSFに追加する場合、その新しい機能の機能をI2NSF登録インターフェイスを介して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ポリシールールおよび攻撃されたユーザーのアプリケーションにアクセスしたり、偽のIDを使用してセキュリティ機能の外部にネットワークトラフィックを生成したりする可能性があります。
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実装など）を変更して、1つ以上の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は、直接またはパケットが関連付けられているセッションのコンテキストで、ネットワークを通過するパケットを検査する最終的にはパケット処理エンジンです。目標は、機能的な機能を制限する可能性のある制約を回避しながら、レガシー、SDN、NFV環境内での統合を支援するNSFへの実行可能なインターフェースを作成することです。
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-ATTESTATION]で説明されているように、接続は安全であるだけでなく、ユーザーとI2NSFコントローラー間の相互認証にバインドされる必要があるという意味で信頼されることを目的としています。唯一可能な例外は、必要な保証レベルが低い場合です（[I2NSF-ATTESTATION]のセクション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コントローラーとNSFを接続するネットワークは、データトラフィックを伝送するネットワークと同じにすることも、管理目的専用のネットワークにすることもできます。どちらの場合も、障害、輻輳、またはその他の理由により、パケット損失が発生する可能性があります。
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 安全な外部ネットワーク接続を介して到達する1つ以上の外部管理ドメインで1つ以上の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 管理ドメインが1つしかない閉じた環境。そのような環境は、より**分離された**環境を提供しますが、オープン環境に存在する同じセットの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で説明されているトラステッド接続メカニズムを使用します。これらのメカニズムに従って、接続は適切に検証されたピアIDの使用に依存する必要があります（たとえば、認証、承認、およびアカウンティング（AAA）フレームワークを通じて）。 ID管理機能の実装と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が指定されている異なる役割を反映するため）。したがって、堅牢なIDの使用に加えて、ロールを使用して同じ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 1つの単一の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に移動されるときに、1つの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 | |
| + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + |
+ - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - +
Figure 2: Cluster of NSF Instantiations Management
図2：NSFインスタンス化管理のクラスター
There are three basic models of consistency:
整合性の3つの基本モデルがあります。
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.
このドキュメントでは、上記の3つのモデルのどれを使用するかについては推奨していません。 I2NSFポリシールールは、適切な管理戦略と相まって、上記の3つの整合性モデルの設計と統合に適用できます。
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は、Event-Condition-Action（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.
上記の3つの句はそれぞれブール句として定義されています。これは、それぞれが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 認証済みユーザーのインターネットアクセスを有効にする
o Any operation on a HighValueAsset must use the corporate network
o HighValueAssetでの操作では、企業ネットワークを使用する必要があります
o The use of FTP from any user except the CxOGroup must be audited o Streaming media applications are prohibited on the corporate network during business hours
o CxOGroup以外のユーザーからのFTPの使用は監査する必要があります。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.
Customer-Facing Interface上の1つのフローポリシーでは、目的の適用を実現するために、さまざまな場所で複数の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-Facingインターフェイスは、明示的なルールを個々のNSFに渡してパケットを処理することと、これらの機能の実行ステータスを監視する方法を提供します。
Here are some examples of Events over the NSF-Facing Interface:
NSF-Facingインターフェースを介したイベントの例をいくつか示します。
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 Here are some examples of Conditions over the NSF-Facing Interface:
oユーザーのログオンまたはログオフNSF-Facingインターフェースを介した条件の例を以下に示します。
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 1つ以上のパケットヘッダー、パケットペイロードからのデータ、パケット内のビット、またはパケットから派生したデータを探すパケットコンテンツ値。
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接続（最初の3方向ハンドシェイクを通過した接続）を追跡します。
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の有効性を決定する主要なプロパティの1つであり、現在ほとんどが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.
複数のセキュリティ機能インスタンス間のポリシーの一貫性は、セキュリティポリシーが1つの中央セキュリティデバイスによって維持されなくなったため、非常に重要です。代わりに、さまざまな場所でインスタンス化された複数のセキュリティ機能によって実施されます。
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]は、L2、L3、またはL4ヘッダーに基づいてパケットを転送するほとんどのルーター/スイッチでサポートされるACLのルールを定義しています。 ACLのアクションには、Pass、Drop、またはRedirectが含まれます。
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.
NSFの機能プロファイル（または署名）は、特定のNSFに固有であるため、[ACL-YANG]にはありません。たとえば、ほとんどのIPS / IDS実装には独自の機能/プロファイルがあります。 I2NSFの目標の1つは、異なる組織間でプロファイルを交換または共有するための共通のエンベロープ形式を定義して、脅威に対するより効果的な保護を実現することです。
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]で指定された一致基準だけでなく、選択したNSFに応じたL4-L7フィールドも含める必要があります。
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 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.
NSFが（リソースの制約などにより）目的のプロビジョニングを実行できない場合は、I2NSF管理システムに通知する必要があります。このセキュリティ機能/能力交渉に必要なプロトコルは、[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を登録できます。 Inter-Domain Routing（IDR）Flow Specification [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 |
| 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 |
+---------------+-------------------------------------------+
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 |
+---------------+-------------------------------------------+
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 |
+---------------+-------------------------------------------+
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 |
+---------------+-------------------------------------------+
Figure 6: Functional Profile Index
図6：機能プロファイルインデックス
Management of NSFs include:
NSFの管理には次のものがあります。
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とその管理エンティティ間で制御および監視情報を伝送するために慎重に指定された適切な安全な通信チャネルが含まれている必要があります。リモートで管理されるNSFに関連する脅威については、セクション4で説明されており、ソリューションはそれらの懸念に対処する必要があります。
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.、Shes、N.、Raszuk、R.、Greene、B.、Mauch、J。、およびD. McPherson、「Dissemination of Flow Specification Rules」、RFC 5575、DOI 10.17487 / RFC5575、August 2009、<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、「Network Access Control List（ACL）YANG Data Model」、Work in Progress、draft-ietf-netmod-acl-モデル-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-ATTESTATION]牧師、A.、Lopez、D。、およびA. Shaw、「I2NSFセキュリティコントローラーによるネットワークセキュリティ機能（NSF）のリモート認証手順」、作業中、draft-pastor-i2nsf-nsf- remote-attestation-02、2017年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-CAPABILITIES] Xia、L.、Strassner、J.、Basile、C。、およびD. Lopez、「NSF機能の情報モデル」、作業中、draft-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、「ネットワークセキュリティ機能のデモの概要設計へのインターフェイス」、作業中、draft-xie-i2nsf-demo-outline-design-00、4月2015。
[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、「Interface to Network Security Functions（I2NSF）Terminology」、Work in Progress、draft-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、「Interface to Network Security Functions（I2NSF）：Problem Statement and Use Cases」、 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（ケーブルラブ）、Mohamed Boucadair（オレンジ）、Ramki Krishnan（デル）、Anil Lohiya（ジュニパーネットワークス）、Joe Parrott（BT）、Frank Xialing（Huawei）、 XiaoJun Zhuang（China Mobile）。
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.
この研究につながるいくつかの結果は、EUの第7次フレームワークプログラム（FP7 / 2007-2013）から助成金契約番号no。 611458。
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
Edward Lopez Curveball Networks Chantilly, Virginia United States of America
エドワードロペスカーブボールネットワークスシャンティリー、バージニア州アメリカ合衆国
Email: ed@curveballnetworks.com
Linda Dunbar Huawei Technologies United States of America
Linda Dunbar Huawei Technologiesアメリカ合衆国
Email: Linda.Dunbar@huawei.com
John Strassner Huawei Technologies Santa Clara, CA United States of America
John Strassner Huawei Technologiesサンタクララ、カリフォルニア州アメリカ合衆国
Email: John.sc.Strassner@huawei.com
Rakesh Kumar Juniper Networks United States of America
Rakesh Kumar Juniper Networksアメリカ合衆国
Email: rakeshkumarcloud@gmail.com