[要約] RFC 8241は、I2RSセキュリティ関連要件に関するインターフェースを提供するためのガイドラインです。その目的は、ネットワークルーティングシステムのセキュリティを向上させるための要件を定義することです。
Internet Engineering Task Force (IETF) S. Hares
Request for Comments: 8241 Huawei
Category: Informational D. Migault
ISSN: 2070-1721 J. Halpern
Ericsson
September 2017
Interface to the Routing System (I2RS) Security-Related Requirements
ルーティングシステム（I2RS）のセキュリティ関連の要件へのインターフェイス
Abstract
概要
This document presents security-related requirements for the Interface to the Routing System (I2RS) protocol, which provides a new interface to the routing system described in the I2RS architecture document (RFC 7921). The I2RS protocol is implemented by reusing portions of existing IETF protocols and adding new features to them. One such reuse is of the security features of a secure transport (e.g., Transport Layer Security (TLS), Secure SHell (SSH) Protocol, Datagram TLS (DTLS)) such as encryption, message integrity, mutual peer authentication, and anti-replay protection. The new I2RS features to consider from a security perspective are as follows: a priority mechanism to handle multi-headed write transactions, an opaque secondary identifier that identifies an application using the I2RS client, and an extremely constrained read-only non-secure transport.
このドキュメントは、I2RSアーキテクチャドキュメント（RFC 7921）で説明されているルーティングシステムへの新しいインターフェイスを提供する、ルーティングシステム（I2RS）プロトコルへのインターフェイスのセキュリティ関連の要件を示しています。 I2RSプロトコルは、既存のIETFプロトコルの一部を再利用し、それらに新しい機能を追加することによって実装されます。このような再利用の1つは、暗号化、メッセージの整合性、相互ピア認証、リプレイ防止などの安全なトランスポート（トランスポート層セキュリティ（TLS）、Secure SHell（SSH）プロトコル、データグラムTLS（DTLS）など）のセキュリティ機能です。保護。セキュリティの観点から検討する必要がある新しいI2RS機能は次のとおりです。マルチヘッド書き込みトランザクションを処理する優先メカニズム、I2RSクライアントを使用してアプリケーションを識別する不透明なセカンダリ識別子、非常に制約された読み取り専用の非セキュアトランスポート。
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 https://www.rfc-editor.org/info/rfc8241.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8241で入手できます。
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 (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. Terminology and Concepts ........................................4
2.1. Requirements Language ......................................4
2.2. Security Terminology .......................................4
2.3. I2RS-Specific Terminology ..................................5
2.4. Concepts ...................................................5
3. Security Features and Protocols: Reused and New .................6
3.1. Security Protocols Reused by the I2RS Protocol .............6
3.2. New Features Related to Security ...........................7
3.3. I2RS Protocol Security Requirements vs. IETF
Management Protocols .......................................8
4. Security-Related Requirements ..................................10
4.1. I2RS Peer (Agent and Client) Identity Authentication ......10
4.2. Identity Validation before Role-Based Message Actions .....11
4.3. Peer Identity, Priority, and Client Redundancy ............12
4.4. Multi-Channel Transport: Secure and Non-Secure ............13
4.5. Management Protocol Security ..............................15
4.6. Role-Based Data Model Security ............................16
4.7. Security of the Environment ...............................17
5. IANA Considerations ............................................17
6. Security Considerations ........................................17
7. References .....................................................18
7.1. Normative References ......................................18
7.2. Informative References ....................................18
Acknowledgements ..................................................20
Authors' Addresses ................................................20
The Interface to the Routing System (I2RS) protocol provides read and write access to information and state within the routing system. An I2RS client interacts with one or more I2RS agents to collect information from network routing systems. [RFC7921] describes the architecture of this interface, and this document assumes the reader is familiar with this architecture and its definitions.
ルーティングシステムへのインターフェイス（I2RS）プロトコルは、ルーティングシステム内の情報と状態への読み取りおよび書き込みアクセスを提供します。 I2RSクライアントは、1つ以上のI2RSエージェントと対話して、ネットワークルーティングシステムから情報を収集します。 [RFC7921]はこのインターフェースのアーキテクチャを説明しており、このドキュメントは読者がこのアーキテクチャとその定義に精通していることを前提としています。
The I2RS interface is instantiated by the I2RS protocol connecting an I2RS client and an I2RS agent associated with a routing system. The I2RS protocol is implemented by reusing portions of existing IETF protocols and adding new features to them. As a reuse protocol, it can be considered a higher-layer protocol because it can be instantiated in multiple management protocols (e.g., NETCONF [RFC6241] or RESTCONF [RFC8040]) operating over a secure transport. These protocols are what provide its security.
I2RSインターフェイスは、ルーティングシステムに関連付けられたI2RSクライアントとI2RSエージェントを接続するI2RSプロトコルによってインスタンス化されます。 I2RSプロトコルは、既存のIETFプロトコルの一部を再利用し、それらに新しい機能を追加することによって実装されます。再利用プロトコルとして、セキュアなトランスポート上で動作する複数の管理プロトコル（NETCONF [RFC6241]またはRESTCONF [RFC8040]など）でインスタンス化できるため、上位層プロトコルと見なすことができます。これらのプロトコルは、そのセキュリティを提供するものです。
This document is part of a suite of documents outlining requirements for the I2RS protocol, which also includes the following:
このドキュメントは、I2RSプロトコルの要件を概説する一連のドキュメントの一部であり、以下も含まれています。
o "An Architecture for the Interface to the Routing System" [RFC7921]
o 「ルーティングシステムへのインターフェースのアーキテクチャ」[RFC7921]
o "I2RS Ephemeral State Requirements" [RFC8242]
o 「I2RS一時的な状態の要件」[RFC8242]
o "Interface to the Routing System (I2RS) Traceability: Framework and Information Model" (which discusses traceability) [RFC7923]
o 「ルーティングシステム（I2RS）トレーサビリティへのインターフェイス：フレームワークと情報モデル」（トレーサビリティについて説明）[RFC7923]
o "Requirements for Subscription to YANG Datastores" (which highlights the publication/subscription requirements) [RFC7922]
o 「YANGデータストアへのサブスクリプションの要件」（パブリケーション/サブスクリプションの要件を強調）[RFC7922]
Since the I2RS "higher-layer" protocol changes the interface to the routing systems, it is important that implementers understand the new security requirements for the environment the I2RS protocol operates in. A summary of the I2RS protocol security environment is found in the I2RS architecture [RFC7921].
I2RS「上位層」プロトコルはルーティングシステムへのインターフェイスを変更するため、I2RSプロトコルが動作する環境の新しいセキュリティ要件を実装者が理解することが重要です。I2RSプロトコルセキュリティ環境の概要はI2RSアーキテクチャにあります[RFC7921]。
I2RS reuses the secure transport protocols (TLS, SSH, DTLS) that support encryption, message integrity, peer authentication, and key distribution protocols. Optionally, implementers may utilize Authentication, Authorization, and Accounting (AAA) protocols (Radius over TLS or Diameter over TLS) to securely distribute identity information.
I2RSは、暗号化、メッセージ整合性、ピア認証、および鍵配布プロトコルをサポートするセキュアなトランスポートプロトコル（TLS、SSH、DTLS）を再利用します。必要に応じて、実装者は認証、承認、アカウンティング（AAA）プロトコル（Radius over TLSまたはDiameter over TLS）を利用して、ID情報を安全に配布できます。
Section 2 highlights some of the terminology and concepts that the reader is required to be familiar with.
セクション2では、読者が熟知する必要のある用語と概念のいくつかを取り上げています。
Section 3 provides an overview of security features and protocols being reused (Section 3.1), lists the new security features being required (Section 3.2), and explores how existing and new security features and protocols would be paired with existing IETF management protocols (Section 3.3).
セクション3では、再利用されるセキュリティ機能とプロトコルの概要（セクション3.1）、必要な新しいセキュリティ機能のリスト（セクション3.2）、および既存のセキュリティ機能と新しいセキュリティ機能とプロトコルを既存のIETF管理プロトコルとペアにする方法について説明します（セクション3.3） ）。
The new features I2RS extends to these protocols are a priority mechanism to handle multi-headed writes, an opaque secondary identifier to allow traceability of an application utilizing a specific I2RS client to communicate with an I2RS agent, and non-secure transport constrained to be used only for read-only data, which may include publicly available data (e.g., public BGP events, public telemetry information, web service availability) and some legacy data.
I2RSがこれらのプロトコルに拡張する新機能は、マルチヘッド書き込みを処理する優先メカニズム、特定のI2RSクライアントを使用してアプリケーションのトレーサビリティを可能にする不透明なセカンダリ識別子、I2RSエージェントとの通信、および使用するように制限された非セキュアトランスポートです。読み取り専用データのみ。これには、公開されているデータ（例：公開BGPイベント、公開テレメトリ情報、Webサービスの可用性）および一部のレガシーデータが含まれる場合があります。
Section 4 provides the I2RS protocol security requirements of several security features. Protocols designed to be I2RS higher-layer protocols need to fulfill these security requirements.
セクション4では、いくつかのセキュリティ機能のI2RSプロトコルセキュリティ要件について説明します。 I2RS上位層プロトコルとして設計されたプロトコルは、これらのセキュリティ要件を満たす必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document uses the terminology found in [RFC4949] and [RFC7921]. Specifically, this document reuses the following terms from [RFC4949]:
このドキュメントでは、[RFC4949]と[RFC7921]にある用語を使用しています。具体的には、このドキュメントでは、[RFC4949]の次の用語を再利用しています。
o access control o authentication o data confidentiality o data integrity o data privacy o identity o identifier o mutual authentication o role o role-based access control o security audit trail o trust
o アクセス制御o認証oデータの機密性oデータの整合性oデータのプライバシーoアイデンティティo識別子o相互認証oロールoロールベースのアクセス制御oセキュリティ監査証跡o信頼
[RFC7922] describes traceability for the I2RS interface and the I2RS protocol. Traceability is not equivalent to a security audit trail or simple logging of information. A security audit trail may utilize traceability information.
[RFC7922]は、I2RSインターフェイスとI2RSプロトコルのトレーサビリティについて説明しています。トレーサビリティは、セキュリティ監査証跡や情報の単純なログ記録とは異なります。セキュリティ監査証跡は、トレーサビリティ情報を利用する場合があります。
This document discusses the security of the multiple I2RS communication channels that operate over the higher-layer I2RS protocol. The higher-layer I2RS protocol combines a secure transport and I2RS contextual information, and it reuses IETF protocols and data models to create the secure transport and the contextual information driven by the I2RS data model. To describe how the I2RS higher-layer protocol combines other protocols, the following terms are used:
このドキュメントでは、上位層のI2RSプロトコルで動作する複数のI2RS通信チャネルのセキュリティについて説明します。上位層のI2RSプロトコルは、安全なトランスポートとI2RSコンテキスト情報を組み合わせ、IETFプロトコルとデータモデルを再利用して、I2RSデータモデルによって駆動される安全なトランスポートとコンテキスト情報を作成します。 I2RS上位層プロトコルが他のプロトコルをどのように組み合わせるかを説明するために、次の用語が使用されます。
I2RS component protocols
I2RSコンポーネントプロトコル
Protocols that are reused and combined to create the I2RS higher-layer protocol.
I2RS上位層プロトコルを作成するために再利用および結合されるプロトコル。
I2RS secure transport component protocols (required)
I2RSセキュアトランスポートコンポーネントプロトコル（必須）
Secure transport protocols that combine to support the I2RS higher-layer protocol.
I2RS上位層プロトコルをサポートするために組み合わせるセキュアなトランスポートプロトコル。
I2RS management component protocols (required)
I2RS管理コンポーネントプロトコル（必須）
Management protocols that combine to provide the management-information context for the I@RS higher-layer protocol.
I @ RS上位層プロトコルの管理情報コンテキストを提供するために組み合わせる管理プロトコル。
I2RS AAA component protocols (optional)
I2RS AAAコンポーネントプロトコル（オプション）
AAA protocols supporting the I2RS higher-layer protocol.
I2RS上位層プロトコルをサポートするAAAプロトコル。
The reader should be familiar with the pervasive security requirements in [RFC7258].
読者は[RFC7258]の広範なセキュリティ要件に精通している必要があります。
This document uses the following concepts from the I2RS architecture [RFC7921] listed below with their respective section numbers from said RFC:
このドキュメントでは、下記のI2RSアーキテクチャ[RFC7921]の次の概念と、前述のRFCのセクション番号を使用しています。
o I2RS client, agent, and protocol (Section 2)
o I2RSクライアント、エージェント、プロトコル（セクション2）
o I2RS higher-layer protocol (Section 7.2)
o I2RS上位層プロトコル（セクション7.2）
o scope: read, notification, identity, and write (Section 2)
o スコープ：読み取り、通知、識別、および書き込み（セクション2）
o identity and secondary identity (Section 2)
o アイデンティティとセカンダリアイデンティティ（セクション2）
o roles or security rules (Section 2)
o ロールまたはセキュリティルール（セクション2）
o routing system/subsystem (Section 2)
o ルーティングシステム/サブシステム（セクション2）
o I2RS assumed security environment (Section 4)
o I2RSはセキュリティ環境を想定（セクション4）
o I2RS identity and authentication (Section 4.1)
o I2RSのIDと認証（セクション4.1）
o scope of Authorization in I2RS client and agent (Section 4.2)
o I2RSクライアントとエージェントの承認の範囲（セクション4.2）
o client redundancy with a single client identity (Section 4.3),
o 単一のクライアントIDによるクライアントの冗長性（セクション4.3）
o restrictions on I2RS in personal devices (Section 4.4)
o 個人用デバイスのI2RSに関する制限（セクション4.4）
o communication channels and I2RS higher-layer protocol (Section 7.2)
o 通信チャネルとI2RS上位層プロトコル（セクション7.2）
o active communication versus connectivity (Section 7.5)
o アクティブな通信と接続（セクション7.5）
o multi-headed control (Section 7.8)
o マルチヘッド制御（セクション7.8）
o transaction, message, multi-message atomicity (Section 7.9)
o トランザクション、メッセージ、マルチメッセージの原子性（7.9節）
I2RS requires a secure transport protocol and key distribution protocols. The secure transport for I2RS requires one to provide peer authentication. In addition, the features required for I2RS messages are confidentiality, authentication, and replay protection. According to [RFC8095], the secure transport protocols that support peer authentication, confidentiality, data integrity, and replay protection are the following:
I2RSには、安全なトランスポートプロトコルとキー配布プロトコルが必要です。 I2RSのセキュアなトランスポートでは、ピア認証を提供するために1つ必要です。さらに、I2RSメッセージに必要な機能は、機密性、認証、およびリプレイ保護です。 [RFC8095]によると、ピア認証、機密性、データ整合性、および再生保護をサポートするセキュアなトランスポートプロトコルは次のとおりです。
1. TLS [RFC5246] over TCP or Stream Control Transmission Protocol (SCTP)
1. TLS [RFC5246] over TCPまたはStream Control Transmission Protocol（SCTP）
2. DTLS over UDP with replay detection and an anti-DoS stateless cookie mechanism required for the I2RS protocol and the DTLS options of record-size negotiation and conveyance of the Don't Fragment (DF) bit are set for IPv4, or no fragmentation extension headers for IPv6 to be optional in deployments are allowed by the I2RS protocol
2. I2RSプロトコルに必要なリプレイ検出とアンチDoSステートレスCookieメカニズムを備えたDTLS over UDP、およびレコードサイズネゴシエーションのDTLSオプションと、Do n't Fragment（DF）ビットの伝達がIPv4に設定されているか、フラグメンテーション拡張ヘッダーがない展開でIPv6がオプションになるため、I2RSプロトコルで許可されています
3. HTTP over TLS (over TCP or SCTP)
3. HTTP over TLS（over TCPまたはSCTP）
4. HTTP over DTLS (with the requirements and optional features specified above in item 2)
4. HTTP over DTLS（上記の項目2で指定された要件とオプション機能を使用）
As detailed in Section 3.3, the following protocols would need to be extended to provide confidentiality, data integrity, peer authentication, and key distribution and to run over a secure transport (TLS or DTLS):
セクション3.3で詳しく説明するように、機密性、データの整合性、ピア認証、および鍵の配布を提供し、安全なトランスポート（TLSまたはDTLS）を介して実行するには、次のプロトコルを拡張する必要があります。
o IP Flow Information Export (IPFIX) over SCTP, TCP, or UDP
o SCTP、TCP、またはUDPを介したIPフロー情報エクスポート（IPFIX）
o Forwarding and Control Element Separation (ForCES) Transport Mapping Layer (TML) over SCTP
o SCTPを介した転送および制御要素分離（ForCES）トランスポートマッピングレイヤー（TML）
The specific type of key management protocols an I2RS secure transport uses depends on the transport. Key management protocols utilized for the I2RS protocols SHOULD support automatic rotation.
I2RSセキュアトランスポートが使用する特定の種類のキー管理プロトコルは、トランスポートによって異なります。 I2RSプロトコルに使用されるキー管理プロトコルは、自動ローテーションをサポートする必要があります（SHOULD）。
An I2RS implementer may use AAA protocols over secure transport to distribute the identities for the I2RS client, I2RS agent, and role-authorization information. Two AAA protocols are as follows: Diameter [RFC6733] and Radius [RFC2865]. To provide I2RS peer identities with the best security, the AAA protocols MUST be run over a secure transport (Diameter over secure transport (TLS over TCP) [RFC6733]), Radius over a secure transport (TLS) [RFC6614]).
I2RSの実装者は、セキュアなトランスポートを介してAAAプロトコルを使用して、I2RSクライアント、I2RSエージェント、およびロール承認情報のIDを配布できます。 2つのAAAプロトコルは、Diameter [RFC6733]とRadius [RFC2865]です。 I2RSピアIDに最高のセキュリティを提供するには、AAAプロトコルを安全なトランスポート（Diameter over secure transport（TLS over TCP）[RFC6733]）、Radius over a secure transport（TLS）[RFC6614]）で実行する必要があります。
The new features are priority, an opaque secondary identifier, and a non-secure protocol for read-only data constrained to specific standard usages. The I2RS protocol allows multi-headed control by several I2RS clients. This multi-headed control is based on the assumption that the operator deploying the I2RS clients, I2RS agents, and the I2RS protocol will coordinate the read, write, and notification scope so the I2RS clients will not contend for the same write scope. However, just in case there is an unforeseen overlap of I2RS clients attempting to write a particular piece of data, the I2RS architecture [RFC7921] provides the concept of each I2RS client having a priority. The I2RS client with the highest priority will have its write succeed. This document specifies requirements for this new concept of priority (see Section 4.3).
新機能は、優先度、不透明なセカンダリ識別子、特定の標準的な使用に制限された読み取り専用データ用の非セキュアプロトコルです。 I2RSプロトコルは、複数のI2RSクライアントによるマルチヘッド制御を可能にします。このマルチヘッド制御は、I2RSクライアント、I2RSエージェント、およびI2RSプロトコルを展開するオペレーターが読み取り、書き込み、および通知のスコープを調整するため、I2RSクライアントが同じ書き込みスコープを争わないことを前提としています。ただし、特定のデータを書き込もうとするI2RSクライアントの予期しないオーバーラップがある場合に備えて、I2RSアーキテクチャ[RFC7921]は、優先度を持つ各I2RSクライアントの概念を提供します。最も優先度の高いI2RSクライアントは、書き込みが成功します。このドキュメントでは、この新しい優先度の概念の要件を指定しています（セクション4.3を参照）。
The opaque secondary identifier identifies an application that uses communication from the I2RS client to I2RS agent to manage the routing system. The secondary identifier is opaque to the I2RS protocol. In order to protect personal privacy, the secondary identifier should not contain identifiable personal information.
不透明なセカンダリ識別子は、I2RSクライアントからI2RSエージェントへの通信を使用してルーティングシステムを管理するアプリケーションを識別します。セカンダリ識別子は、I2RSプロトコルに対して不透明です。個人のプライバシーを保護するために、二次識別子には識別可能な個人情報を含めないでください。
The last new feature related to I2RS security is the ability to allow nonconfidential data to be transferred over a non-secure transport. It is expected that most I2RS data models will describe information that will be transferred with confidentiality. Therefore, any model that transfers data over a non-secure transport is marked. The use of a non-secure transport is optional, and an implementer SHOULD create knobs that allow data marked as nonconfidential to be sent over a secure transport.
I2RSセキュリティに関連する最後の新機能は、非機密データを非セキュアなトランスポートを介して転送できるようにする機能です。ほとんどのI2RSデータモデルは、機密性をもって転送される情報を記述することが期待されています。したがって、非セキュアなトランスポートを介してデータを転送するすべてのモデルがマークされます。非セキュアなトランスポートの使用はオプションであり、実装者は非機密としてマークされたデータをセキュアなトランスポート経由で送信できるようにするノブを作成する必要があります（SHOULD）。
Nonconfidential data can only be data with read-scope or notification-scope transmission of events. Nonconfidential data cannot have write-scope or notification-scope configuration. Examples of nonconfidential data would be the telemetry information that is publicly known (e.g., BGP route-views data or website status data) or some legacy data (e.g., interface) that cannot be transported using secure transport. The IETF I2RS data models MUST indicate (in the model) the specific data that is nonconfidential.
非機密データは、イベントの読み取りスコープまたは通知スコープの送信のみが可能なデータです。非機密データには、書き込みスコープまたは通知スコープの構成を含めることはできません。非機密データの例としては、一般に知られているテレメトリ情報（BGPルートビューデータやWebサイトステータスデータなど）や、安全なトランスポートを使用してトランスポートできないレガシーデータ（インターフェースなど）があります。 IETF I2RSデータモデルは、（モデル内で）機密でない特定のデータを示す必要があります。
Most I2RS data models will expect that the information described in the model will be transferred with confidentiality.
ほとんどのI2RSデータモデルは、モデルに記述されている情報が機密性を持って転送されることを期待しています。
Figure 1 provides a partial list of the candidate management protocols. It also lists the secure transports each protocol supports. The column on the right of the table indicates whether or not the transport protocol will need I2RS security extensions.
図1は、候補となる管理プロトコルのリストの一部です。また、各プロトコルがサポートするセキュアなトランスポートも示しています。表の右側の列は、トランスポートプロトコルにI2RSセキュリティ拡張機能が必要かどうかを示しています。
Management I2RS Security
Protocol Transport Protocol Extensions
========= ===================== =================
NETCONF TLS over TCP (*1) None required (*2)
RESTCONF HTTP over TLS with None required (*2) X.509v3 certificates, certificate validation, mutual authentication: 1) authenticated server identity, 2) authenticated client identity (*1)
RESTCONF HTTP over TLS with None required（* 2）X.509v3証明書、証明書の検証、相互認証：1）認証済みサーバーID、2）認証済みクライアントID（* 1）
ForCES TML over SCTP Needs an extension to (*1) TML to run TML over TLS over SCTP, or DTLS with options for replay protection and anti-DoS stateless cookie mechanism. (DTLS record size negotiation and conveyance of DF bits are optional). The IPsec mechanism is not sufficient for I2RS traveling over multiple hops (router + link) (*2)
ForCES TML over SCTP（* 1）TML over SCTP over TLSまたはDTLSを実行するには、TPM over SCTP、または再生保護とアンチDoSステートレスCookieメカニズムのオプションを備えたDTLSを拡張する必要があります。 （DTLSレコードサイズのネゴシエーションとDFビットの伝達はオプションです）。 IPsecメカニズムは、I2RSが複数のホップ（ルーター+リンク）を移動するのに十分ではありません（* 2）
IPFIX SCTP, TCP, UDP Needs an extension TLS or DTLS for to support TLS or DTLS with secure client (*1) options for replay protection and anti-DoS stateless cookie mechanism. (DTLS record size negotiation and conveyance of DF bits are optional)
IPFIX SCTP、TCP、UDPリプレイ保護とアンチDoSステートレスCookieメカニズムのセキュアクライアント（* 1）オプションでTLSまたはDTLSをサポートするには、拡張TLSまたはDTLSが必要です。 （DTLSレコードサイズのネゴシエーションとDFビットの伝達はオプションです）
*1 - Key management protocols MUST support appropriate key rotation.
* 1-キー管理プロトコルは適切なキーローテーションをサポートする必要があります。
*2 - Identity and role authorization distributed by Diameter or Radius MUST use Diameter over TLS or Radius over TLS.
* 2-DiameterまたはRadiusによって配布されるIDおよびロールの承認では、Diameter over TLSまたはRadius over TLSを使用する必要があります。
Figure 1: Candidate Management Protocols and Their Secure Transports
図1：候補管理プロトコルとその安全なトランスポート
This section discusses security requirements based on the following security functions:
このセクションでは、次のセキュリティ機能に基づくセキュリティ要件について説明します。
o peer identity authentication (Section 4.1)
o ピアID認証（セクション4.1）
o Peer Identity validation before role-based message actions (Section 4.2)
o ロールベースのメッセージアクションの前のピアID検証（セクション4.2）
o peer identity and client redundancy (Section 4.3)
o ピアIDとクライアントの冗長性（セクション4.3）
o multi-channel transport requirements: Secure transport and non-secure Transport (Section 4.4)
o マルチチャネルトランスポートの要件：セキュアなトランスポートと非セキュアなトランスポート（セクション4.4）
o management protocol security requirements (Section 4.5)
o 管理プロトコルのセキュリティ要件（セクション4.5）
o role-based security (Section 4.6)
o ロールベースのセキュリティ（セクション4.6）
o security environment (Section 4.7)
o セキュリティ環境（セクション4.7）
The I2RS protocol depends upon a secure transport layer for peer authentication, data integrity, confidentiality, and replay protection. The optional non-secure transport can only be used for a restricted set of data available publicly (events or information) or a select set of legacy data. Data passed over the non-secure transport channel MUST NOT contain any data that identifies a person.
I2RSプロトコルは、ピア認証、データの整合性、機密性、およびリプレイ保護の安全なトランスポート層に依存しています。オプションの非セキュアトランスポートは、公開されている限られたデータセット（イベントまたは情報）または選択したレガシーデータセットに対してのみ使用できます。非セキュアなトランスポートチャネルを介して渡されるデータには、個人を識別するデータを含めてはなりません。
Requirements:
要件：
SEC-REQ-01: All I2RS clients and agents MUST have an identity and at least one unique identifier for each party in the I2RS protocol context.
SEC-REQ-01：すべてのI2RSクライアントとエージェントは、I2RSプロトコルコンテキストの各パーティに対してIDと少なくとも1つの一意の識別子を持っている必要があります。
SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for mutual identification of the I2RS client and agent.
SEC-REQ-02：I2RSプロトコルは、I2RSクライアントとエージェントの相互識別のためにこれらの識別子を利用する必要があります。
SEC-REQ-03: Identifier distribution and the loading of these identifiers into the I2RS agent and client SHOULD occur outside the I2RS protocol prior to the I2RS protocol establishing a connection between I2RS client and agent. AAA protocols MAY be used to distribute these identifiers, but other mechanism can be used.
SEC-REQ-03：I2RSプロトコルがI2RSクライアントとエージェント間の接続を確立する前に、識別子の配布とこれらの識別子のI2RSエージェントとクライアントへの読み込みは、I2RSプロトコルの外部で発生する必要があります。これらの識別子を配布するためにAAAプロトコルが使用される場合がありますが、他のメカニズムを使用することもできます。
Explanation:
説明：
These requirements are for I2RS peer (I2RS agent and client) authentication. A secure transport (e.g., TLS) will authenticate based on these identities, but these identities are for the I2RS management layer. A AAA protocol distributing I2RS identity information SHOULD transport its information over a secure transport.
これらの要件は、I2RSピア（I2RSエージェントおよびクライアント）認証用です。セキュアなトランスポート（TLSなど）はこれらのIDに基づいて認証しますが、これらのIDはI2RS管理レイヤー用です。 I2RS ID情報を配布するAAAプロトコルは、安全なトランスポートを介して情報をトランスポートする必要があります（SHOULD）。
Requirements:
要件：
SEC-REQ-04: An I2RS agent receiving a request from an I2RS client MUST confirm that the I2RS client has a valid identity.
SEC-REQ-04：I2RSクライアントから要求を受信するI2RSエージェントは、I2RSクライアントが有効なIDを持っていることを確認する必要があります。
SEC-REQ-05: An I2RS client receiving an I2RS message over a secure transport MUST confirm that the I2RS agent has a valid identifier.
SEC-REQ-05：セキュアなトランスポートを介してI2RSメッセージを受信するI2RSクライアントは、I2RSエージェントが有効な識別子を持っていることを確認する必要があります。
SEC-REQ-06: An I2RS agent receiving an I2RS message over a non-secure transport MUST confirm that the content is suitable for transfer over such a transport.
SEC-REQ-06：非セキュアなトランスポートを介してI2RSメッセージを受信するI2RSエージェントは、コンテンツがそのようなトランスポートを介した転送に適していることを確認する必要があります。
Explanation:
説明：
Each I2RS client has a scope based on its identity and the security roles (read, write, or events) associated with that identity, and that scope must be considered in processing an I2RS message sent on a communication channel. An I2RS communication channel may utilize multiple transport sessions or establish a transport session and then close the transport session. Therefore, it is important that the I2RS peers operate utilizing valid peer identities when a message is processed rather than checking if a transport session exists.
各I2RSクライアントには、IDとそのIDに関連付けられたセキュリティロール（読み取り、書き込み、またはイベント）に基づくスコープがあり、通信チャネルで送信されるI2RSメッセージの処理では、そのスコープを考慮する必要があります。 I2RS通信チャネルは、複数のトランスポートセッションを利用するか、トランスポートセッションを確立してからトランスポートセッションを閉じます。したがって、トランスポートセッションが存在するかどうかを確認するのではなく、メッセージが処理されるときに、I2RSピアが有効なピアIDを利用して動作することが重要です。
During the time period when a secure transport session is active, the I2RS agent SHOULD assume that the I2RS client's identity remains valid. Similarly, while a secure connection exists that included validating the I2RS agent's identity and a message is received via that connection, the I2RS client SHOULD assume that the I2RS agent's identity remains valid.
セキュアなトランスポートセッションがアクティブな期間中、I2RSエージェントは、I2RSクライアントのIDが引き続き有効であると想定する必要があります（SHOULD）。同様に、I2RSエージェントのIDの検証を含む安全な接続が存在し、その接続を介してメッセージが受信された場合、I2RSクライアントは、I2RSエージェントのIDが有効なままであると想定する必要があります。
The definition of what constitutes a valid identity or a valid identifier MUST be defined by the I2RS protocol.
有効なアイデンティティまたは有効な識別子を構成するものの定義は、I2RSプロトコルで定義する必要があります。
Requirements:
要件：
SEC-REQ-07: Each I2RS identifier MUST be associated with just one priority.
SEC-REQ-07：各I2RS識別子は、1つの優先度のみに関連付けられている必要があります。
SEC-REQ-08: Each identifier is associated with one secondary identifier during a particular I2RS transaction (e.g., read/write sequence), but the secondary identifier may vary during the time a connection between the I2RS client and I2RS agent is active.
SEC-REQ-08：各識別子は、特定のI2RSトランザクション（読み取り/書き込みシーケンスなど）中に1つのセカンダリ識別子に関連付けられますが、I2RSクライアントとI2RSエージェント間の接続がアクティブなときにセカンダリ識別子が変わる場合があります。
Explanation:
説明：
The I2RS architecture also allows multiple I2RS clients with unique identities to connect to an I2RS agent (see Section 7.8 of [RFC7921]). The I2RS deployment using multiple clients SHOULD coordinate this multi-headed control of I2RS agents by I2RS clients so no conflict occurs in the write scope. However, in the case of conflict on a write-scope variable, the error resolution mechanisms defined by the I2RS architecture multi-headed control (Section 7.8 of [RFC7921]) allow the I2RS agent to deterministically choose one I2RS client. The I2RS client with highest priority is given permission to write the variable, and the second client receives an error message.
I2RSアーキテクチャでは、一意のIDを持つ複数のI2RSクライアントがI2RSエージェントに接続することもできます（[RFC7921]のセクション7.8を参照）。複数のクライアントを使用するI2RS展開は、I2RSクライアントによるI2RSエージェントのこのマルチヘッド制御を調整して、書き込みスコープで競合が発生しないようにする必要があります。ただし、書き込みスコープ変数で競合が発生した場合、I2RSアーキテクチャのマルチヘッドコントロール（[RFC7921]のセクション7.8）で定義されたエラー解決メカニズムにより、I2RSエージェントは1つのI2RSクライアントを決定的に選択できます。優先度が最も高いI2RSクライアントには変数を書き込む権限が与えられ、2番目のクライアントはエラーメッセージを受け取ります。
A single I2RS client may be associated with multiple applications with different tasks (e.g., weekly configurations or emergency configurations). The secondary identity is an opaque value that the I2RS client passes to the I2RS agent so that this opaque value can be placed in the tracing file or event stream to identify the application using the communication from I2RS client to agent. The I2RS client is trusted to simply assert the secondary identifier.
単一のI2RSクライアントは、異なるタスク（例：毎週の構成または緊急の構成）を持つ複数のアプリケーションに関連付けられている場合があります。セカンダリIDは不透明な値であり、I2RSクライアントがI2RSエージェントに渡すため、この不透明な値をトレースファイルまたはイベントストリームに入れて、I2RSクライアントからエージェントへの通信を使用するアプリケーションを識別できます。 I2RSクライアントは、セカンダリ識別子を単にアサートすることが信頼されています。
One example of the use of the secondary identity is the situation where an operator of a network has two applications that use an I2RS client. The first application is a weekly configuration application that uses the I2RS protocol to change configurations. The second application allows operators to makes emergency changes to routers in the network. Both of these applications use the same I2RS client to write to an I2RS agent. In order for traceability to determine which application (weekly configuration or emergency) wrote some configuration changes to a router, the I2RS client sends a different opaque value for each of the applications. The weekly configuration secondary opaque value could be "xzzy-splot" and the emergency secondary opaque value could be "splish-splash".
セカンダリIDの使用の一例は、ネットワークのオペレーターがI2RSクライアントを使用する2つのアプリケーションを持っている状況です。最初のアプリケーションは、I2RSプロトコルを使用して構成を変更する毎週の構成アプリケーションです。 2番目のアプリケーションでは、オペレーターはネットワーク内のルーターに緊急の変更を加えることができます。これらのアプリケーションはどちらも、同じI2RSクライアントを使用してI2RSエージェントに書き込みます。トレーサビリティがどのアプリケーション（毎週の構成または緊急）がルーターにいくつかの構成変更を書き込んだかを判断するために、I2RSクライアントはアプリケーションごとに異なる不透明な値を送信します。毎週の構成の二次不透明値は「xzzy-splot」、緊急の二次不透明値は「splish-splash」とすることができます。
A second example is if the I2RS client is used for the monitoring of critical infrastructure. The operator of a network using the I2RS client may desire I2RS client redundancy where the monitoring application with the I2RS client is deployed on two different boxes with the same I2RS client identity (see Section 4.3 of [RFC7921]). These two monitoring applications pass to the I2RS client whether the application is the primary or back-up application, and the I2RS client passes this information in the I2RS secondary identifier, as the figure below shows. The primary application's secondary identifier is "primary-monitoring", and the back-up application secondary identifier is "backup-monitoring". The I2RS tracing information will include the secondary identifier information along with the transport information in the tracing file in the agent.
2番目の例は、重要なインフラストラクチャの監視にI2RSクライアントが使用されている場合です。 I2RSクライアントを使用するネットワークのオペレーターは、I2RSクライアントを使用した監視アプリケーションが、同じI2RSクライアントIDを持つ2つの異なるボックスにデプロイされるI2RSクライアントの冗長性を望む場合があります（[RFC7921]のセクション4.3を参照）。次の図に示すように、これらの2つの監視アプリケーションは、アプリケーションがプライマリアプリケーションかバックアップアプリケーションかに関係なくI2RSクライアントに渡され、I2RSクライアントはI2RSセカンダリ識別子でこの情報を渡します。プライマリアプリケーションのセカンダリ識別子は「プライマリモニタリング」であり、バックアップアプリケーションのセカンダリ識別子は「バックアップモニタリング」です。 I2RSトレース情報には、エージェントのトレースファイル内のトランスポート情報と共にセカンダリ識別子情報が含まれます。
Application A--I2RS client--Secure transport(#1)
[I2RS identity 1, secondary identifier: "primary-monitoring"]-->
Application B--I2RS client--Secure transport(#2)
[I2RS identity 1, secondary identifier: "backup-monitoring"]-->
Figure 2: Primary and Back-Up Application for Monitoring Identification Sent to Agent
図2：エージェントに送信されたIDを監視するためのプライマリおよびバックアップアプリケーション
Requirements:
要件：
SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport. The default transport is a secure transport, and this secure transport is mandatory to implement in all I2RS agents and in any I2RS client that a) performs a write scope transaction that is sent to the I2RS agent or b) configures an Event Scope transaction. This secure transport is mandatory to use on any I2RS client's Write transaction or the configuration of an Event Scope transaction.
SEC-REQ-09：I2RSプロトコルはセキュアなトランスポートを介してデータを転送できなければならず（MUST）、オプションで非セキュアなトランスポートを介してデータを転送できてもよい（MAY）。デフォルトのトランスポートはセキュアなトランスポートであり、このセキュアなトランスポートは、すべてのI2RSエージェントとすべてのI2RSクライアントで、a）I2RSエージェントに送信される書き込みスコープトランザクションを実行するか、b）イベントスコープトランザクションを構成するために必須です。このセキュアなトランスポートは、I2RSクライアントの書き込みトランザクションまたはイベントスコープトランザクションの構成で使用するために必須です。
SEC-REQ-10: The secure transport MUST provide data confidentiality, data integrity, and practical replay prevention.
SEC-REQ-10：安全なトランスポートは、データの機密性、データの整合性、および実用的なリプレイ防止を提供する必要があります。
SEC-REQ-11: The I2RS client and I2RS agent SHOULD implement mechanisms that mitigate DoS attacks. This means the secure transport must support DoS prevention. For the non-secure transport, the I2RS higher-layer protocol MUST contain a transport management layer that considers the detection of DoS attacks and provides a warning over a secure transport channel.
SEC-REQ-11：I2RSクライアントとI2RSエージェントは、DoS攻撃を軽減するメカニズムを実装する必要があります（SHOULD）。つまり、セキュアなトランスポートはDoS防止をサポートする必要があります。非セキュアなトランスポートの場合、I2RS上位層プロトコルには、DoS攻撃の検出を考慮し、セキュアなトランスポートチャネルを介して警告を提供するトランスポート管理レイヤーを含める必要があります。
SEC-REQ-12: A secure transport MUST be associated with a key management solution that can guarantee that only the entities having sufficient privileges can get the keys to encrypt/decrypt the sensitive data.
SEC-REQ-12：安全なトランスポートは、十分な特権を持つエンティティーのみが機密データを暗号化/復号化するためのキーを取得できることを保証できるキー管理ソリューションに関連付ける必要があります。
SEC-REQ-13: A machine-readable mechanism to indicate that a data model contains nonconfidential data MUST be provided. A non-secure transport MAY be used to publish only read-scope or notification-scope data if the associated data model indicates that the data in question is nonconfidential.
SEC-REQ-13：データモデルに非機密データが含まれていることを示す機械可読メカニズムを提供する必要があります。関連するデータモデルが問題のデータが機密でないことを示している場合、非セキュアなトランスポートを使用して、読み取りスコープまたは通知スコープのデータのみを公開できます。
SEC-REQ-14: The I2RS protocol MUST be able to support multiple secure transport sessions providing protocol and data communication between an I2RS agent and client. However, a single connection between I2RS agent and client MAY elect to use a single secure transport session or a single non-secure transport session conforming to the requirements above.
SEC-REQ-14：I2RSプロトコルは、I2RSエージェントとクライアント間のプロトコルとデータ通信を提供する複数の安全なトランスポートセッションをサポートできなければなりません（MUST）。ただし、I2RSエージェントとクライアント間の単一の接続は、上記の要件に準拠する単一のセキュアなトランスポートセッションまたは単一の非セキュアなトランスポートセッションを使用することを選択できます。
SEC-REQ-15: Deployment configuration knobs SHOULD be created to allow operators to send "nonconfidential" read scope (data or event streams) over a secure transport.
SEC-REQ-15：展開構成ノブを作成して、オペレーターが「非機密」の読み取りスコープ（データまたはイベントストリーム）を安全なトランスポート経由で送信できるようにする必要があります。
SEC-REQ-16: The I2RS protocol makes use of both secure and non-secure transports, but this use MUST NOT be done in any way that weakens the secure transport protocol used in the I2RS protocol or other contexts that do not have this requirement for mixing secure and non-secure modes of operation.
SEC-REQ-16：I2RSプロトコルは安全なトランスポートと非安全なトランスポートの両方を使用しますが、この使用は、I2RSプロトコルで使用される安全なトランスポートプロトコルまたはこの要件を持たない他のコンテキストを弱める方法で行わないでください。安全な動作モードと非安全な動作モードを混在させるため。
Explanation:
説明：
The I2RS architecture defines three scopes: read, write, and notification. Non-secure data can only be used for read and notification scopes of "nonconfidential data". The configuration of ephemeral data in the I2RS agent uses write scope either for data or for configuration of event notification streams. The requirement to use secure transport for configuration prevents accidental or malevolent entities from altering the I2RS routing system through the I2RS agent.
I2RSアーキテクチャは、読み取り、書き込み、通知の3つのスコープを定義します。非セキュアデータは、「非機密データ」の読み取りスコープと通知スコープにのみ使用できます。 I2RSエージェントでのエフェメラルデータの構成では、データまたはイベント通知ストリームの構成に書き込みスコープを使用します。構成に安全なトランスポートを使用する必要があるため、偶発的または悪意のあるエンティティがI2RSエージェントを介してI2RSルーティングシステムを変更することを防ぎます。
It is anticipated that the passing of most I2RS ephemeral state operational statuses SHOULD be done over a secure transport.
ほとんどのI2RS一時的運用状態の通過は、安全なトランスポートを介して行われる必要があります。
In most circumstances, the secure transport protocol will be associated with a key management system. Most deployments of the I2RS protocol will allow for automatic key management systems. Since the data models for the I2RS protocol will control key routing functions, it is important that deployments of I2RS use automatic key management systems.
ほとんどの場合、セキュアなトランスポートプロトコルはキー管理システムに関連付けられます。 I2RSプロトコルのほとんどの展開では、自動キー管理システムを使用できます。 I2RSプロトコルのデータモデルはキールーティング機能を制御するため、I2RSの展開では自動キー管理システムを使用することが重要です。
Per BCP 107 [RFC4107], while key management systems SHOULD be automatic, the systems MAY be manual in the following scenarios:
BCP 107 [RFC4107]に従い、キー管理システムは自動である必要がありますが、以下のシナリオでは、システムは手動である必要があります。
a) The environment has limited bandwidth or high round-trip times.
a) 環境の帯域幅が制限されているか、ラウンドトリップ時間が長い。
b) The information being protected has low value.
b) 保護されている情報の価値は低いです。
c) The total volume of traffic over the entire lifetime of the long-term session key will be very low.
c) 長期セッションキーのライフタイム全体にわたるトラフィックの総量は非常に少なくなります。
d) The scale of the deployment is limited.
d) 展開の規模は限られています。
Operators deploying the I2RS protocol selecting manual key management SHOULD consider both short- and medium-term plans. Deploying automatic systems initially may save effort in the long term.
手動キー管理を選択するI2RSプロトコルを展開するオペレーターは、短期および中期計画の両方を検討する必要があります。自動システムを最初に導入すると、長期的には労力を節約できます。
Requirements:
要件：
SEC-REQ-17: In a critical infrastructure, certain data within routing elements is sensitive and read/write operations on such data SHOULD be controlled in order to protect its confidentiality. To achieve this, higher-layer protocols MUST utilize a secure transport, and they SHOULD provide access-control functions to protect confidentiality of the data.
SEC-REQ-17：重要なインフラストラクチャでは、ルーティング要素内の特定のデータは機密であり、そのようなデータの読み取り/書き込み操作は、その機密性を保護するために制御する必要があります。これを達成するために、上位層プロトコルは安全なトランスポートを利用する必要があり、データの機密性を保護するアクセス制御機能を提供する必要があります（SHOULD）。
SEC-REQ-18: An integrity protection mechanism for I2RS MUST be provided that will be able to ensure the following:
SEC-REQ-18：以下を保証できるI2RSの完全性保護メカニズムを提供する必要があります。
1) the data being protected is not modified without detection during its transportation,
1）保護されているデータは、転送中に検出されることなく変更されません。
2) the data is actually from where it is expected to come from, and
2）データは実際には、それがどこから来るかが予想されている場所からのものであり、
3) the data is not repeated from some earlier interaction the higher-layer protocol (best effort).
3）上位層プロトコル（ベストエフォート）の以前のやり取りからデータが繰り返されない。
The I2RS higher-layer protocol operating over a secure transport provides this integrity. The I2RS higher-layer protocol operating over a non-secure transport SHOULD provide some way for the client receiving nonconfidential read-scoped or event-scoped data over the non-secure connection to detect when the data integrity is questionable; and in the event of a questionable data integrity, the I2RS client should disconnect the non-secure transport connection.
安全なトランスポート上で動作するI2RS上位層プロトコルは、この整合性を提供します。非セキュアなトランスポートで動作するI2RS上位層プロトコルは、非セキュアな接続を介して非機密の読み取りスコープまたはイベントスコープのデータを受信するクライアントに、データの整合性が疑わしい場合に検出する何らかの方法を提供する必要があります。また、データの整合性に問題がある場合、I2RSクライアントは非セキュアなトランスポート接続を切断する必要があります。
SEC-REQ-19: The I2RS higher-layer protocol MUST provide a mechanism for message traceability (requirements in [RFC7922]) that supports the tracking higher-layer functions run across secure connection or a non-secure transport.
SEC-REQ-19：I2RS上位層プロトコルは、セキュア接続または非セキュアトランスポートで実行される上位層機能の追跡をサポートするメッセージ追跡可能性（[RFC7922]の要件）のメカニズムを提供する必要があります。
Explanation:
説明：
Most carriers do not want a router's configuration and data-flow statistics to be known by hackers or their competitors. While carriers may share peering information, most carriers do not share configuration and traffic statistics. To achieve this, the I2RS higher-layer protocol (e.g., NETCONF) requires access control (NETCONF Access Control Model [RFC6536]) for sensitive data needs to be provided; and the confidentiality protection on such data during transportation needs to be enforced.
ほとんどのキャリアは、ルーターの構成とデータフローの統計情報がハッカーや競合他社に知られることを望んでいません。キャリアはピアリング情報を共有する場合がありますが、ほとんどのキャリアは構成およびトラフィック統計を共有しません。これを実現するには、I2RS上位層プロトコル（NETCONFなど）で、機密データを提供するためのアクセス制御（NETCONFアクセス制御モデル[RFC6536]）が必要です。また、輸送中のそのようなデータの機密保護を実施する必要があります。
Integrity of data is important even if the I2RS protocol is sending nonconfidential data over a non-secure connection. The ability to trace I2RS protocol messages that enact I2RS transactions provides a minimal aid to helping operators check how messages enact transactions on a secure or non-secure transport. Contextual checks on specific nonconfidential data sent over a non-secure connection may indicate the data has been modified.
I2RSプロトコルが非セキュア接続を介して非機密データを送信している場合でも、データの整合性は重要です。 I2RSトランザクションを制定するI2RSプロトコルメッセージをトレースする機能は、メッセージがセキュアなトランスポートまたは非セキュアなトランスポートでトランザクションを制定する方法をオペレーターが確認するのに役立つ最小限の支援を提供します。非セキュア接続を介して送信された特定の非機密データのコンテキストチェックは、データが変更されたことを示している場合があります。
In order to make access control more manageable, the I2RS architecture [RFC7921] specifies a "role" to categorize users into a group (rather than handling them individually) for access-control purposes (role-based access control). Therefore, an I2RS role specifies the access control for a group as being read, write, or notification.
アクセス制御をより管理しやすくするために、I2RSアーキテクチャ[RFC7921]は、アクセス制御の目的（ロールベースのアクセス制御）のために、ユーザーを（個別に処理するのではなく）グループに分類する「役割」を指定します。したがって、I2RSロールは、グループのアクセス制御を読み取り、書き込み、または通知として指定します。
SEC-REQ-20: The rules around what I2RS security role is permitted to access and manipulate what information over a secure transport (which protects the data in transit) SHOULD ensure that data of any level of sensitivity is reasonably protected from being observed by those without permission to view it, so that privacy requirements are met.
SEC-REQ-20：どのI2RSセキュリティロールが安全なトランスポート（転送中のデータを保護する）を介してどの情報にアクセスおよび操作することを許可するかに関するルールは、あらゆるレベルの機密性のデータがそれらによって観察されることから合理的に保護されることを保証する必要があります。それを表示する許可なしで、プライバシー要件が満たされるようにします。
SEC-REQ-21: Role security MUST work when multiple transport connections are being used between the I2RS client and agent as the I2RS architecture [RFC7921] describes.
SEC-REQ-21：I2RSアーキテクチャ[RFC7921]で説明されているように、I2RSクライアントとエージェント間で複数のトランスポート接続が使用されている場合、ロールセキュリティが機能する必要があります。
Sec-REQ-22: If an I2RS agent or client is tightly correlated with a person, then the I2RS protocol and data models SHOULD provide additional security that protects the person's privacy.
Sec-REQ-22：I2RSエージェントまたはクライアントが個人と密接に相関している場合、I2RSプロトコルおよびデータモデルは、個人のプライバシーを保護する追加のセキュリティを提供する必要があります（SHOULD）。
Explanation:
説明：
An I2RS higher-layer protocol uses a management protocol (e.g., NETCONF, RESTCONF) to pass messages in order to enact I2RS transactions. Role security must secure data (sensitive and normal data) in a router even when it is operating over multiple connections at the same time. NETCONF can run over TLS (over TCP or SCTP) or SSH. RESTCONF runs over HTTP over a secure transport (TLS). SCTP [RFC4960] provides security for multiple streams plus end-to-end transport of data. Some I2RS functions may wish to operate over DTLS [RFC6347], which runs over UDP ([RFC768]) and SCTP ([RFC5764]).
I2RS上位層プロトコルは、管理プロトコル（NETCONF、RESTCONFなど）を使用してメッセージを渡し、I2RSトランザクションを実行します。役割のセキュリティでは、ルーターが同時に複数の接続で動作している場合でも、ルーター内のデータ（機密データと通常のデータ）を保護する必要があります。 NETCONFは、TLS（TCPまたはSCTP）またはSSHで実行できます。 RESTCONFは、セキュアなトランスポート（TLS）上のHTTPで実行されます。 SCTP [RFC4960]は、複数のストリームとエンドツーエンドのデータ転送にセキュリティを提供します。一部のI2RS機能は、UDP（[RFC768]）およびSCTP（[RFC5764]）で実行されるDTLS [RFC6347]で動作することを望む場合があります。
Please note the security of the connection between application and I2RS client is outside of the I2RS protocol or I2RS interface.
アプリケーションとI2RSクライアント間の接続のセキュリティは、I2RSプロトコルまたはI2RSインターフェイスの外部にあることに注意してください。
While I2RS clients are expected to be related to network devices and not individual people, if an I2RS client ran on a person's phone, then privacy protection to anonymize any data relating to a person's identity or location would be needed.
I2RSクライアントは個人ではなくネットワークデバイスに関連していると予想されますが、I2RSクライアントが個人の電話で実行された場合、個人のIDまたは場所に関連するデータを匿名化するプライバシー保護が必要になります。
A variety of forms of management may set policy on roles: "operator-applied knobs", roles that restrict personal access, data models with specific "privacy roles", and access filters.
さまざまな形式の管理者がロールにポリシーを設定できます。「オペレーターが適用するノブ」、個人アクセスを制限するロール、特定の「プライバシーロール」を持つデータモデル、アクセスフィルターなどです。
The security for the implementation of a protocol also considers the protocol environment. Implementers should review the summary of the I2RS security environment in [RFC7921].
プロトコルの実装のセキュリティでは、プロトコル環境も考慮されます。実装者は、[RFC7921]のI2RSセキュリティ環境の概要を確認する必要があります。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
This is a document about security requirements for the I2RS protocol and data models. Security considerations for the I2RS protocol include both the protocol and the security environment.
これは、I2RSプロトコルとデータモデルのセキュリティ要件に関するドキュメントです。 I2RSプロトコルのセキュリティに関する考慮事項には、プロトコルとセキュリティ環境の両方が含まれます。
[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>。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC4107] Bellovin、S。およびR. Housley、「暗号化キー管理のガイドライン」、BCP 107、RFC 4107、DOI 10.17487 / RFC4107、2005年6月、<https://www.rfc-editor.org/info/rfc4107 >。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、DOI 10.17487 / RFC4949、2007年8月、<https://www.rfc-editor.org/info/rfc4949>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<https://www.rfc-editor.org/info/rfc7258 >。
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016, <https://www.rfc-editor.org/info/rfc7921>.
[RFC7921] Atlas、A.、Halpern、J.、Hares、S.、Ward、D。、およびT. Nadeau、「ルーティングシステムへのインターフェイスのアーキテクチャ」、RFC 7921、DOI 10.17487 / RFC7921、2016年6月、<https://www.rfc-editor.org/info/rfc7921>。
[RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to the Routing System (I2RS) Traceability: Framework and Information Model", RFC 7922, DOI 10.17487/RFC7922, June 2016, <https://www.rfc-editor.org/info/rfc7922>.
[RFC7922] Clarke、J.、Salgueiro、G。、およびC. Pignataro、「Interface to the Routing System（I2RS）Traceability：Framework and Information Model」、RFC 7922、DOI 10.17487 / RFC7922、June 2016、<https：/ /www.rfc-editor.org/info/rfc7922>。
[RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements for Subscription to YANG Datastores", RFC 7923, DOI 10.17487/RFC7923, June 2016, <https://www.rfc-editor.org/info/rfc7923>.
[RFC7923] Voit、E.、Clemm、A。、およびA. Gonzalez Prieto、「YANG Datastoresへのサブスクリプションの要件」、RFC 7923、DOI 10.17487 / RFC7923、2016年6月、<https：//www.rfc-editor。 org / info / rfc7923>。
[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>。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC768] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、DOI 10.17487 / RFC2865、2000年6月、<https：/ /www.rfc-editor.org/info/rfc2865>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https://www.rfc-editor.org/info/rfc4960>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.
[RFC5764] McGrew、D。およびE. Rescorla、「Secure Real-time Transport Protocol（SRTP）のキーを確立するためのデータグラムトランスポート層セキュリティ（DTLS）拡張」、RFC 5764、DOI 10.17487 / RFC5764、2010年5月、<https ：//www.rfc-editor.org/info/rfc5764>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、A。Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, <https://www.rfc-editor.org/info/rfc6536>.
[RFC6536] Bierman、A。およびM. Bjorklund、「Network Configuration Protocol（NETCONF）Access Control Model」、RFC 6536、DOI 10.17487 / RFC6536、2012年3月、<https://www.rfc-editor.org/info/ rfc6536>。
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, May 2012, <https://www.rfc-editor.org/info/rfc6614>.
[RFC6614] Winter、S.、McCauley、M.、Venaas、S.、and K. Wierenga、 "Transport Layer Security（TLS）Encryption for RADIUS"、RFC 6614、DOI 10.17487 / RFC6614、May 2012、<https：/ /www.rfc-editor.org/info/rfc6614>。
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <https://www.rfc-editor.org/info/rfc6733>.
[RFC6733] Fajardo、V。、編、Arkko、J.、Loughney、J。、およびG. Zorn、編、「Diameter Base Protocol」、RFC 6733、DOI 10.17487 / RFC6733、2012年10月、<https：/ /www.rfc-editor.org/info/rfc6733>。
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RESTCONFプロトコル」、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040 >。
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.
[RFC8095] Fairhurst、G。、編、Trammell、B。、編、およびM. Kuehlewind、編、「IETFトランスポートプロトコルおよび輻輳制御メカニズムによって提供されるサービス」、RFC 8095、DOI 10.17487 / RFC8095、2017年3月、<https://www.rfc-editor.org/info/rfc8095>。
[RFC8242] Haas, J. and S. Hares, "Interface to the Routing System (I2RS) Ephemeral State Requirements", RFC 8242, DOI 10.17487/RFC8242, September 2017, <http://www.rfc-editor.org/info/rfc8242>.
[RFC8242] Haas、J。およびS. Hares、「Interface to the Routing System（I2RS）Ephemeral State Requirements」、RFC 8242、DOI 10.17487 / RFC8242、2017年9月、<http://www.rfc-editor.org/ info / rfc8242>。
Acknowledgements
謝辞
The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, Dacheng Zhang, Alia Atlas, and Jeff Haas for their contributions to the I2RS security requirements discussion and this document. The authors would like to thank Bob Moskowitz, Kathleen Moriarty, Stephen Farrell, Radia Perlman, Alvaro Retana, Ben Campbell, and Alissa Cooper for their review of these requirements.
著者は、I2RSセキュリティ要件の議論とこのドキュメントへの貢献に対して、ウェスジョージ、アーメドアブロ、キンウー、エリックユー、ジョエルハルパーン、スコットブリム、ナンシーカムウィンゲット、ダチェンチャン、アリアアトラス、ジェフハースに感謝します。 。著者は、これらの要件のレビューについて、Bob Moskowitz、Kathleen Moriarty、Stephen Farrell、Radia Perlman、Alvaro Retana、Ben Campbell、およびAlissa Cooperに感謝します。
Authors' Addresses
著者のアドレス
Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 United States of America
Susan Hares Huawei 7453 Hickory Hill Saline、MI 48176アメリカ合衆国
Email: shares@ndzh.com
Daniel Migault Ericsson 8275 Trans Canada Route Saint Laurent, QC H4S Canada
Daniel Migault Ericsson 8275 Trans Canada Route Saint Laurent、QC H4S Canada
Email: daniel.migault@ericsson.com
Joel Halpern Ericsson United States of America
Joel Halpern Ericssonアメリカ合衆国
Email: joel.halpern@ericsson.com