[要約] 要約： RFC 8192は、I2NSF（Interface to Network Security Functions）の問題声明と使用例に関するドキュメントです。このRFCの目的は、ネットワークセキュリティ機能へのインターフェースを提供し、ネットワークセキュリティの管理と制御を改善することです。目的： 1. I2NSFの問題声明を提供する。 2. I2NSFの使用例を示す。 3. ネットワークセキュリティの管理と制御を改善するためのインターフェースを提供する。
Internet Engineering Task Force (IETF) S. Hares
Request for Comments: 8192 Huawei
Category: Informational D. Lopez
ISSN: 2070-1721 Telefonica I+D
M. Zarny
vArmour
C. Jacquenet
France Telecom
R. Kumar
Juniper Networks
J. Jeong
Sungkyunkwan University
July 2017
Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases
ネットワークセキュリティ機能（I2NSF）へのインターフェイス：問題の説明と使用例
Abstract
概要
This document sets out the problem statement for Interface to Network Security Functions (I2NSF) and outlines some companion use cases.
このドキュメントでは、ネットワークセキュリティ機能へのインターフェース（I2NSF）の問題の説明と、いくつかの関連するユースケースの概要を説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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 a candidate 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 http://www.rfc-editor.org/info/rfc8192.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8192で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Challenges Facing Security Service Providers . . . . . . 6
3.1.1. Diverse Types of Security Functions . . . . . . . . . 6
3.1.2. Diverse Interfaces to Control and Monitor NSFs . . . 8
3.1.3. More Distributed NSFs and vNSFs . . . . . . . . . . . 8
3.1.4. More Demand to Control NSFs Dynamically . . . . . . . 9
3.1.5. Demand for Multi-tenancy to Control and Monitor NSFs 9
3.1.6. Lack of Characterization of NSFs and Capability
Exchange . . . . . . . . . . . . . . . . . . . . . . 9
3.1.7. Lack of Mechanism for NSFs to Utilize External
Profiles . . . . . . . . . . . . . . . . . . . . . . 10
3.1.8. Lack of Mechanisms to Accept External Alerts to
Trigger Automatic Rule and Configuration Changes . . 10
3.1.9. Lack of Mechanism for Dynamic Key Distribution to
NSFs . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Challenges Facing Customers . . . . . . . . . . . . . . . 12
3.2.1. NSFs from Heterogeneous Administrative Domains . . . 12
3.2.2. Today's Vendor-Specific Control Requests . . . . . . 13
3.2.3. Difficulty for Customers to Monitor the Execution of
Desired Policies . . . . . . . . . . . . . . . . . . 14
3.3. Lack of Standard Interface to Inject Feedback to NSF . . 15
3.4. Lack of Standard Interface for Capability Negotiation . . 15
3.5. Difficulty in Validating Policies across Multiple Domains 15
3.6. Software-Defined Networks . . . . . . . . . . . . . . . . 16
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Basic Framework . . . . . . . . . . . . . . . . . . . . . 17
4.2. Access Networks . . . . . . . . . . . . . . . . . . . . . 18
4.3. Cloud Data Center Scenario . . . . . . . . . . . . . . . 21
4.3.1. On-Demand Virtual Firewall Deployment . . . . . . . . 21
4.3.2. Firewall Policy Deployment Automation . . . . . . . . 22
4.3.3. Client-Specific Security Policy in Cloud VPNs . . . . 22
4.3.4. Internal Network Monitoring . . . . . . . . . . . . . 23
4.4. Preventing DDoS, Malware, and Botnet Attacks . . . . . . 23
4.5. Regulatory and Compliance Security Policies . . . . . . . 24
5. Management Considerations . . . . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Informative References . . . . . . . . . . . . . . . . . . . 25
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
This document sets out the problem statement for Interface to Network Security Functions (I2NSF) and outlines some use cases. A summary of the state of the art in the industry and IETF that is relevant to I2NSF work is documented in [I2NSF-ANALYSIS].
このドキュメントでは、ネットワークセキュリティ機能（I2NSF）へのインターフェイスに関する問題の説明と、いくつかの使用例の概要を説明します。 I2NSFの作業に関連する業界最先端のIETFの概要は、[I2NSF-ANALYSIS]に文書化されています。
The growing challenges and complexity in maintaining a secure infrastructure, complying with regulatory requirements, and controlling costs are enticing enterprises into consuming network security functions hosted by service providers. The hosted security service is especially attractive to small- and medium-size enterprises which suffer from a lack of security experts to continuously monitor networks, acquire new skills, and propose immediate mitigations to ever increasing sets of security attacks.
安全なインフラストラクチャを維持し、規制要件に準拠し、コストを管理する上で増大する課題と複雑さにより、企業はサービスプロバイダーがホストするネットワークセキュリティ機能を利用するようになっています。ホストされているセキュリティサービスは、ネットワークを継続的に監視し、新しいスキルを習得し、増え続けるセキュリティ攻撃のセットに即時の緩和策を提案するセキュリティ専門家が不足している中小企業にとって特に魅力的です。
According to [Gartner], the demand for hosted (or cloud-based) security services is growing. Small- and medium-size businesses (SMBs) are increasingly adopting cloud-based security services to replace on-premises security tools, while larger enterprises are deploying a mix of traditional and cloud-based security services.
[Gartner]によると、ホスト型（またはクラウドベース）のセキュリティサービスの需要が高まっています。中小企業（SMB）は、オンプレミスのセキュリティツールに代わるクラウドベースのセキュリティサービスの採用を拡大している一方、大企業では、従来のセキュリティサービスとクラウドベースのセキュリティサービスを組み合わせて導入しています。
To meet the demand, more and more service providers are providing hosted security solutions to deliver cost-effective managed security services to enterprise customers. The hosted security services are primarily targeted at enterprises (especially small and medium ones) but could also be provided to any kind of mass-market customer. As a result, the Network Security Functions (NSFs) are provided and consumed in a large variety of environments. Users of NSFs may consume network security services hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both.
需要を満たすために、ますます多くのサービスプロバイダーがホスト型セキュリティソリューションを提供して、企業顧客に費用対効果の高いマネージドセキュリティサービスを提供しています。ホストされているセキュリティサービスは、主に企業（特に中小規模の企業）を対象としていますが、あらゆる種類の大衆市場の顧客に提供することもできます。その結果、ネットワークセキュリティ機能（NSF）が提供され、さまざまな環境で使用されます。 NSFのユーザーは、独自の企業、サービスプロバイダー、またはその両方の組み合わせである1つ以上のプロバイダーによってホストされるネットワークセキュリティサービスを利用できます。
This document also briefly describes the following use cases summarized by [I2NSF-USECASES]:
このドキュメントでは、[I2NSF-USE CASES]で要約された次の使用例についても簡単に説明します。
o I2NSF Access Use Cases [OAM-USECASE],
o I2NSFアクセスの使用例[OAM-USECASE]、
o I2NSF Data Center Use Cases [DC-USECASE], and
o I2NSFデータセンターの使用例[DC-USE CASE]、および
o Integrated Security with Access Network Use Case [ACCESS-USECASE].
o 統合セキュリティとアクセスネットワークの使用例[ACCESS-USECASE]。
AAA: Authentication, Authorization, and Accounting [RFC2904]
AAA：認証、承認、およびアカウンティング[RFC2904]
ACL: Access Control List
ACL：アクセス制御リスト
Bespoke security management: Security management that is made to fit a particular customer.
オーダーメイドのセキュリティ管理：特定の顧客に合わせて作成されたセキュリティ管理。
DC: Data Center
DC：データセンター
FW: Firewall
FW：ファイアウォール
IDS: Intrusion Detection System
IDS：侵入検知システム
IPS: Intrusion Protection System
IPS：侵入防御システム
I2NSF: Interface to Network Security Functions
I2NSF：ネットワークセキュリティ機能へのインターフェイス
NSF: Network Security Function. An NSF is a function that is used to ensure integrity, confidentiality, or availability of network communication; to detect unwanted network activity; or to block, or at least mitigate, the effects of unwanted activity.
NSF：ネットワークセキュリティ機能。 NSFは、ネットワーク通信の整合性、機密性、または可用性を確保するために使用される機能です。不要なネットワークアクティビティを検出します。または、不要なアクティビティの影響をブロック、または少なくとも軽減します。
Flow-based NSF: An NSF that inspects network flows according to a security policy. Flow-based security also means that packets are inspected in the order they are received and without altering packets due to the inspection process (e.g., Medium Access Control (MAC) rewrites, TTL decrement action, or NAT inspection or changes). (Note: Some existing firewalls store packets and look at the packets in logical order, which is not the order these are received in time. This document restricts flow-based NSF to this definition.)
フローベースのNSF：セキュリティポリシーに従ってネットワークフローを検査するNSF。フローベースのセキュリティとは、パケットが受信された順序で検査され、検査プロセス（Medium Access Control（MAC）の書き換え、TTLデクリメントアクション、NAT検査や変更など）によってパケットが変更されることもないことを意味します。 （注：一部の既存のファイアウォールはパケットを格納し、パケットを論理的な順序で見ます。これは、パケットが時間内に受信された順序ではありません。このドキュメントでは、フローベースのNSFをこの定義に制限しています。）
Security service provider: A provider of security services to the customers (end users or enterprises) using NSF equipment purchased from vendors or created by the service provider.
セキュリティサービスプロバイダー：ベンダーから購入した、またはサービスプロバイダーが作成したNSF機器を使用して、顧客（エンドユーザーまたは企業）にセキュリティサービスを提供するプロバイダー。
SDN: Software-Defined Networking. (See [RFC7426] for architecture and terminology or [RFC7149] for a service provider view.)
SDN：Software-Defined Networking。 （アーキテクチャと用語については[RFC7426]を、サービスプロバイダーのビューについては[RFC7149]を参照してください。）
vCPE: virtual Customer Premises Equipment
vCPE：仮想顧客宅内機器
vEPC: virtual Evolved Packet Core [EPC-3GPP]
vEPC：仮想Evolved Packet Core [EPC-3GPP]
vNSF: Virtual NSF. An NSF that is deployed as a distributed virtual resource.
vNSF：仮想NSF。分散仮想リソースとしてデプロイされるNSF。
vPE: virtual Provider Edge
vPE：仮想プロバイダーエッジ
VPN: Virtual Private Network
VPN：仮想プライベートネットワーク
The following sub-sections describe the problems and challenges facing customers and security service providers when some or all of the security functions are no longer physically hosted by the customer's administrative domain.
次のサブセクションでは、セキュリティ機能の一部またはすべてが顧客の管理ドメインで物理的にホストされなくなった場合に、顧客とセキュリティサービスプロバイダーが直面する問題と課題について説明します。
Security service providers can be internal or external to the company. For example, an internal IT security group within a large enterprise could act as a security service provider for the enterprise. In contrast, an enterprise could outsource all security services to an external security service provider. In this document, the security service provider function, whether it is internal or external, will be denoted as "service provider".
セキュリティサービスプロバイダーは、会社の内部または外部のどちらでもかまいません。たとえば、大企業内の内部ITセキュリティグループは、企業のセキュリティサービスプロバイダーとして機能できます。対照的に、企業はすべてのセキュリティサービスを外部のセキュリティサービスプロバイダーに外部委託することができます。このドキュメントでは、セキュリティサービスプロバイダー機能は、それが内部か外部かに関係なく、「サービスプロバイダー」と表記されます。
The "Customer-Provider" relationship may be between any two parties. The parties can be in different organizations or different domains of the same organization. Contractual agreements may be required in such contexts to formally document the customer's security requirements and the provider's guarantees to fulfill those requirements. Such agreements may detail protection levels, escalation procedures, alarms reporting, etc. There is currently no standard mechanism to capture those requirements.
「顧客とプロバイダー」の関係は、任意の2者間である可能性があります。当事者は、異なる組織または同じ組織の異なるドメインに存在することができます。そのような状況では、顧客のセキュリティ要件と、それらの要件を満たすためのプロバイダーの保証を正式に文書化するために、契約上の合意が必要になる場合があります。そのような合意は、保護レベル、エスカレーション手順、アラーム報告などを詳述する場合があります。現在、これらの要件を取得する標準的なメカニズムはありません。
A service provider may be a customer of another service provider.
サービスプロバイダーは、別のサービスプロバイダーの顧客である場合があります。
It is the objective of the I2NSF work to address these problems and challenges.
これらの問題と課題に対処することがI2NSF作業の目的です。
There are many types of NSFs. NSFs by different vendors can have different features and interfaces. NSFs can be deployed in multiple locations in a given network and perhaps have different roles.
NSFには多くのタイプがあります。さまざまなベンダーのNSFは、さまざまな機能とインターフェースを持つことができます。 NSFは特定のネットワークの複数の場所に展開でき、おそらく異なる役割を持っています。
Below are a few examples of security functions and locations or contexts in which they are often deployed:
以下は、セキュリティ機能とそれらがしばしば展開される場所またはコンテキストのいくつかの例です。
External Intrusion and Attack Protection: Examples of this function are firewall/ACL authentication, IPS, IDS, and endpoint protection.
外部侵入および攻撃保護：この機能の例には、ファイアウォール/ ACL認証、IPS、IDS、およびエンドポイント保護があります。
Security Functions in a Demilitarized Zone (DMZ): Examples of this function are firewall/ACLs, IDS/IPS, one or all of AAA services, NAT, forwarding proxies, and application filtering. These functions may be physically on-premise in a server provider's network at the DMZ spots or located in a "virtual" DMZ.
非武装地帯（DMZ）のセキュリティ機能：この機能の例には、ファイアウォール/ ACL、IDS / IPS、1つまたはすべてのAAAサービス、NAT、転送プロキシ、およびアプリケーションフィルタリングがあります。これらの機能は、サーバープロバイダーのネットワークのDMZスポットに物理的に設置されている場合と、「仮想」DMZに設置されている場合があります。
Centralized or Distributed Security Functions: The security functions could be deployed in a centralized fashion for ease of management and network design or in a distributed fashion for scaled requirement. No matter how a security function is deployed and provisioned, it is desirable to have the same interface to provision security policies; otherwise, the job of security administration is more complex, requiring knowledge of firewall and network design.
集中型または分散型セキュリティ機能：セキュリティ機能は、管理とネットワーク設計を容易にするために集中型で、または拡張された要件に応じて分散型で展開できます。セキュリティ機能がどのように展開およびプロビジョニングされているかに関係なく、セキュリティポリシーをプロビジョニングするために同じインターフェイスを持つことが望ましいです。そうしないと、セキュリティ管理の仕事がより複雑になり、ファイアウォールとネットワーク設計の知識が必要になります。
Internal Security Analysis and Reporting: Examples of this function are security logs, event correlation, and forensic analysis.
内部セキュリティ分析とレポート：この機能の例は、セキュリティログ、イベント相関、およびフォレンジック分析です。
Internal Data and Content Protection: Examples of this function are encryption, authorization, and public/private key management for internal databases.
内部データとコンテンツの保護：この機能の例としては、内部データベースの暗号化、承認、公開/秘密キー管理があります。
Security Gateways and VPN Concentrators: Examples of these functions are IPsec gateways, secure VPN concentrators that handle bridging secure VPNs, and secure VPN controllers for data flows.
セキュリティゲートウェイとVPNコンセントレータ：これらの機能の例としては、IPsecゲートウェイ、安全なVPNのブリッジングを処理する安全なVPNコンセントレータ、データフロー用の安全なVPNコントローラーなどがあります。
Given the diversity of security functions, the contexts in which these functions can be deployed, and the constant evolution of these functions, standardizing all aspects of security functions is challenging and probably not feasible. Fortunately, it is not necessary to standardize all aspects. For example, from an I2NSF perspective, there is no need to standardize how every firewall's filtering is created or applied. Some features in a specific vendor's filtering may be unique to the vendor's product, so it is not necessary to standardize these features.
セキュリティ機能の多様性、これらの機能を展開できるコンテキスト、およびこれらの機能の絶え間ない進化を考えると、セキュリティ機能のすべての側面を標準化することは困難であり、おそらく実現不可能です。幸い、すべての側面を標準化する必要はありません。たとえば、I2NSFの観点からは、すべてのファイアウォールのフィルタリングがどのように作成または適用されるかを標準化する必要はありません。特定のベンダーのフィルタリングの一部の機能はベンダーの製品に固有である可能性があるため、これらの機能を標準化する必要はありません。
What is needed is a standardized interface to control and monitor the rule sets that NSFs use to treat packets traversing through these NSFs. Thus, standardizing interfaces will provide an impetus for standardizing established security functions.
必要なのは、NSFがこれらのNSFを通過するパケットを処理するために使用するルールセットを制御および監視するための標準化されたインターフェイスです。したがって、インターフェースの標準化は、確立されたセキュリティ機能を標準化するための推進力を提供します。
I2NSF may specify some filters, but these filters will be linked to specific common functionality developed by I2NSF in information models or data models.
I2NSFはいくつかのフィルターを指定する場合がありますが、これらのフィルターは、情報モデルまたはデータモデルでI2NSFによって開発された特定の共通機能にリンクされます。
To provide effective and competitive solutions and services, security service providers may need to utilize multiple security functions from various vendors to enforce the security policies desired by their customers.
効果的で競争力のあるソリューションとサービスを提供するために、セキュリティサービスプロバイダーは、さまざまなベンダーの複数のセキュリティ機能を利用して、顧客が望むセキュリティポリシーを施行する必要がある場合があります。
Since no widely accepted industry standard interface to NSFs exists today, management of NSFs (device and policy provisioning, monitoring, etc.) tends to be custom-made security management offered by product vendors. As a result, automation of such services, if it exists at all, is also custom made. Thus, even in the traditional way of deploying security features, there is a gap that needs to be filled; this would require coordination among implementations from distinct vendors.
NSFへの広く受け入れられている業界標準のインターフェイスは現在存在しないため、NSFの管理（デバイスとポリシーのプロビジョニング、監視など）は、製品ベンダーが提供するカスタムメイドのセキュリティ管理になる傾向があります。その結果、このようなサービスが存在する場合、その自動化もカスタム化されます。したがって、セキュリティ機能を展開する従来の方法でも、埋める必要のあるギャップがあります。これには、異なるベンダーの実装間の調整が必要になります。
A challenge for monitoring prior to mitigation of a security intrusion is that an NSF cannot monitor what it cannot view. For example, enabling a security function to mitigate an intrusion (e.g., firewall [FIREWALLS]) must include a mechanism to provide monitoring feedback in order to determine the intrusion has been stopped. Therefore, it is necessary to have a mechanism to monitor and provide execution status of NSFs to security and compliance management tools. Such mechanisms exist in vendor-specific network security interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across a variety of NSFs.
セキュリティ侵入を軽減する前に監視するための課題は、NSFが表示できないものを監視できないことです。たとえば、セキュリティ機能を有効にして侵入を軽減する（ファイアウォール[FIREWALLS]など）には、侵入が停止したことを確認するために監視フィードバックを提供するメカニズムを含める必要があります。したがって、NSFの実行ステータスを監視し、セキュリティおよびコンプライアンス管理ツールに提供するメカニズムが必要です。このようなメカニズムは、フォレンジックとトラブルシューティングのためのベンダー固有のネットワークセキュリティインターフェイスに存在しますが、業界標準のインターフェイスは、さまざまなNSFを監視できます。
The security functions that are invoked to enforce a security policy can be located in different equipment and network locations.
セキュリティポリシーを実施するために呼び出されるセキュリティ機能は、さまざまな機器やネットワークの場所に配置できます。
The European Telecommunications Standards Institute (ETSI) Network Functions Virtualization (NFV) initiative [ETSI-NFV] creates new management challenges for security policies to be enforced by distributed vNSFs.
欧州電気通信標準化機構（ETSI）ネットワーク機能仮想化（NFV）イニシアチブ[ETSI-NFV]は、分散vNSFによって実施されるセキュリティポリシーの新しい管理課題を作成します。
A vNSF has higher risk of changes to the state of network connection, interfaces, or traffic, as their hosting Virtual Machines (VMs) are being created, moved, or decommissioned.
vNSFは、ホスティング仮想マシン（VM）が作成、移動、または廃止されるため、ネットワーク接続、インターフェース、またはトラフィックの状態が変化するリスクが高くなります。
In the advent of Software-Defined Networking (SDN) (see [SDN-SECURITY]), more clients, applications, or application controllers need to dynamically update their security policies that are enforced by NSFs. The security service providers have to dynamically update their decision-making process (e.g., in terms of NSF resource allocation and invocation) upon receiving security-related requests from their clients.
ソフトウェア定義ネットワーク（SDN）（[SDN-SECURITY]を参照）の出現により、より多くのクライアント、アプリケーション、またはアプリケーションコントローラーが、NSFによって適用されるセキュリティポリシーを動的に更新する必要があります。セキュリティサービスプロバイダーは、クライアントからセキュリティ関連のリクエストを受信すると、意思決定プロセス（NSFリソースの割り当てや呼び出しなど）を動的に更新する必要があります。
Service providers may need to deploy several NSF controllers to control and monitor the NSFs, especially when NSFs become distributed and virtualized.
特にNSFが分散および仮想化される場合、サービスプロバイダーは、NSFを制御および監視するためにいくつかのNSFコントローラを展開する必要がある場合があります。
To offer effective security services, service providers need to activate various security functions in NSFs or vNSFs manufactured by multiple vendors. Even within one product category (e.g., firewall), security functions provided by different vendors can have different features and capabilities. For example, filters that can be designed and activated by a firewall may or may not support IPv6 depending on the firewall technology.
効果的なセキュリティサービスを提供するには、サービスプロバイダーは、複数のベンダーによって製造されたNSFまたはvNSFのさまざまなセキュリティ機能をアクティブにする必要があります。 1つの製品カテゴリ（ファイアウォールなど）内であっても、異なるベンダーが提供するセキュリティ機能は、異なる機能を備えている場合があります。たとえば、ファイアウォールによって設計およびアクティブ化できるフィルターは、ファイアウォールテクノロジーに応じてIPv6をサポートする場合とサポートしない場合があります。
The service provider's management system (or controller) needs a way to retrieve the capabilities of service functions by different vendors so that it can build an effective security solution. These service function capabilities can be documented in a static manner (e.g., a file) or via an interface that accesses a repository of security function capabilities that the NSF vendors dynamically update.
サービスプロバイダーの管理システム（またはコントローラー）には、効果的なセキュリティソリューションを構築できるように、さまざまなベンダーによるサービス機能の機能を取得する方法が必要です。これらのサービス機能機能は、静的な方法（ファイルなど）で、またはNSFベンダーが動的に更新するセキュリティ機能機能のリポジトリにアクセスするインターフェースを介して文書化できます。
A dynamic capability registration is useful for automation because security functions may be subject to software and hardware updates. These updates may have implications on the policies enforced by the NSFs.
動的機能登録は、セキュリティ機能がソフトウェアとハードウェアの更新の影響を受ける可能性があるため、自動化に役立ちます。これらの更新は、NSFによって適用されるポリシーに影響を与える可能性があります。
Today, there is no standard method for vendors to describe the capabilities of their security functions. Without a common technical framework to describe the capabilities of security functions, service providers cannot automate the process of selecting NSFs by different vendors to accommodate customers' security requirements.
現在、ベンダーがセキュリティ機能の機能を説明するための標準的な方法はありません。セキュリティ機能の機能を説明する共通の技術フレームワークがないと、サービスプロバイダーは、顧客のセキュリティ要件に対応するために、さまざまなベンダーによるNSFの選択プロセスを自動化できません。
The I2NSF work will focus on developing a standard method to describe capabilities of security functions.
I2NSFの作業では、セキュリティ機能の機能を説明する標準的な方法の開発に焦点を当てます。
Many security functions depend on signature files or profiles (e.g., IPS/IDS signatures and DDoS Open Threat Signaling (DOTS) filters). Different policies might need different signatures or profiles. Today, blacklist databases can be a beneficial strategy for all parties involved (except the attackers), but in the future, there might be open-source signatures and profiles distributed as part of IDS systems (e.g., by Snort, Suricata, Bro, and Kismet).
多くのセキュリティ機能は、署名ファイルまたはプロファイルに依存しています（IPS / IDS署名やDDoS Open Threat Signaling（DOTS）フィルターなど）。ポリシーごとに異なる署名またはプロファイルが必要になる場合があります。今日、ブラックリストデータベースは、関与するすべての関係者（攻撃者を除く）にとって有益な戦略になる可能性がありますが、将来、IDSシステムの一部として（たとえば、Snort、Suricata、Bro、などによって）オープンソースの署名とプロファイルが配布される可能性があります。 Kismet）。
There is a need to have a standard envelope (i.e., a message format) to allow NSFs to use external profiles.
NSFが外部プロファイルを使用できるようにするには、標準のエンベロープ（つまり、メッセージ形式）が必要です。
3.1.8. Lack of Mechanisms to Accept External Alerts to Trigger Automatic Rule and Configuration Changes
3.1.8. 自動ルールと設定変更をトリガーする外部アラートを受け入れるメカニズムの欠如
NSFs can ask the I2NSF security controller to alter specific rules and/or configurations. For example, a Distributed Denial of Service (DDoS) alert could trigger a change to the routing system to send traffic to a traffic scrubbing service to mitigate the DDoS.
NSFは、特定のルールや構成を変更するようにI2NSFセキュリティコントローラーに要求できます。たとえば、分散サービス拒否（DDoS）アラートは、ルーティングシステムへの変更をトリガーして、トラフィックスクラブサービスにトラフィックを送信し、DDoSを軽減できます。
The DDoS protection has two parts: a) the configuration of signaling of open threats and b) DDoS mitigation. The DOTS controller manages the signaling part of DDoS. I2NSF controller(s) would control any changes to affected policies (e.g., forwarding and routing, filtering, etc.). By monitoring the network alerts regarding DDoS attacks (e.g., from DOTS servers or clients), the I2NSF controller(s) can feed an alerts analytics engine that could recognize attacks so the I2NSF can enforce the appropriate policies.
DDoS保護には2つの部分があります。a）オープン脅威のシグナリングの構成、およびb）DDoS緩和。 DOTSコントローラは、DDoSのシグナリング部分を管理します。 I2NSFコントローラーは、影響を受けるポリシー（たとえば、転送とルーティング、フィルタリングなど）への変更を制御します。 DDoS攻撃に関するネットワークアラートを監視することにより（DOTSサーバーやクライアントからなど）、I2NSFコントローラーは、攻撃を認識できるアラート分析エンジンにフィードできるため、I2NSFは適切なポリシーを実施できます。
DDoS mitigation is enhanced if the provider's network security controller can monitor, analyze, and investigate the abnormal events and provide information to the customer or change the network configuration automatically.
プロバイダーのネットワークセキュリティコントローラーが異常なイベントを監視、分析、および調査し、顧客に情報を提供したり、ネットワーク構成を自動的に変更したりできる場合、DDoSの緩和機能が強化されます。
[CAP-INTERFACE] provides details on how monitoring aspects of the flow-based Network Security Functions (NSFs) can use the I2NSF interfaces to receive traffic reports and enforce appropriate policies.
[CAP-INTERFACE]は、フローベースのネットワークセキュリティ機能（NSF）の監視機能がI2NSFインターフェイスを使用してトラフィックレポートを受信し、適切なポリシーを適用する方法の詳細を提供します。
There is a need for a controller to create, manage, and distribute various keys to distributed NSFs. While there are many key management methods and cryptographic suites (e.g., encryption algorithms, key derivation functions, etc.) and other functions, there is a lack of a standard interface to provision and manage security associations.
さまざまなキーを作成、管理、および分散NSFに配布するコントローラーが必要です。多くの鍵管理方法と暗号スイート（暗号化アルゴリズム、鍵導出関数など）やその他の関数がありますが、セキュリティアソシエーションをプロビジョニングおよび管理するための標準的なインターフェイスがありません。
The keys may be used for message authentication and integrity in order to protect data flows. In addition, keys may be used to secure the protocols and messages in the core routing infrastructure (see [RFC4948]).
キーは、データフローを保護するために、メッセージ認証と整合性に使用できます。さらに、キーは、コアルーティングインフラストラクチャのプロトコルとメッセージを保護するために使用できます（[RFC4948]を参照）。
As of now, there is not much focus on an abstraction for keying information that describes the interface between protocols, operators, and automated key management.
現在のところ、プロトコル、オペレーター、および自動化されたキー管理の間のインターフェースを記述するキーイング情報の抽象化にはあまり重点が置かれていません。
An example of a solution may provide some insight into why the lack of a mechanism is a problem. If a device had an abstract key table maintained by security services, it could use these keys for routing and security devices.
ソリューションの例は、メカニズムの欠如が問題である理由についての洞察を提供する場合があります。デバイスがセキュリティサービスによって維持される抽象キーテーブルを持っている場合、ルーティングおよびセキュリティデバイスにこれらのキーを使用できます。
What does this take?
これは何をしますか？
Conceptually, there must be an interface defined for routing/ signaling protocols that can a) make requests for automated key management when it is being used and b) notify the protocols when keys become available in the key table. One potential use of such an interface is to manage IPsec security associations on Software-Defined Networks.
概念的には、ルーティング/シグナリングプロトコル用に定義されたインターフェイスが必要です。これは、a）使用時に自動キー管理を要求し、b）キーがキーテーブルで使用可能になったときにプロトコルに通知することができます。このようなインターフェイスの潜在的な用途の1つは、ソフトウェア定義ネットワークでIPsecセキュリティアソシエーションを管理することです。
An abstract key service will work under the following conditions:
抽象キーサービスは、次の条件下で機能します。
1. I2NSF needs to design the key table abstraction, the interface between key management protocols and routing/other protocols, and possibly security protocols at other layers.
1. I2NSFは、キーテーブルの抽象化、キー管理プロトコルとルーティング/その他のプロトコル間のインターフェイス、および場合によっては他のレイヤーのセキュリティプロトコルを設計する必要があります。
2. For each routing/other protocol, I2NSF needs to define the mapping between how the protocol represents key material and the protocol-independent key table abstraction. If several protocols share common mechanisms for authentication (e.g., TCP Authentication Option [RFC5925]), then the same mapping may be used for all usages of that mechanism.
2. 各ルーティング/その他のプロトコルについて、I2NSFは、プロトコルがキーマテリアルを表す方法とプロトコルに依存しないキーテーブルの抽象化との間のマッピングを定義する必要があります。複数のプロトコルが認証の共通メカニズムを共有している場合（たとえば、TCP認証オプション[RFC5925]）、そのメカニズムのすべての使用に同じマッピングを使用できます。
3. Automated key management needs to support both pairwise keys and group keys via the abstract key service provided by items 1 and 2. I2NSF controllers within the NSF that are required to exchange data with NSFs may exchange data with individual NSFs using individual pairwise keys or with a group of NSFs simultaneously using an IP group address secured by a group security key(s).
3. 自動キー管理は、アイテム1と2によって提供される抽象キーサービスを介してペアワイズキーとグループキーの両方をサポートする必要があります。NSFとのデータ交換に必要なNSF内のI2NSFコントローラーは、個別のペアワイズキーまたはグループセキュリティキーで保護されたIPグループアドレスを同時に使用するNSFのグループ。
When customers invoke hosted security services, their security policies may be enforced by a collection of security functions hosted in different domains. Customers may not have the security skills to express sufficiently precise requirements or security policies. Usually, these customers express the expectations of their security requirements or the intent of their security policies. These expectations can be considered customer-level security expectations. Customers may also desire to express guidelines for security management. Examples of such guidelines include:
顧客がホストされているセキュリティサービスを呼び出すと、異なるドメインでホストされているセキュリティ機能のコレクションによってセキュリティポリシーが適用される場合があります。顧客は、十分に正確な要件またはセキュリティポリシーを表現するためのセキュリティスキルを持っていない可能性があります。通常、これらの顧客は、セキュリティ要件の期待またはセキュリティポリシーの意図を表明します。これらの期待は、顧客レベルのセキュリティの期待と見なすことができます。お客様は、セキュリティ管理のガイドラインを表明することもできます。そのようなガイドラインの例は次のとおりです。
o which critical communications are to be preserved during critical events and which hosts will continue services over the network,
o 重要なイベントの間、どの重要な通信が保持され、どのホストがネットワーク上でサービスを継続するか、
o what signaling information is passed to a controller during a DDoS in order to ask for mitigation services (within the scope of the DOTS Working Group),
o （DOTSワーキンググループのスコープ内で）緩和サービスを要求するために、DDoS中にコントローラーに渡されるシグナリング情報
o reporting of attacks to CERT (within the scope of the MILE Working Group), and
o CERTへの攻撃の報告（MILEワーキンググループの範囲内）、および
o managing network connectivity of systems out of compliance (within the scope of the SACM Working Group).
o コンプライアンスに準拠していないシステムのネットワーク接続の管理（SACMワーキンググループの範囲内）。
Many medium and large enterprises have deployed various on-premises security functions that they want to continue to use. These enterprises want to combine local security functions with remote hosted security functions to achieve more efficient and immediate countermeasures to attacks originating on both the Internet and enterprise networks.
多くの中規模および大規模企業は、引き続き使用したいさまざまなオンプレミスセキュリティ機能を展開しています。これらの企業は、ローカルのセキュリティ機能とリモートのホストされたセキュリティ機能を組み合わせて、インターネットと企業ネットワークの両方から発生する攻撃に対するより効率的で即時の対策を実現したいと考えています。
Some enterprises may only need the hosted security services for their remote branch offices where minimal security infrastructures/ capabilities exist. The security solution will consist of deploying NSFs on customer networks and on service provider networks.
一部の企業では、最小限のセキュリティインフラストラクチャ/機能が存在するリモートのブランチオフィスにホスト型セキュリティサービスのみが必要な場合があります。セキュリティソリューションは、顧客ネットワークとサービスプロバイダーネットワークへのNSFの導入で構成されます。
Customers may utilize NSFs provided by multiple service providers. Customers need to express their security requirements, guidelines, and expectations to the service providers. In turn, the service providers must translate this customer information into customer security policies and associated configuration tasks for the set of security functions in their network. Without a standardized interface that provides a clear technical characterization, the service provider faces many challenges:
複数のサービスプロバイダーが提供するNSFを利用できます。顧客は、セキュリティ要件、ガイドライン、およびサービスプロバイダーへの期待を表明する必要があります。次に、サービスプロバイダーは、この顧客情報を顧客のセキュリティポリシーと、ネットワーク内の一連のセキュリティ機能の関連する構成タスクに変換する必要があります。明確な技術的特性を提供する標準化されたインターフェイスがなければ、サービスプロバイダーは多くの課題に直面します。
No standard technical characterization, APIs, or interface(s): Even for the most common security services, there is no standard technical characterization, APIs, or interface(s). Most security services are accessible only through disparate, proprietary interfaces (e.g., portals or APIs) in whatever format vendors choose to offer. The service provider must process the customer's input with these widely varying interfaces and differing configuration models for security devices and security policy. Without a standard interface, new innovative security products find a large barrier to entry into the market.
標準の技術的特性、API、またはインターフェースなし：最も一般的なセキュリティサービスであっても、標準的な技術的特性、API、またはインターフェースはありません。ほとんどのセキュリティサービスには、ベンダーが提供する形式を問わず、異なる独自のインターフェース（ポータルやAPIなど）を介してのみアクセスできます。サービスプロバイダーは、セキュリティデバイスとセキュリティポリシーのさまざまなインターフェイスとさまざまな構成モデルを使用して、顧客の入力を処理する必要があります。標準のインターフェースがなければ、新しい革新的なセキュリティ製品は市場への参入にとって大きな障壁となります。
Lack of immediate feedback: Customers may also require a mechanism to easily update/modify their security requirements with immediate effect in the underlying involved NSFs.
即時のフィードバックの欠如：顧客は、関連するNSFに即時に影響を与えるセキュリティ要件を簡単に更新/変更するメカニズムも必要とする場合があります。
Lack of explicit invocation request: While security agreements are in place, security functions may be solicited without requiring an explicit invocation means. Nevertheless, some explicit invocation means may be required to interact with a service function.
明示的な呼び出し要求の欠如：セキュリティー合意が確立されている間、明示的な呼び出し手段を必要とせずにセキュリティー機能が要求される場合があります。それにもかかわらず、サービス関数と対話するために、いくつかの明示的な呼び出し手段が必要になる場合があります。
Managing by scripts du jour: The current practices rely upon the use of scripts that generate other scripts, which automatically run to upload or download configuration changes, log information, and other things. These scripts have to be adjusted each time an implementation from a different vendor technology is enabled by a provider.
スクリプトによる管理：現在の慣行は、他のスクリプトを生成するスクリプトの使用に依存しています。このスクリプトは、自動的に実行され、構成の変更、ログ情報などをアップロードまたはダウンロードします。これらのスクリプトは、プロバイダーによって異なるベンダーテクノロジーの実装が有効になるたびに調整する必要があります。
To see how standard interfaces could help achieve faster implementation time cycles, let us consider a customer who would like to dynamically allow an encrypted flow with a specific port, src/dst addresses, or protocol type through the firewall/IPS to enable an encrypted video conferencing call only during the time of the call. With no commonly accepted interface in place, as shown in Figure 1, the customer would have to learn about the particular provider's firewall/IPS interface and send the request in the provider's required format.
標準インターフェースが実装時間サイクルの高速化にどのように役立つかを確認するために、特定のポート、src / dstアドレス、またはファイアウォール/ IPSを介したプロトコルタイプを使用して、暗号化されたフローを動的に許可し、暗号化されたビデオを有効にしたいと考えているお客様を考えてみましょう通話中の会議通話のみ。図1に示すように、一般的に受け入れられているインターフェイスがないため、顧客は特定のプロバイダーのファイアウォール/ IPSインターフェイスについて学習し、プロバイダーの必要な形式でリクエストを送信する必要があります。
+------------+
| Security |
| Management |
| System |
+----||------+
|| Proprietary
|| or I2NSF Standard
Video: ||
Port 10 +--------+
--------| FW/IPS |-------------
Encrypted +--------+
Video Flow
Figure 1: Example of Non-standard vs. Standard Interface
図1：非標準インターフェースと標準インターフェースの例
In contrast, as Figure 1 shows, if a firewall/IPS interface standard exists, the customer would be able to send the request to a security management system, and the security management would send it via a I2NSF standard interface. Service providers could now utilize the same standard interface to represent firewall/IPS services implemented using products from many vendors.
対照的に、図1に示すように、ファイアウォール/ IPSインターフェイス標準が存在する場合、顧客はセキュリティ管理システムに要求を送信でき、セキュリティ管理はI2NSF標準インターフェイスを介して要求を送信します。サービスプロバイダーは、同じ標準インターフェイスを利用して、多くのベンダーの製品を使用して実装されたファイアウォール/ IPSサービスを表すことができます。
3.2.3. Difficulty for Customers to Monitor the Execution of Desired Policies
3.2.3. お客様が必要なポリシーの実行を監視するのが難しい
How a policy is translated into technology-specific actions is hidden from the customers. However, customers still need ways to monitor the delivered security service that results from the execution of their desired security requirements, guidelines, and expectations. Customers want to monitor existing policies to determine such things as which policies are in effect, how many security attacks are being prevented, and how much bandwidth efficiency does security enforcement cost.
ポリシーがテクノロジー固有のアクションにどのように変換されるかは、顧客には見えません。ただし、お客様は、必要なセキュリティ要件、ガイドライン、および期待の実行から生じる、提供されたセキュリティサービスを監視する方法が依然として必要です。お客様は、既存のポリシーを監視して、有効なポリシー、防御されているセキュリティ攻撃の数、セキュリティ実施コストによる帯域幅効率の程度などを判断したいと考えています。
Today, there is no standard way for customers to get these details from the security service. As a consequence, there is no way to assure customers that their specified security policies are properly enforced by the security functions located in the provider domain.
現在、顧客がセキュリティサービスからこれらの詳細を取得する標準的な方法はありません。その結果、指定されたセキュリティポリシーがプロバイダードメインにあるセキュリティ機能によって適切に実施されていることを顧客に保証する方法はありません。
Customers also want this monitoring information from the security system in order to plan for the future using "what-if" scenarios with real data. A tight loop between the data gathered from security systems and the "what-if" scenario planning can reduce the time to design and deploy workable security policies that deal with new threats.
お客様は、実際のデータを使用した「what-if」シナリオを使用して将来を計画するために、セキュリティシステムからのこの監視情報も必要としています。セキュリティシステムから収集されたデータと「what-if」シナリオ計画の間の緊密なループにより、新しい脅威に対処する実用的なセキュリティポリシーを設計および展開する時間を短縮できます。
It is the objective of the I2NSF work to provide a standard way to get the information that security service assurance systems need to provide customers an evaluation about the current security systems and to quickly plan for future security policies using "what-if" scenarios based on today's information.
I2NSF作業の目的は、セキュリティサービス保証システムが現在のセキュリティシステムについての評価を顧客に提供し、将来のセキュリティポリシーに基づいて「what-if」シナリオに基づいて迅速に計画するために必要な情報を取得する標準的な方法を提供することです今日の情報。
Today, many security functions in the NSF, such as IPS, IDS, DDoS mitigation, and antivirus, depend heavily on the associated profiles. NSF devices can perform more effective protection if these NSF devices have the up-to-date profiles for these functions. Today, there is no standard interface to provide these security profiles for the NSF.
今日、IPS、IDS、DDoS緩和、アンチウイルスなど、NSFの多くのセキュリティ機能は、関連するプロファイルに大きく依存しています。これらのNSFデバイスにこれらの機能の最新のプロファイルがある場合、NSFデバイスはより効果的な保護を実行できます。現在、NSFにこれらのセキュリティプロファイルを提供する標準のインターフェイスはありません。
As more sophisticated threats arise, protection will depend on enterprises, vendors, and service providers being able to cooperate to develop optimal profiles; one example of this cooperation is the Cyber Threat Alliance [CTA]. The standard interface to provide security profiles to the NSF should interwork with the formats that exchange security profiles between organizations.
より高度な脅威が発生すると、保護は企業、ベンダー、サービスプロバイダーが最適なプロファイルを開発するために協力できるかどうかに依存します。この協力の一例は、サイバー脅威アライアンス[CTA]です。 NSFにセキュリティプロファイルを提供する標準インターフェイスは、組織間でセキュリティプロファイルを交換するフォーマットと相互作用する必要があります。
One objective of the I2NSF work is to provide this type of standard interface to security profiles.
I2NSF作業の1つの目的は、このタイプの標準インターフェースをセキュリティプロファイルに提供することです。
There could be situations when the selected NSFs cannot perform the policies requested by the security controller due to resource constraints. The customer and security service provider should negotiate the appropriate resource constraints before the security service begins. However, unexpected events may happen that cause the NSF to exhaust those negotiated resources. At this point, the NSF should inform the security controller that the allotted resources have been exhausted. To support the automatic control in the SDN era, it is necessary to have a set of messages for proper notification (and a response to that notification) between the security controller and the NSFs.
リソースの制約により、選択したNSFがセキュリティコントローラーによって要求されたポリシーを実行できない場合があります。顧客とセキュリティサービスプロバイダーは、セキュリティサービスを開始する前に、適切なリソースの制約について交渉する必要があります。ただし、NSFがネゴシエートされたリソースを使い果たす原因となる予期しないイベントが発生する可能性があります。この時点で、NSFは割り当てられたリソースが使い果たされたことをセキュリティコントローラに通知する必要があります。 SDN時代の自動制御をサポートするには、セキュリティコントローラーとNSFの間で適切な通知（およびその通知への応答）のための一連のメッセージが必要です。
As discussed in the previous four sub-sections, both service providers and customers have need to express policies and profiles, monitor systems, verify security policy has been installed in NSFs within a security domain, and establish limits for services NSFs can safely perform. This sub-section and the next sub-section (Section 3.6) examine what happens in two specific network scenarios: a) multi-domain control of security devices hosted on virtual and non-virtual NSFs and b) Software-Defined Networking.
前の4つのサブセクションで説明したように、サービスプロバイダーと顧客の両方がポリシーとプロファイルを表現し、システムを監視し、セキュリティポリシーがセキュリティドメイン内のNSFにインストールされていることを確認し、NSFが安全に実行できるサービスの制限を確立する必要があります。このサブセクションと次のサブセクション（セクション3.6）では、2つの特定のネットワークシナリオで何が起こるかを調べます。a）仮想および非仮想NSFでホストされているセキュリティデバイスのマルチドメイン制御とb）ソフトウェア定義ネットワーク。
Hosted security service may instantiate NSFs in virtual machines that are sometimes widely distributed in the network and sometimes are combined together in one device to perform a set of tasks for delivering a service. Hosted security services may be connected within a single service provider or via multiple service providers. Ensuring that the security service purchased by the customer adheres to customer policy requires that the central controller(s) for this service monitor and validate this service across multiple networks on NSFs (some of which may be virtual networks on virtual machines). To set up this cross-domain service, the security controller must be able to communicate with NSFs and/or controllers within its domain and across domains to negotiate for the services needed.
ホストされたセキュリティサービスは、ネットワークに広く分散され、サービスを提供するための一連のタスクを実行するために1つのデバイスに結合されることがある仮想マシンでNSFをインスタンス化する場合があります。ホストされたセキュリティサービスは、単一のサービスプロバイダー内または複数のサービスプロバイダーを介して接続できます。顧客が購入したセキュリティサービスが顧客のポリシーに準拠していることを確認するには、このサービスの中央コントローラーが、NSF上の複数のネットワーク（仮想マシンの一部は仮想ネットワークである可能性があります）全体でこのサービスを監視および検証する必要があります。このクロスドメインサービスをセットアップするには、セキュリティコントローラーがドメイン内およびドメイン間でNSFやコントローラーと通信して、必要なサービスについて交渉できる必要があります。
Without standard interfaces and security policy data models, the enforcement of a customer-driven security policy remains challenging because of the inherent complexity created by combining the invocation of several vendor-specific security functions into a multi-vendor, heterogeneous environment across multiple domains. Each vendor-specific function may require specific configuration procedures and operational tasks.
標準のインターフェイスとセキュリティポリシーデータモデルがないと、複数のドメインにまたがる複数ベンダーの異機種環境に複数のベンダー固有のセキュリティ機能の呼び出しを組み合わせることによって生じる固有の複雑さのため、顧客主導のセキュリティポリシーの実施は依然として困難です。各ベンダー固有の機能には、特定の構成手順と運用タスクが必要な場合があります。
Ensuring the consistent enforcement of the policies at various domains is also challenging. Standard data models are likely to contribute to solving that issue.
さまざまなドメインでポリシーを一貫して適用することを保証することも困難です。標準データモデルは、その問題の解決に貢献する可能性があります。
Software-Defined Networks have changed the landscape of data-center designs by introducing overlay networks deployed over Top-of-Rack (ToR) switches that connect to a hypervisor. SDN techniques are meant to improve the flexibility of workload management without affecting applications and how they work. Workload can thus be easily and seamlessly managed across private and public clouds. SDN techniques optimize resource usage and are now being deployed in various networking environments besides cloud infrastructures. Yet, such SDN-conferred agility may raise specific security issues. For example, a security administrator must make sure that a security policy can be enforced regardless of the location of the workload, thereby raising concerns about the ability of SDN computation logic to send security policy-provisioning information to the participating NSFs. A second example is workload migration to a public cloud infrastructure, which may raise additional security requirements during the migration.
Software-Defined Networksは、ハイパーバイザーに接続するTop-of-Rack（ToR）スイッチ上に展開されたオーバーレイネットワークを導入することにより、データセンター設計の状況を変えました。 SDN手法は、アプリケーションとその動作に影響を与えることなく、ワークロード管理の柔軟性を向上させることを目的としています。これにより、プライベートクラウドとパブリッククラウド全体でワークロードを簡単かつシームレスに管理できます。 SDN技術はリソースの使用を最適化し、現在、クラウドインフラストラクチャ以外のさまざまなネットワーキング環境に導入されています。しかし、そのようなSDNで与えられた俊敏性は、特定のセキュリティ問題を引き起こす可能性があります。たとえば、セキュリティ管理者は、ワークロードの場所に関係なくセキュリティポリシーを適用できることを確認する必要があります。これにより、SDN計算ロジックがセキュリティポリシープロビジョニング情報を参加NSFに送信する機能に懸念が生じます。 2番目の例は、パブリッククラウドインフラストラクチャへのワークロードの移行です。移行中に追加のセキュリティ要件が発生する可能性があります。
Standard interfaces for monitoring and controlling the behavior of NSFs are essential building blocks for security service providers and enterprises to automate the use of different NSFs from multiple vendors by their security management entities. I2NSF may be invoked by any (authorized) client. Examples of authorized clients are upstream applications (controllers), orchestration systems, and security portals.
NSFの動作を監視および制御するための標準インターフェイスは、セキュリティサービスプロバイダーおよび企業がセキュリティ管理エンティティによる複数のベンダーのさまざまなNSFの使用を自動化するための重要なビルディングブロックです。 I2NSFは、任意の（許可された）クライアントから呼び出すことができます。承認されたクライアントの例は、上流のアプリケーション（コントローラー）、オーケストレーションシステム、およびセキュリティポータルです。
Users request security services through specific clients (e.g., a customer application, the Business Support Systems / Operations Support Systems (BSSs/OSSs) of Network Service Providers (NSPs), or a management platform), and the appropriate NSP network entity will invoke the (v)NSFs according to the user service request. This network entity is denoted as the security controller in this document. The interaction between the entities discussed above (client, security controller, and NSF) is shown in Figure 2:
ユーザーは特定のクライアント（たとえば、顧客アプリケーション、ネットワークサービスプロバイダー（NSP）のビジネスサポートシステム/オペレーションサポートシステム（BSS / OSS）、または管理プラットフォーム）を通じてセキュリティサービスを要求し、適切なNSPネットワークエンティティが（v）ユーザーのサービス要求に応じたNSF。このドキュメントでは、このネットワークエンティティをセキュリティコントローラと表記しています。上記のエンティティ（クライアント、セキュリティコントローラ、NSF）間の相互作用を図2に示します。
+----------+
+-------+ | | +-------+
| | Interface 1 |Security | Interface 2 | NSF(s)|
|Client <--------------> <------------------> |
| | |Controller| | |
+-------+ | | +-------+
+----------+
Figure 2: Interaction between Entities
図2：エンティティ間の相互作用
Interface 1 is used for receiving security requirements from a client and translating them into commands that NSFs can understand and execute. The security controller also passes back NSF security reports (e.g., statistics) to the client that the security controller has gathered from NSFs. Interface 2 is used for interacting with NSFs according to commands (e.g., enact/revoke a security policy or distribute a policy) and collecting status information about NSFs.
インターフェイス1は、クライアントからセキュリティ要件を受け取り、それらをNSFが理解して実行できるコマンドに変換するために使用されます。また、セキュリティコントローラーは、NSFから収集したNSFセキュリティレポート（統計など）をクライアントに返します。インターフェース2は、コマンド（たとえば、セキュリティポリシーの制定/取り消しまたはポリシーの配布）に従ってNSFと対話し、NSFに関するステータス情報を収集するために使用されます。
Client devices or applications can require the security controller to add, delete, or update rules in the security service function for their specific traffic.
クライアントデバイスまたはアプリケーションは、特定のトラフィックのセキュリティサービス機能でルールを追加、削除、または更新するようにセキュリティコントローラーに要求できます。
When users want to get the executing status of a security service, they can request NSF status from the client. The security controller will collect NSF information through Interface 2, consolidate it, and give feedback to the client through Interface 1. This interface can be used to collect not only individual service information, but also aggregated data suitable for tasks like infrastructure security assessment.
ユーザーは、セキュリティサービスの実行ステータスを取得したい場合、クライアントにNSFステータスを要求できます。セキュリティコントローラーは、インターフェイス2を介してNSF情報を収集し、統合して、インターフェイス1を介してクライアントにフィードバックを提供します。このインターフェイスを使用して、個々のサービス情報だけでなく、インフラストラクチャのセキュリティ評価などのタスクに適した集約データも収集できます。
Customers may require validating NSF availability, provenance, and execution. This validation process, especially relevant to vNSFs, includes at least:
お客様は、NSFの可用性、来歴、および実行を検証する必要があります。特にvNSFに関連するこの検証プロセスには、少なくとも次のものが含まれます。
Integrity of the NSF: Ensuring that the NSF is not compromised;
NSFの完全性：NSFが危険にさらされないようにします。
Isolation: Ensuring the execution of the NSF is self-contained for privacy requirements in multi-tenancy scenarios; and
分離：NSFの実行がマルチテナンシーシナリオのプライバシー要件に対して自己完結型であることを保証します。そして
Provenance of the NSF: Customers may need to be provided with strict guarantees about the origin of the NSF, its status (e.g., available, idle, down, and others), and feedback mechanisms so that a customer may be able to check that a given NSF or set of NSFs properly conform to the customer's requirements and subsequent configuration tasks.
NSFの出所：NSFの発生元、そのステータス（使用可能、アイドル、ダウンなど）、およびフィードバックメカニズムについて顧客に厳密な保証を提供して、顧客が与えられたNSFまたはNSFのセットは、お客様の要件とその後の構成タスクに適切に準拠しています。
In order to achieve this, the security controller may collect security measurements and share them with an independent and trusted third party (via Interface 1) in order to allow for attestation of NSF functions using the third-party added information.
これを実現するために、セキュリティコントローラーはセキュリティ測定値を収集し、それらを独立した信頼できるサードパーティと（インターフェイス1を介して）共有して、サードパーティの追加情報を使用したNSF機能の証明を可能にします。
This implies that there may be the following two types of clients using Interface 1: the end user and the trusted, independent third party. The I2NSF work may determine that Interface 1 creates two sub-interfaces to support these two types of clients.
これは、インターフェイス1を使用する次の2種類のクライアントが存在する可能性があることを意味します。エンドユーザーと信頼できる独立したサードパーティ。 I2NSFの作業により、インターフェイス1が2つのサブインターフェイスを作成して、これら2つのタイプのクライアントをサポートすることが決定される場合があります。
This scenario describes use cases for users (e.g., residential user, enterprise user, mobile user, and management system) that request and manage security services hosted in the NSP infrastructure. Given that NSP customers are essentially users of their access networks, the scenario is essentially associated with their characteristics as well as with the use of vNSFs. Figure 3 shows how different types of customers connect through virtual access nodes (vCPE, vPE, and vEPC) to an NSF.
このシナリオでは、NSPインフラストラクチャでホストされているセキュリティサービスを要求および管理するユーザー（住宅用ユーザー、エンタープライズユーザー、モバイルユーザー、管理システムなど）の使用例について説明します。 NSPの顧客は基本的にアクセスネットワークのユーザーであることを考えると、シナリオは基本的に顧客の特性とvNSFの使用に関連しています。図3は、さまざまなタイプの顧客が仮想アクセスノード（vCPE、vPE、およびvEPC）を介してNSFに接続する方法を示しています。
The vCPE described in use case #7 in [NFVUC] requires a model of access virtualization that includes mobile and residential access networks where the operator may offload security services from the customer's local environment (e.g., device or terminal) to its own infrastructure.
[NFVUC]のユースケース＃7で説明されているvCPEには、モバイルと住宅のアクセスネットワークを含むアクセス仮想化のモデルが必要です。この仮想化では、オペレーターが顧客のローカル環境（デバイスや端末など）から独自のインフラストラクチャにセキュリティサービスをオフロードできます。
These use cases define the interaction between the operator and the vNSFs through automated interfaces that support the business communications between customer and provider or between two business entities.
これらのユースケースは、顧客とプロバイダー間、または2つのビジネスエンティティ間のビジネスコミュニケーションをサポートする自動化されたインターフェイスを介したオペレーターとvNSF間の相互作用を定義します。
Customer + Access + PoP / Data Center
| | +--------+
| ,-----+--. |Network |
| ,' | `-|Operator|
+-------------+ | /+----+ | |Mgmt Sys|
| Residential |-+------/-+vCPE+----+ +--------+
+-------------+ | / +----+ | \ | :
| / | \ | |
+----------+ | ; +----+ | +----+ |
|Enterprise|---+---+----+ vPE+--+----+ NSF| |
+----------+ | : +----+ | +----+ |
| : | / |
+--------+ | : +----+ | / ;
| Mobile |-+-----\--+vEPC+----+ /
+--------+ | \ +----+ | Service /
| `--. | Provider /
| `----+---------..
+ + ^^
||
Service Provider
encompasses
everything
in circle
vCPE - virtual customer premises equipment vPE - virtual provider edge vEPC - virtual evolved packet core PoP - point of presence
vCPE-仮想顧客宅内機器vPE-仮想プロバイダーエッジvEPC-仮想進化型パケットコアPoP-ポイントオブプレゼンス
Figure 3: NSF and Actors
図3：NSFとアクター
Different access clients may have different service requests:
アクセスクライアントが異なると、サービスリクエストも異なります。
Residential: service requests for parental control, content management, and threat management.
住宅：ペアレンタルコントロール、コンテンツ管理、脅威管理のサービスリクエスト。
Threat content management may include identifying and blocking malicious activities from web contents, mail, or files downloaded. Threat management may include identifying and blocking botnets or malware.
脅威コンテンツ管理には、ダウンロードされたWebコンテンツ、メール、またはファイルからの悪意のあるアクティビティの識別とブロックが含まれる場合があります。脅威の管理には、ボットネットやマルウェアの特定とブロックが含まれる場合があります。
Enterprise: service requests for enterprise flow security policies and managed security services.
エンタープライズ：エンタープライズフローセキュリティポリシーとマネージドセキュリティサービスのサービスリクエスト。
Flow security policies identify and block malicious activities during access to (or isolation from) web sites or social media applications. Managed security services for an enterprise may include detection and mitigation of external and internal threats. External threats can include application or phishing attacks, malware, botnet, DDoS, and others.
フローセキュリティポリシーは、Webサイトまたはソーシャルメディアアプリケーションへのアクセス中（または隔離中）の悪意のあるアクティビティを識別してブロックします。企業のマネージドセキュリティサービスには、外部および内部の脅威の検出と軽減が含まれる場合があります。外部の脅威には、アプリケーションまたはフィッシング攻撃、マルウェア、ボットネット、DDoSなどが含まれます。
Service Provider: service requests for policies that protect service provider networks against various threats (including DDoS, botnets, and malware). Such policies are meant to securely and reliably deliver contents (e.g., data, voice, and video) to various customers, including residential, mobile, and corporate customers. These security policies are also enforced to guarantee isolation between multiple tenants, regardless of the nature of the corresponding connectivity services.
サービスプロバイダー：サービスプロバイダーネットワークをさまざまな脅威（DDoS、ボットネット、マルウェアなど）から保護するポリシーのサービスリクエスト。このようなポリシーは、コンテンツ（データ、音声、ビデオなど）を住宅、モバイル、企業の顧客を含むさまざまな顧客に安全かつ確実に配信することを目的としています。これらのセキュリティポリシーは、対応する接続サービスの性質に関係なく、複数のテナント間の分離を保証するためにも適用されます。
Mobile: service requests from interfaces that monitor and ensure user quality of experience, content management, parental controls, and external threat management.
モバイル：ユーザーエクスペリエンスの品質、コンテンツ管理、ペアレンタルコントロール、および外部の脅威管理を監視および保証するインターフェイスからのサービスリクエスト。
Content management for the mobile device includes identifying and blocking malicious activities from web contents, mail, and files uploaded/downloaded. Threat management for infrastructure includes detecting and removing malicious programs such as botnet, malware, and other programs that create DDoS attacks).
モバイルデバイスのコンテンツ管理には、アップロード/ダウンロードされたWebコンテンツ、メール、ファイルからの悪意のあるアクティビティの識別とブロックが含まれます。インフラストラクチャの脅威管理には、ボットネット、マルウェア、およびDDoS攻撃を作成するその他のプログラムなどの悪意のあるプログラムの検出と削除が含まれます。
Some access customers may not care about which NSFs are utilized to achieve the services they requested. In this case, provider network orchestration systems can internally select the NSFs (or vNSFs) to enforce the security policies requested by the clients.
一部のアクセス顧客は、要求したサービスを実現するためにどのNSFが利用されているかを気にしない場合があります。この場合、プロバイダーネットワークオーケストレーションシステムはNSF（またはvNSF）を内部的に選択して、クライアントから要求されたセキュリティポリシーを適用できます。
Other access customers, especially some enterprise customers, may want to contract separately for dedicated NSFs (most likely vNSFs) for direct control purposes. In this case, here are the steps to associate vNSFs to specific customers:
他のアクセス顧客、特に一部の企業顧客は、直接制御の目的で専用のNSF（ほとんどの場合vNSF）について個別に契約することを希望する場合があります。この場合、vNSFを特定の顧客に関連付ける手順は次のとおりです。
vNSF Deployment: The deployment process consists of instantiating an NSF on an NFV Infrastructure (NFVI), within the NSP administrative domain(s) or with other external domain(s). This is a required step before a customer can subscribe to a security service supported in the vNSF.
vNSF展開：展開プロセスは、NFVインフラストラクチャ（NFVI）でのNSFのインスタンス化、NSP管理ドメイン内、または他の外部ドメインでのインスタンス化で構成されます。これは、顧客がvNSFでサポートされているセキュリティサービスにサブスクライブする前に必要な手順です。
vNSF Customer Provisioning: Once a vNSF is deployed, any customer can subscribe to it. The provisioning life cycle includes the following:
vNSF顧客プロビジョニング：vNSFが導入されると、すべての顧客がそれに加入できます。プロビジョニングのライフサイクルには、次のものが含まれます。
* Customer enrollment and cancellation of the subscription to a vNSF.
* お客様の登録とvNSFへのサブスクリプションのキャンセル。
* Configuration of the vNSF, based on specific configurations or derived from common security policies defined by the NSP.
* 特定の構成に基づく、またはNSPによって定義された共通のセキュリティポリシーから派生したvNSFの構成。
* Retrieval of the vNSF functionalities, extracted from a manifest or a descriptor. The NSP management systems can demand this information to offer detailed information through the commercial channels to the customer.
* マニフェストまたは記述子から抽出されたvNSF機能の取得。 NSP管理システムは、商業チャネルを通じて顧客に詳細情報を提供するためにこの情報を要求できます。
In a data center, network security mechanisms such as firewalls may need to be dynamically added or removed for a number of reasons. These changes may be explicitly requested by the user or triggered by a pre-agreed-upon demand level in the Service Level Agreement (SLA) between the user and the provider of the service. For example, the service provider may be required to add more firewall capacity within a set of time frames whenever the bandwidth utilization hits a certain threshold for a specified period. This capacity expansion could result in adding new instances of firewalls on existing machines or provisioning a completely new firewall instance in a different machine.
データセンターでは、ファイアウォールなどのネットワークセキュリティメカニズムをさまざまな理由で動的に追加または削除する必要がある場合があります。これらの変更は、ユーザーによって明示的に要求されるか、ユーザーとサービスのプロバイダーの間のサービスレベルアグリーメント（SLA）の事前に合意された需要レベルによってトリガーされます。たとえば、サービスプロバイダーは、帯域幅の使用率が指定された期間に特定のしきい値に達するたびに、一連の時間枠内にファイアウォールキャパシティを追加する必要がある場合があります。この容量拡張により、既存のマシンにファイアウォールの新しいインスタンスが追加されたり、別のマシンに完全に新しいファイアウォールインスタンスがプロビジョニングされたりする可能性があります。
The on-demand, dynamic nature of security service delivery essentially encourages that the network security "devices" be in software or virtual forms rather than in a physical appliance form. This requirement is a provider-side concern. Users of the firewall service are agnostic (as they should be) as to whether or not the firewall service is run on a VM or any other form factor. Indeed, they may not even be aware that their traffic traverses firewalls.
セキュリティサービス配信のオンデマンドで動的な性質により、ネットワークセキュリティの「デバイス」は、物理的なアプライアンスの形式ではなく、ソフトウェアまたは仮想の形式であることが本質的に推奨されます。この要件はプロバイダー側の懸念事項です。ファイアウォールサービスのユーザーは、ファイアウォールサービスがVMまたはその他のフォームファクターで実行されているかどうかにとらわれません（あるべき姿）。実際、トラフィックがファイアウォールを通過していることさえ知らないかもしれません。
Furthermore, new firewall instances need to be placed in the "right zone" (domain). The issue applies not only to multi-tenant environments where getting the tenant in the right domain is of paramount importance, but also in environments owned and operated by a single organization with its own service segregation policies. For example, an enterprise may mandate that firewalls serving Internet traffic within the organization be separated from inter-organization traffic. Another example is IPS/IDS services that split investment banking traffic from other data traffic to comply with regulatory restrictions for transfer of investment banking information.
さらに、新しいファイアウォールインスタンスを「右ゾーン」（ドメイン）に配置する必要があります。この問題は、適切なドメインでテナントを取得することが最も重要なマルチテナント環境だけでなく、独自のサービス分離ポリシーを持つ単一の組織によって所有および運用されている環境にも当てはまります。たとえば、企業は、組織内のインターネットトラフィックを処理するファイアウォールを組織間トラフィックから分離することを義務付ける場合があります。もう1つの例は、投資銀行情報を他のデータトラフィックから分割して、投資銀行情報の転送に関する規制上の制限に準拠するIPS / IDSサービスです。
A cloud data center operated by a service provider could serve tens of thousands of clients. Clients' compute servers are typically hosted on VMs, which could be deployed across different server racks located in different parts of the data center. It is often not technically and/or financially feasible to deploy dedicated physical firewalls to suit each client's security policy requirements, which can be numerous. What is needed is the ability to dynamically deploy virtual firewalls for each client's set of servers based on established security policies and underlying network topologies. Figure 4 shows an example topology of virtual firewalls within a data center.
サービスプロバイダーが運営するクラウドデータセンターは、数万のクライアントにサービスを提供できます。クライアントの計算サーバーは通常、VMでホストされ、データセンターのさまざまな部分にあるさまざまなサーバーラックに展開できます。多くの場合、各クライアントのセキュリティポリシー要件に合わせて専用の物理ファイアウォールを展開することは、技術的および/または経済的に実現できないことがよくあります。必要なのは、確立されたセキュリティポリシーと基盤となるネットワークトポロジに基づいて、各クライアントのサーバーセットに対して仮想ファイアウォールを動的に展開する機能です。図4は、データセンター内の仮想ファイアウォールのトポロジ例を示しています。
---+-----------------------------+-----
| |
+---+ +-+-+
|vFW| |vFW|
+---+ +-+-+
| Client #1 | Client #2
---+-------+--- ---+-------+---
+-+-+ +-+-+ +-+-+ +-+-+
|VM | |VM | |VM | |VM |
+---+ +---+ +---+ +---+
Figure 4: NSF in Data Centers
図4：データセンターのNSF
Firewall rules apply to traffic usually identified with addresses and ports. It becomes far more complex in provider-owned cloud networks that serve myriads of customers.
ファイアウォールルールは、通常アドレスとポートで識別されるトラフィックに適用されます。無数の顧客にサービスを提供するプロバイダー所有のクラウドネットワークでは、はるかに複雑になります。
Firewall rules today are highly tied with ports and addresses that identify traffic. This makes it very difficult for clients of cloud data centers to construct rules for their own traffic, as the clients only see the virtual networks and the virtual addresses. The customer-visible virtual networks and addresses may be different from the actual packets traversing the firewalls.
現在のファイアウォールルールは、トラフィックを識別するポートとアドレスと密接に関連しています。これにより、クライアントは仮想ネットワークと仮想アドレスしか認識できないため、クラウドデータセンターのクライアントが自分のトラフィックのルールを構築することが非常に困難になります。お客様から見える仮想ネットワークとアドレスは、ファイアウォールを通過する実際のパケットとは異なる場合があります。
Even though most vendors support similar firewall features, the specific rule configuration keywords are different from vendor to vendor, making it difficult for automation. Automation works best when it can leverage a common set of standards that will work across NSFs by multiple vendors and utilize dynamic key management.
ほとんどのベンダーが同様のファイアウォール機能をサポートしていますが、特定のルール構成キーワードはベンダーごとに異なり、自動化が困難です。自動化は、複数のベンダーによるNSF全体で機能し、動的なキー管理を利用する共通の標準セットを活用できる場合に最適に機能します。
Clients of cloud data centers operated by a service provider need to secure Virtual Private Networks (VPNs) and virtual security functions that apply the clients' security policies. The security policies may govern communication within the clients' own virtual networks as well as communication with external networks. For example, VPN service providers may need to provide firewall and other security services to their VPN clients. Today, it is generally not possible for clients to dynamically view (let alone change) what, where, and how security policies are implemented on their provider-operated clouds. Indeed, no standards-based framework exists to allow clients to retrieve/ manage security policies in a consistent manner across different providers.
サービスプロバイダーが運営するクラウドデータセンターのクライアントは、クライアントのセキュリティポリシーを適用する仮想プライベートネットワーク（VPN）および仮想セキュリティ機能を保護する必要があります。セキュリティポリシーは、クライアント自身の仮想ネットワーク内の通信と外部ネットワークとの通信を管理する場合があります。たとえば、VPNサービスプロバイダーは、ファイアウォールやその他のセキュリティサービスをVPNクライアントに提供する必要がある場合があります。現在、クライアントがプロバイダーが運用するクラウドにセキュリティポリシーが実装されている場所、場所、および方法を動的に表示（変更はもちろん）することは一般に不可能です。実際、クライアントがさまざまなプロバイダー間で一貫した方法でセキュリティポリシーを取得/管理できるようにする標準ベースのフレームワークはありません。
As described above, the dynamic key management is critical for securing the VPN and the distribution of policies.
上記のように、動的なキー管理は、VPNの保護とポリシーの配布に不可欠です。
There are many types of internal traffic monitors that may be managed by a security controller. This includes the class of services referred to as Data Loss Prevention (DLP) or Reputation Protection Services (RPS). Depending on the class of event, alerts may go to internal administrators or external services.
セキュリティコントローラーで管理できる内部トラフィックモニターには多くの種類があります。これには、データ損失防止（DLP）または評判保護サービス（RPS）と呼ばれるサービスのクラスが含まれます。イベントのクラスに応じて、アラートは内部管理者または外部サービスに送信される場合があります。
On the Internet, where everything is connected, preventing unwanted traffic that may cause a DoS attack or a DDoS attack has become a challenge. Similarly, a network could be exposed to malware attacks and become an attack vector that may jeopardize the operation of other networks, by means of remote commands for example. Many networks that carry groups of information (such as Internet of Things (IoT) networks, Information-Centric Networks (ICNs), Content Delivery Networks (CDNs), Voice over IP (VoIP) packet networks, and Voice over LTE (VoLTE)) are also exposed to such remote attacks. There are many examples of remote attacks on these networks, but the following examples will illustrate the issues. A malware attack on an IoT network that carries sensor readings and instructions may attempt to alter the sensor instructions in order to disable a key sensor. A malware attack on VoIP or VoLTE networks involves software that attempts to place unauthorized long-distance calls. Botnets may overwhelm nodes in ICNs and CDNs so that the networks cannot pass critical data.
すべてが接続されているインターネットでは、DoS攻撃やDDoS攻撃を引き起こす可能性のある不要なトラフィックを防ぐことが課題となっています。同様に、ネットワークはマルウェア攻撃にさらされて、たとえばリモートコマンドによって他のネットワークの動作を危険にさらす可能性のある攻撃ベクトルになる可能性があります。情報のグループを運ぶ多くのネットワーク（モノのインターネット（IoT）ネットワーク、情報中心ネットワーク（ICN）、コンテンツ配信ネットワーク（CDN）、Voice over IP（VoIP）パケットネットワーク、Voice over LTE（VoLTE）など）このようなリモート攻撃にもさらされています。これらのネットワークに対するリモート攻撃の例はたくさんありますが、次の例は問題を示しています。センサーの読み取り値と指示を運ぶIoTネットワークに対するマルウェア攻撃は、主要なセンサーを無効にするためにセンサーの指示を変更しようとする可能性があります。 VoIPまたはVoLTEネットワークに対するマルウェア攻撃には、不正な長距離通話を発信しようとするソフトウェアが含まれます。ボットネットは、ネットワークが重要なデータを渡せないように、ICNおよびCDNのノードを圧倒する可能性があります。
In order for organizations to better secure their networks against these kind of attacks, the I2NSF framework should provide a client-side interface that is use case independent and technology agnostic. Technology agnostic is defined to be generic, technology independent, and able to support multiple protocols and data models. For example, such an I2NSF interface could be used to provision security policy configuration information that looks for specific malware signatures. Similarly, botnet attacks could be easily prevented by provisioning security policies using the I2NSF client-side interface that prevents access to botnet command and control servers.
組織がこの種の攻撃からネットワークをより安全に保護するために、I2NSFフレームワークは、ユースケースに依存せず、テクノロジーにとらわれないクライアント側インターフェースを提供する必要があります。テクノロジーにとらわれず、汎用的でテクノロジーに依存せず、複数のプロトコルとデータモデルをサポートできるように定義されています。たとえば、このようなI2NSFインターフェイスを使用して、特定のマルウェアシグネチャを探すセキュリティポリシー構成情報をプロビジョニングできます。同様に、ボットネットコマンドおよび制御サーバーへのアクセスを防止するI2NSFクライアント側インターフェースを使用してセキュリティポリシーをプロビジョニングすることにより、ボットネット攻撃を簡単に防止できます。
Organizations must protect their networks against attacks and must also adhere to various industry regulations: any organization that falls under a specific regulation, like the Payment Card Industry - Data Security Standard (PCI-DSS) [PCI-DSS] for the payment industry or the Health Insurance Portability and Accountability Act [HIPAA] for the healthcare industry, must be able to isolate various kinds of traffic. They must also show records of their security policies whenever audited.
組織は攻撃からネットワークを保護する必要があり、さまざまな業界の規制も遵守する必要があります。特定の規制に該当する組織。たとえば、決済カード業界-決済業界向けのPCI-DSS（PCI-DSS）[PCI-DSS]など。医療業界向けの医療保険の相互運用性と説明責任に関する法律[HIPAA]は、さまざまな種類のトラフィックを分離できる必要があります。また、監査の際には、セキュリティポリシーの記録も表示する必要があります。
The I2NSF client-side interface could be used to provision regulatory and compliance-related security policies. The security controller would keep track of when and where a specific policy is applied and if there is any policy violation; this information can be provided in the event of an audit as proof that traffic is isolated between specific endpoints, in full compliance with the required regulations.
I2NSFクライアント側インターフェースを使用して、規制およびコンプライアンス関連のセキュリティポリシーをプロビジョニングできます。セキュリティコントローラは、特定のポリシーがいつどこで適用されたか、およびポリシー違反があるかどうかを追跡します。この情報は、監査の際に、必要な規制に完全に準拠して、トラフィックが特定のエンドポイント間で分離されている証拠として提供できます。
Management of NSFs usually include the following:
NSFの管理には通常、次のものが含まれます。
o Life-cycle management and resource management of NSFs,
o NSFのライフサイクル管理とリソース管理
o Device configuration, such as address configuration, device internal attributes configuration, etc.,
o アドレス構成、デバイスの内部属性構成などのデバイス構成
o Signaling of events, notifications, and changes, and
o イベント、通知、変更の通知、および
o Policy rule provisioning.
o ポリシールールのプロビジョニング。
I2NSF will only focus on the policy provisioning part of NSF management.
I2NSFは、NSF管理のポリシープロビジョニング部分にのみ焦点を当てます。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
Having secure access to control and monitor NSFs is crucial for hosted security services. An I2NSF security controller raises new security threats. It needs to be resilient to attacks and quickly recover from them. Therefore, proper secure communication channels have to be carefully specified for carrying, controlling, and monitoring traffic between the NSFs and their management entity (or entities).
NSFを制御および監視するための安全なアクセス権は、ホスト型セキュリティサービスにとって非常に重要です。 I2NSFセキュリティコントローラーは、新しいセキュリティの脅威を引き起こします。攻撃に対する耐性があり、攻撃から迅速に回復する必要があります。したがって、NSFとその管理エンティティ（1つまたは複数）間のトラフィックを伝送、制御、および監視するために、適切な安全な通信チャネルを慎重に指定する必要があります。
The traffic flow security policies specified by customers can conflict with providers' internal traffic flow security policies. This conflict can be resolved in one of two ways: a) installed policies can restrict traffic if either the customer traffic flow security policies or the provider's internal security policies restrict traffic, or b) installed policies can only restrict traffic if both the customer traffic flow security policies and the provider's internal traffic flow security policies restrict data. Either choice could cause potential problems. It is crucial for the management system to flag these conflicts to the customers and to the service provider.
顧客が指定したトラフィックフローセキュリティポリシーは、プロバイダーの内部トラフィックフローセキュリティポリシーと競合する可能性があります。この競合は次の2つの方法のいずれかで解決できます。a）顧客のトラフィックフローのセキュリティポリシーまたはプロバイダーの内部セキュリティポリシーのいずれかがトラフィックを制限している場合、インストールされているポリシーはトラフィックを制限できます。セキュリティポリシーとプロバイダーの内部トラフィックフローのセキュリティポリシーは、データを制限します。どちらを選択しても問題が発生する可能性があります。管理システムがこれらの競合を顧客とサービスプロバイダーに通知することは重要です。
It is important to proper AAA [RFC2904] to authorize access to the network and access to the I2NSF management stream.
ネットワークへのアクセスとI2NSF管理ストリームへのアクセスを承認するには、適切なAAA [RFC2904]が重要です。
Enforcing the appropriate privacy is key to all IETF protocols (see [RFC6973]) and is especially important for IETF security management protocols since they are deployed to protect the network. In some circumstances, security management protocols may be utilized to protect an individual's home, phone, or other personal data. In this case, any solution should carefully consider whether combining management streams abides by the recommendations of [RFC6973] for data minimization, user participation, and security.
適切なプライバシーの適用はすべてのIETFプロトコル（[RFC6973]を参照）の鍵であり、ネットワークを保護するために展開されるため、IETFセキュリティ管理プロトコルにとって特に重要です。状況によっては、セキュリティ管理プロトコルを使用して、個人の家、電話、またはその他の個人データを保護する場合があります。この場合、どのソリューションでも、管理ストリームの組み合わせが、データの最小化、ユーザー参加、およびセキュリティに関する[RFC6973]の推奨事項を順守しているかどうかを慎重に検討する必要があります。
[ACCESS-USECASE] Wang, K. and X. Zhuang, "Integrated Security with Access Network Use Case", Work in Progress, draft-qi-i2nsf-access-network-usecase-02, March 2015.
[ACCESS-USECASE] Wang、K。およびX. Zhuang、「Integrated Security with Access Network Use Case」、Work in Progress、draft-qi-i2nsf-access-network-usecase-02、2015年3月。
[CAP-INTERFACE] Zhou, C., Xia, L., Boucadair, M., and J. Xiong, "The Capability Interface for Monitoring Network Security Functions (NSF) in I2NSF", Work in Progress, draft-zhou-i2nsf-capability-interface-monitoring-00, October 2015.
[CAP-INTERFACE] Zhou、C.、Xia、L.、Boucadair、M.、J。Xiong、「I2NSFでネットワークセキュリティ機能（NSF）を監視するための機能インターフェイス」、作業中、draft-zhou-i2nsf -capability-interface-monitoring-00、2015年10月。
[CTA] "Cyber Threat Alliance", <http://cyberthreatalliance.org>.
[CTA]「サイバー脅威同盟」、<http://cyberthreatalliance.org>。
[DC-USECASE] Zarny, M., Majee, S., Leymann, N., and L. Dunbar, "I2NSF Data Center Use Cases", Work in Progress, draft-zarny-i2nsf-data-center-use-cases-00, October 2014.
[DC-USECASE] Zarny、M.、Majee、S.、Leymann、N。、およびL. Dunbar、「I2NSF Data Center Use Cases」、Work in Progress、draft-zarny-i2nsf-data-center-use-cases -00、2014年10月。
[EPC-3GPP] Firmin, F., "The Evolved Packet Core", January 2017.
[EPC-3GPP] Firmin、F。、「The Evolved Packet Core」、2017年1月。
[ETSI-NFV] ETSI, "Network Functions Virtualisation (NFV); Architectural Framework", ETSI GS NFV 002 V1.2.1, December 2014.
[ETSI-NFV] ETSI、「Network Functions Virtualization（NFV）; Architectural Framework」、ETSI GS NFV 002 V1.2.1、2014年12月。
[FIREWALLS] Baker, F. and P. Hoffman, "On Firewalls in Internet Security", Work in Progress, draft-ietf-opsawg-firewalls-01, October 2012.
[ファイアウォール]ベイカー、F.、P。ホフマン、「インターネットセキュリティのファイアウォールについて」、作業中、draft-ietf-opsawg-firewalls-01、2012年10月。
[Gartner] Messmer, E., "Gartner: Cloud-based security as a service set to take off", October 2013.
[Gartner] Messmer、E。、「Gartner：Cloud-based security as a service set to take to set」、2013年10月。
[HIPAA] US Congress, "Health Insurance Portability and Accountability Act of 1996 (Public Law 104-191)", August 1996, <https://www.hhs.gov/hipaa/>.
[HIPAA]米国議会、「1996年の医療保険の相互運用性と説明責任に関する法律（公法104-191）」、1996年8月、<https://www.hhs.gov/hipaa/>。
[I2NSF-ANALYSIS] Hares, S., Moskowitz, R., and D. Zhang, "Analysis of Existing work for I2NSF", Work in Progress, draft-ietf-i2nsf-gap-analysis-03, March 2017.
[I2NSF-ANALYSIS] Hares、S.、Moskowitz、R。、およびD. Zhang、「Analysis of Existing work for I2NSF」、Work in Progress、draft-ietf-i2nsf-gap-analysis-03、2017年3月。
[I2NSF-USECASES] Pastor, A., Lopez, D., Wang, K., Zhuang, X., Qi, M., Zarny, M., Majee, S., Leymann, N., Dunbar, L., and M. Georgiades, "Use Cases and Requirements for an Interface to Network Security Functions", Work in Progress, draft-pastor-i2nsf-merged-use-cases-00, June 2015.
[I2NSF-USECASES]牧師、A.、Lopez、D.、Wang、K.、Zhuang、X.、Qi、M.、Zarny、M.、Majee、S.、Leymann、N.、Dunbar、L。、 M.ジョージアデス、「ネットワークセキュリティ機能へのインターフェイスの使用例と要件」、作業中、draft-pastor-i2nsf-merged-use-cases-00、2015年6月。
[NFVUC] ETSI, "Network Functions Virtualization (NFV); Use Cases", ETSI GR NFV 001 V1.2.1, May 2017.
[NFVUC] ETSI、「ネットワーク機能仮想化（NFV）;使用例」、ETSI GR NFV 001 V1.2.1、2017年5月。
[OAM-USECASE] Pastor, A. and D. Lopez, "Access Use Cases for an Open OAM Interface to Virtualized Security Services", Work in Progress, draft-pastor-i2nsf-access-usecases-00, October 2014.
[OAM-USECASE]牧師、A。およびD.ロペス、「仮想化セキュリティサービスへのオープンOAMインターフェイスのアクセスユースケース」、作業中、draft-pastor-i2nsf-access-usecases-00、2014年10月。
[PCI-DSS] PCI Security Standards Council, "Payment Card Industry (PCI) Data Security Standard -- Requirements and Security Assessment Procedures", PCS DSS v3.2, April 2016, <https://www.pcisecuritystandards.org/pci_security/>.
[PCI-DSS] PCI Security Standards Council、「Payment Card Industry（PCI）Data Security Standard-Requirements and Security Assessment Procedures」、PCS DSS v3.2、2016年4月、<https://www.pcisecuritystandards.org/pci_security />。
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and D. Spence, "AAA Authorization Framework", RFC 2904, DOI 10.17487/RFC2904, August 2000, <http://www.rfc-editor.org/info/rfc2904>.
[RFC2904] Vollbrecht、J.、Calhoun、P.、Farrell、S.、Gommans、L.、Gross、G.、de Bruijn、B.、de Laat、C.、Holdrege、M。、およびD. Spence、 「AAA Authorization Framework」、RFC 2904、DOI 10.17487 / RFC2904、2000年8月、<http://www.rfc-editor.org/info/rfc2904>。
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, DOI 10.17487/RFC4948, August 2007, <http://www.rfc-editor.org/info/rfc4948>.
[RFC4948] Andersson、L.、Davies、E.、and L. Zhang、 "Report from the IAB Workshop on Unwanted Traffic March 9-10、2006"、RFC 4948、DOI 10.17487 / RFC4948、2007年8月、<http：/ /www.rfc-editor.org/info/rfc4948>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<http://www.rfc-editor.org/info / rfc5925>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<http://www.rfc-editor.org/info/rfc6973>。
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <http://www.rfc-editor.org/info/rfc7149>.
[RFC7149] Boucadair、M。およびC. Jacquenet、「Software-Defined Networking：A Perspective from a Service Provider Environment」、RFC 7149、DOI 10.17487 / RFC7149、2014年3月、<http：//www.rfc-editor。 org / info / rfc7149>。
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <http://www.rfc-editor.org/info/rfc7426>.
[RFC7426] Haleplidis、E。、編、Pentikousis、K。、編、Denazis、S.、Hadi Salim、J.、Meyer、D.、O。Koufopavlou、「ソフトウェア定義ネットワーキング（SDN）：レイヤーand Architecture Terminology」、RFC 7426、DOI 10.17487 / RFC7426、2015年1月、<http://www.rfc-editor.org/info/rfc7426>。
[SDN-SECURITY] Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee, "Software-Defined Networking Based Security Services using Interface to Network Security Functions", Work in Progress, draft-jeong-i2nsf-sdn-security-services-05, July 2016.
[SDN-SECURITY] Jeong、J.、Kim、H.、Park、J.、Ahn、T。、およびS. Lee、「ネットワークセキュリティ機能へのインターフェイスを使用したソフトウェア定義のネットワークベースのセキュリティサービス」、進行中の作業、 draft-jeong-i2nsf-sdn-security-services-05、2016年7月。
Acknowledgments
謝辞
This document was supported by the Institute for Information & Communications Technology Promotion (IITP), which is funded by the Ministry of Science, ICT & Future Planning (MSIP) (R0166-15-1041, Standard Development of Network Security based SDN).
このドキュメントは、情報通信技術振興協会（IITP）によってサポートされています。IITPは、科学省、ICTおよび未来計画（MSIP）（R0166-15-1041、ネットワークセキュリティに基づくSDNの標準開発）から資金提供を受けています。
Contributors
貢献者
I2NSF is a group effort. The following people actively contributed to the initial use case text: Xiaojun Zhuang (China Mobile), Sumandra Majee (F5), Ed Lopez (Curveball Networks), and Robert Moskowitz (Huawei).
I2NSFはグループの取り組みです。次の人々は、初期のユースケーステキストに積極的に貢献しました：Xiaojun Zhuang（China Mobile）、Sumandra Majee（F5）、Ed Lopez（Curveball Networks）、およびRobert Moskowitz（Huawei）。
I2NSF has had a number of contributing authors. The following are considered co-authors:
I2NSFには多数の寄稿者がいます。以下は共著者と見なされます。
o Linda Dunbar (Huawei)
o リンダ・ダンバー（hu A for）
o Antonio Pastur (Telefonica I+D)
o アントニオパスツール（Telefonica I + D）
o Mohamed Boucadair (France Telecom)
o Mohamed Bessdir（Frank Telcom）
o Michael Georgiades (Prime Tel)
o Michael Georgiades（Prime Tel）
o Minpeng Qi (China Mobile)
o min touch Q i（China Mobile）
o Shaibal Chakrabarty (US Ignite)
o Shaibal Chakrabarty（US Ignite）
o Nic Leymann (Deutsche Telekom)
o ニック・レイマン（ドイツテレコム）
o Anil Lohiya (Juniper)
o Anil Lohia（ジュニパー）
o David Qi (Bloomberg)
o David Q i（ブルームバーグ）
o Hyoungshick Kim (Sungkyunkwan University)
o キム・ヒョンシク（成均館大学）
o Jung-Soo Park (ETRI)
o チョンスー公園（ETRI）
o Tae-Jin Ahn (Korea Telecom)
o たえーじん あｈん （これあ てぇこｍ）
o Se-Hui Lee (Korea Telecom)
o Se-Hui Lee（Korea Telecom）
Authors' Addresses
著者のアドレス
Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 United States of America
Susan Hares Huawei 7453 Hickory Hill Saline、MI 48176アメリカ合衆国
Phone: +1-734-604-0332 Email: shares@ndzh.com Diego R. Lopez Telefonica I+D Don Ramon de la Cruz, 82 Madrid 28006 Spain
電話：+ 1-734-604-0332メール：shares@ndzh.com Diego R. Lopez Telefonica I + D Don Ramon de la Cruz、82 Madrid 28006 Spain
Email: diego.r.lopez@telefonica.com
Myo Zarny vArmour 800 El Camino Real, Suite 3000 Mountain View, CA 94040 United States of America
Myo Zarny vArmour 800 El Camino Real、Suite 3000 Mountain View、CA 94040アメリカ合衆国
Email: myo@varmour.com
Christian Jacquenet France Telecom Rennes, 35000 France
Christian Jacquenet France Telecom Rennes、35000 France
Email: Christian.jacquenet@orange.com
Rakesh Kumar Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America
Rakesh Kumar Juniper Networks 1133 Innovation Way Sunnyvale、CA 94089アメリカ合衆国
Email: rakeshkumarcloud@gmail.com
Jaehoon Paul Jeong Department of Software Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea
ジェフンポールジョンソフトウェア学科成均館大学2066西部路、タンパ区水原京畿道16419韓国
Phone: +82 31 299 4957
Fax: +82 31 290 7996
Email: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php