[要約] RFC 9061は、ソフトウェア定義ネットワーキング（SDN）に基づくIPsecフロー保護のためのYANGデータモデルを定義しています。この文書の目的は、ネットワークのセキュリティを強化し、管理を簡素化するための標準化された方法を提供することです。利用場面としては、企業や組織がSDNを活用して、ネットワーク内のデータ転送を安全に保護する際に適用されます。
Internet Engineering Task Force (IETF) R. Marin-Lopez
Request for Comments: 9061 G. Lopez-Millan
Category: Standards Track University of Murcia
ISSN: 2070-1721 F. Pereniguez-Garcia
University Defense Center
July 2021
A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)
ソフトウェア定義ネットワーキング（SDN）に基づくIPSecフロー保護のためのヤンデータモデル
Abstract
概要
This document describes how to provide IPsec-based flow protection (integrity and confidentiality) by means of an Interface to Network Security Function (I2NSF) Controller. It considers two main well-known scenarios in IPsec: gateway-to-gateway and host-to-host. The service described in this document allows the configuration and monitoring of IPsec Security Associations (IPsec SAs) from an I2NSF Controller to one or several flow-based Network Security Functions (NSFs) that rely on IPsec to protect data traffic.
この文書では、ネットワークセキュリティ機能（I2NSF）コントローラへのインタフェースを使用して、IPSecベースのフロー保護（整合性と機密性）を提供する方法について説明します。IPsec：ゲートウェイからゲートウェイとホストへの2つの主要な既知のシナリオを考慮しています。この文書に記載されているサービスにより、I2NSFコントローラからのIPSecセキュリティアソシエーション（IPSec SAS）の構成と監視は、IPsecにデータトラフィックを保護するためにIPsecに依存する1つまたは複数のフローベースのネットワークセキュリティ機能（NSF）に依存します。
This document focuses on the I2NSF NSF-Facing Interface by providing YANG data models for configuring the IPsec databases, namely Security Policy Database (SPD), Security Association Database (SAD), Peer Authorization Database (PAD), and Internet Key Exchange Version 2 (IKEv2). This allows IPsec SA establishment with minimal intervention by the network administrator. This document defines three YANG modules, but it does not define any new protocol.
このドキュメントは、IPsecデータベース、すなわちセキュリティポリシーデータベース（SPD）、セキュリティアソシエーションデータベース（SAD）、ピア認証データベース（PAD）、およびインターネットキー交換バージョン2を設定するためのYangデータモデルを提供することによって、I2NSF NSF Facingインタフェースに焦点を当てています（IKEV2）。これにより、ネットワーク管理者による最小限の介入でIPsec SAが確立できます。この文書は3つのYANモジュールを定義していますが、新しいプロトコルを定義しません。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc9061.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9061で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
2.1. Requirements Language
3. SDN-Based IPsec Management Description
3.1. IKE Case: IKEv2/IPsec in the NSF
3.2. IKE-less Case: IPsec (No IKEv2) in the NSF
4. IKE Case vs. IKE-less Case
4.1. Rekeying Process
4.2. NSF State Loss
4.3. NAT Traversal
4.4. NSF Registration and Discovery
5. YANG Configuration Data Models
5.1. The 'ietf-i2nsf-ikec' Module
5.1.1. Data Model Overview
5.1.2. YANG Module
5.2. The 'ietf-i2nsf-ike' Module
5.2.1. Data Model Overview
5.2.2. Example Usage
5.2.3. YANG Module
5.3. The 'ietf-i2nsf-ikeless' Module
5.3.1. Data Model Overview
5.3.2. Example Usage
5.3.3. YANG Module
6. IANA Considerations
7. Security Considerations
7.1. IKE Case
7.2. IKE-less Case
7.3. YANG Modules
8. References
8.1. Normative References
8.2. Informative References
Appendix A. XML Configuration Example for IKE Case
(Gateway-to-Gateway)
Appendix B. XML Configuration Example for IKE-less Case
(Host-to-Host)
Appendix C. XML Notification Examples
Appendix D. Operational Use Case Examples
D.1. Example of IPsec SA Establishment
D.1.1. IKE Case
D.1.2. IKE-less Case
D.2. Example of the Rekeying Process in IKE-less Case
D.3. Example of Managing NSF State Loss in the IKE-less Case
Acknowledgements
Authors' Addresses
Software-Defined Networking (SDN) is an architecture that enables administrators to directly program, orchestrate, control, and manage network resources through software. The SDN paradigm relocates the control of network resources to a centralized entity, namely the SDN Controller. SDN Controllers configure and manage distributed network resources and provide an abstracted view of the network resources to SDN applications. SDN applications can customize and automate the operations (including management) of the abstracted network resources in a programmable manner via this interface [RFC7149] [ITU-T.Y.3300] [ONF-SDN-Architecture] [ONF-OpenFlow].
ソフトウェア定義ネットワーク（SDN）は、管理者がソフトウェアを介してネットワークリソースを直接プログラム、オーケストレート、制御、および管理することを可能にするアーキテクチャです。SDNパラダイムは、ネットワークリソースの制御を集中型エンティティ、すなわちSDNコントローラに再配置します。SDNコントローラは、分散ネットワークリソースを構成および管理し、SDNアプリケーションにネットワークリソースの抽象化されたビューを提供します。SDNアプリケーションは、このインタフェース[RFC7149] [ITU-T.Y.3300] [ONF-SDN-Architecture] [ONF-OpenFlow]を介して、抽象化されたネットワークリソースの操作（管理を含む）をプログラム可能な方法でカスタマイズおよび自動化できます。
Recently, several network scenarios now demand a centralized way of managing different security aspects, for example, Software-Defined WANs (SD-WANs). SD-WANs are SDN extensions providing software abstractions to create secure network overlays over traditional WAN and branch networks. SD-WANs utilize IPsec [RFC4301] as an underlying security protocol. The goal of SD-WANs is to provide flexible and automated deployment from a centralized point to enable on-demand network security services, such as IPsec Security Association (IPsec SA) management. Additionally, Section 4.3.3 ("Client-Specific Security Policy in Cloud VPNs") of [RFC8192] describes another example use case for a cloud data center scenario. The use case in [RFC8192] states that "dynamic key management is critical for securing the VPN and the distribution of policies". These VPNs can be established using IPsec. The management of IPsec SAs in data centers using a centralized entity is a scenario where the current specification may be applicable.
最近、いくつかのネットワークシナリオが現在、ソフトウェア定義のWAN（SD-WAN）など、さまざまなセキュリティ側面を管理するための集中的な方法を要求します。 SD-WANSは、従来のWANおよびブランチネットワークを介して安全なネットワークオーバーレイを作成するためのソフトウェアの抽象化を提供するSDN拡張です。 SD-WANは、基礎となるセキュリティプロトコルとしてIPsec [RFC4301]を使用します。 SD-WANの目的は、IPsec Security Association（IPsec SA）管理など、オンデマンドネットワークセキュリティサービスを有効にするために集中ポイントから柔軟で自動化された展開を提供することです。さらに、[RFC8192]のセクション4.3.3（Cloud VPNSの「クライアント固有のセキュリティポリシー」）は、クラウドデータセンターのシナリオのための別の例のユースケースを説明しています。 [RFC8192]のユースケースは、「動的鍵管理はVPNとポリシーの分布を確保するために重要である」と述べています。これらのVPNはIPsecを使用して確立できます。集中型エンティティを使用したデータセンターのIPsec SASの管理は、現在の仕様が適用可能であるシナリオです。
Therefore, with the growth of SDN-based scenarios where network resources are deployed in an autonomous manner, a mechanism to manage IPsec SAs from a centralized entity becomes more relevant in the industry.
したがって、ネットワークリソースが自律的に展開されているSDNベースのシナリオの成長を伴うと、集中企業からIPsec SASを管理するためのメカニズムが業界でより関連性があります。
In response to this need, the Interface to Network Security Functions (I2NSF) charter states that the goal of this working group is "to define a set of software interfaces and data models for controlling and monitoring aspects of physical and virtual NSFs". As defined in [RFC8192], a Network Security Function (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". This document pays special attention to flow-based NSFs that ensure integrity and confidentiality by means of IPsec.
この必要性に応答して、ネットワークセキュリティ機能へのインタフェース（I2NSF）チャーターは、このワーキンググループの目標が「一連のソフトウェアインターフェイスと、物理的および仮想NSFの側面を制御して監視するためのデータモデル」となることを示しています。[RFC8192]で定義されているように、ネットワークセキュリティ機能（NSF）は「ネットワーク通信の完全性、機密性、または可用性を確保するために使用される機能です。不要なネットワーク活動を検出する。または少なくとも軽減、効果を軽減する不要な活動の。この文書は、IPsecによる完全性と機密性を確保するフローベースのNSFに特別な注意を払います。
In fact, Section 3.1.9 of [RFC8192] states that "there is a need for a controller to create, manage, and distribute various keys to distributed NSFs"; however, "there is a lack of a standard interface to provision and manage security associations". Inspired by the SDN paradigm, the I2NSF framework [RFC8329] defines a centralized entity, the I2NSF Controller, which manages one or multiple NSFs through an I2NSF NSF-Facing Interface. In this document, an architecture is defined for allowing the I2NSF Controller to carry out the key management procedures. More specifically, three YANG data models are defined for the I2NSF NSF-Facing Interface, which allows the I2NSF Controller to configure and monitor IPsec-enabled, flow-based NSFs.
実際、[RFC8192]のセクション3.1.9は「コントローラがさまざまなキーを作成、管理、および分散するためのコントローラがNSFSに登録、管理、配布する必要がある」と述べています。ただし、「セキュリティアソシエーションをプロビジョニングおよび管理するための標準的なインターフェイスが不足しています」。SDN ParadigmにインスパイアされたI2NSFフレームワーク[RFC8329]は、I2NSFコントローラであるI2NSFコントローラを定義します。これは、I2NSF NSF対面インタフェースを介して1つまたは複数のNSFを管理します。この文書では、I2NSFコントローラが鍵管理手順を実行できるようにするためのアーキテクチャが定義されています。より具体的には、I2NSF NSF対話型インタフェースに対して3つのYANGデータモデルが定義されています。これにより、I2NSFコントローラはIPSec対応のフローベースのNSFSを設定および監視できます。
The IPsec architecture [RFC4301] defines a clear separation between the processing to provide security services to IP packets and the key management procedures to establish the IPsec SAs, which allows centralizing the key management procedures in the I2NSF Controller. This document considers two typical scenarios to autonomously manage IPsec SAs: gateway-to-gateway and host-to-host [RFC6071]. In these cases, hosts, gateways, or both may act as NSFs. Due to its complexity, consideration for the host-to-gateway scenario is out of scope. The source of this complexity comes from the fact that, in this scenario, the host may not be under the control of the I2NSF Controller and, therefore, it is not configurable. Nevertheless, the I2NSF interfaces defined in this document can be considered as a starting point to analyze and provide a solution for the host-to-gateway scenario.
IPsecアーキテクチャ[RFC4301]は、IPパケットへのセキュリティサービスを提供するための処理とIPSec SASを確立するためのキー管理手順との間の明確な分離を定義します。この資料は、IPsec SAS：Gateway-To-GatewayとHost-To-Host [RFC6071]を自律的に管理するための2つの典型的なシナリオを考慮します。このような場合、ホスト、ゲートウェイ、またはその両方がNSFとして機能する可能性があります。その複雑さのため、ホストツーゲートウェイのシナリオの検討は範囲外です。この複雑さの原因は、このシナリオでは、ホストがI2NSFコントローラの制御下にない可能性があり、したがって設定できません。それにもかかわらず、このドキュメントで定義されているI2NSFインタフェースは、Analyzeを分析し、ホスト間のシナリオのソリューションを提供するための開始点と見なすことができます。
For the definition of the YANG data models for the I2NSF NSF-Facing Interface, this document considers two general cases, namely:
I2NSF NSF FaceingインタフェースのYANDデータモデルの定義については、この文書は2つの一般的なケースを考慮しています。
1. IKE case. The NSF implements the Internet Key Exchange Version 2 (IKEv2) protocol and the IPsec databases: the Security Policy Database (SPD), the Security Association Database (SAD), and the Peer Authorization Database (PAD). The I2NSF Controller is in charge of provisioning the NSF with the required information in the SPD and PAD (e.g., IKE credentials) and the IKE protocol itself (e.g., parameters for the IKE_SA_INIT negotiation).
1. イークケース。NSFは、インターネットキー交換バージョン2（IKEv2）プロトコルとIPsecデータベースを実装しています。セキュリティポリシーデータベース（SPD）、セキュリティアソシエーションデータベース（SAD）、およびピア認証データベース（PAD）。I2NSFコントローラは、SPDおよびパッド内の必要な情報（例えば、IKE認証情報）およびIKEプロトコル自体（例えば、IKE_SA_INITネゴシエーションのためのパラメータ）を用いてNSFをプロビジョニングすることを担当する。
2. IKE-less case. The NSF only implements the IPsec databases (no IKE implementation). The I2NSF Controller will provide the required parameters to create valid entries in the SPD and the SAD of the NSF. Therefore, the NSF will only have support for IPsec whereas key management functionality is moved to the I2NSF Controller.
2. IKEの少ない場合NSFはIPSecデータベースのみを実装しています（IKE実装はありません）。I2NSFコントローラは、SPD内の有効なエントリとNSFのSADを作成するために必要なパラメータを提供します。したがって、NSFはIPSecのサポートしかサポートしませんが、キー管理機能はI2NSFコントローラに移動します。
In both cases, a YANG data model for the I2NSF NSF-Facing Interface is required to carry out this provisioning in a secure manner between the I2NSF Controller and the NSF. Using YANG data modeling language version 1.1 [RFC7950] and based on YANG data models defined in [netconf-vpn] and [TRAN-IPSECME-YANG] and the data structures defined in [RFC4301] and [RFC7296], this document defines the required interfaces with a YANG data model for configuration and state data for IKE, PAD, SPD, and SAD (see Sections 5.1, 5.2, and 5.3). The proposed YANG data model conforms to the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. Examples of the usage of these data models can be found in Appendices A, B, and C.
どちらの場合も、I2NSF NSF対立インタフェースのYANDデータモデルは、I2NSFコントローラとNSFの間の安全な方法でこのプロビジョニングを実行する必要があります。Yangデータモデリング言語バージョン1.1 [RFC7950]と[NetConf-VPN]と[TRAN-IPSecme-yang]で定義されているYangデータモデルと[RFC4301]と[RFC7296]で定義されているYANGデータモデルに基づいて、この文書は必要なものを定義しています。IKE、PAD、SPD、およびSADの構成および状態データのYANGデータモデルとインタフェースします（セクション5.1,5.2,5.3を参照）。提案されたYANGデータモデルは、[RFC8342]で定義されているネットワーク管理データストアアーキテクチャ（NMDA）に準拠しています。これらのデータモデルの使用例は、付録A、B、およびCにあります。
In summary, the objectives of this document are:
要約すると、この文書の目的は次のとおりです。
* To describe the architecture for I2NSF-based IPsec management, which allows for the establishment and management of IPsec Security Associations from the I2NSF Controller in order to protect specific data flows between two flow-based NSFs implementing IPsec.
* I2NSFベースのIPsec管理のためのアーキテクチャを説明するために、IPSECを実装する2つのフローベースのNSFS間の特定のデータフローを保護するために、I2NSFコントローラからのIPSecセキュリティアソシエーションの確立と管理を可能にします。
* To map this architecture to the I2NSF framework.
* このアーキテクチャをI2NSFフレームワークにマップする。
* To define the interfaces required to manage and monitor the IPsec SAs in the NSF from an I2NSF Controller. YANG data models are defined for configuration and state data for IPsec and IKEv2 management through the I2NSF NSF-Facing Interface. The YANG data models can be used via existing protocols, such as the Network Configuration Protocol (NETCONF) [RFC6241] or RESTCONF [RFC8040]. Thus, this document defines three YANG modules (see Section 5) but does not define any new protocol.
* I2NSFコントローラからNSFのIPSec SASの管理と監視に必要なインタフェースを定義するには。Yangデータモデルは、I2NSF NSF Facing Interfaceを介したIPSecおよびIKEv2管理の構成および状態データに対して定義されています。Yangデータモデルは、ネットワーク構成プロトコル（NETCONF）[RFC6241]またはRESTCONF [RFC8040]など、既存のプロトコルを介して使用できます。したがって、この文書は3つのYANGモジュールを定義します（セクション5を参照）が、新しいプロトコルを定義しません。
This document uses the terminology described in [ITU-T.Y.3300], [RFC8192], [RFC4301], [RFC6437], [RFC7296], [RFC6241], and [RFC8329].
この文書では、用語は、[ITU-T.Y.3300]に記載の[RFC8192]、[RFC4301]、[RFC6437]、[RFC7296]、[RFC6241]及び[RFC8329]を使用します。
The following term is defined in [ITU-T.Y.3300]:
次の用語は[ITU-T.Y.3300]で定義されています。
* Software-Defined Networking (SDN)
* ソフトウェア定義ネットワーク（SDN）
The following terms are defined in [RFC8192]:
次の用語は[RFC8192]に定義されています。
* Network Security Function (NSF)
* ネットワークセキュリティ機能（NSF）
* flow-based NSF
* フローベースのNSF
The following terms are defined in [RFC4301]:
次の用語は[RFC4301]で定義されています。
* Peer Authorization Database (PAD)
* ピア認証データベース（PAD）
* Security Association Database (SAD)
* セキュリティアソシエーションデータベース（SAD）
* Security Policy Database (SPD)
* セキュリティポリシーデータベース（SPD）
The following two terms are related or have identical definition/ usage in [RFC6437]:
次の2つの用語が関連付けられているか、[RFC6437]で同一の定義/使用法があります。
* flow
* フロー
* traffic flow
* 交通流
The following term is defined in [RFC7296]:
次の用語は[RFC7296]で定義されています。
* Internet Key Exchange Version 2 (IKEv2)
* インターネットキー交換バージョン2（IKEv2）
The following terms are defined in [RFC6241]:
次の用語は[RFC6241]に定義されています。
* configuration data
* 設定データ
* configuration datastore
* 構成データストア
* state data
* 州データ
* startup configuration datastore
* 起動設定データストア
* running configuration datastore
* 構成データストアの実行
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
As mentioned in Section 1, two cases are considered, depending on whether the NSF implements IKEv2 or not: the IKE case and the IKE-less case.
セクション1で述べたように、NSFがIKEV2を実装するかどうかに応じて、2つのケースが考慮されます.IKEケースとIKEレスケース。
In this case, the NSF implements IPsec with IKEv2 support. The I2NSF Controller is in charge of managing and applying IPsec connection information (determining which nodes need to start an IKEv2/IPsec session, identifying the type of traffic to be protected, and deriving and delivering IKEv2 credentials, such as a pre-shared key (PSK), certificates, etc.) and applying other IKEv2 configuration parameters (e.g., cryptographic algorithms for establishing an IKEv2 SA) to the NSF necessary for the IKEv2 negotiation.
この場合、NSFはIPSECをIKEV2サポートと実装しています。I2NSFコントローラは、IPsec接続情報の管理と適用を担当しています（どのノードがIKEv2 / IPSecセッションを開始する必要があるかを判断し、保護されるトラフィックの種類を識別し、事前共有キーなどのIKEv2認証情報の導出および配信PSK）、証明書など）と他のIKEv2構成パラメータ（例えば、IKEv2 SAを確立するための暗号化アルゴリズム）をIKEv2ネゴシエーションに必要なNSFに適用します。
With these entries, the IKEv2 implementation can operate to establish the IPsec SAs. The I2NSF User establishes the IPsec requirements and information about the endpoints (through the I2NSF Consumer-Facing Interface [RFC8329]), and the I2NSF Controller translates these requirements into IKEv2, SPD, and PAD entries that will be installed into the NSF (through the I2NSF NSF-Facing Interface). With that information, the NSF can just run IKEv2 to establish the required IPsec SA (when the traffic flow needs protection). Figure 1 shows the different layers and corresponding functionality.
これらのエントリを使用すると、IKEV2実装はIPSec SASを確立するように動作できます。I2NSFユーザーは、IPSecの要件とエンドポイントに関する情報（I2NSFコンシューマインターフェイス[RFC8329]を介して）を確立し、I2NSFコントローラはこれらの要件をIKEv2、SPD、およびNSFにインストールされるパッドエントリに変換します（I2NSF NSFフェイスインターフェイス）。その情報を使用すると、NSFはIKEV2を実行して必要なIPsec SAを確立できます（トラフィックフローが保護が必要な場合）。図1は、異なる層と対応する機能を示しています。
+-------------------------------------------+
| IPsec Management System | I2NSF User
+-------------------------------------------+
|
| I2NSF Consumer-Facing
| Interface
+-------------------------------------------+
| IKEv2 Configuration, PAD and SPD Entries | I2NSF
| Distribution | Controller
+-------------------------------------------+
|
| I2NSF NSF-Facing
| Interface
+-------------------------------------------+
| IKEv2 | IPsec(PAD, SPD) | Network
|-------------------------------------------| Security
| IPsec Data Protection and Forwarding | Function
+-------------------------------------------+
Figure 1: IKE Case: IKE/IPsec in the NSF
I2NSF-based IPsec flow protection services provide dynamic and flexible management of IPsec SAs in flow-based NSFs. In order to support this capability in the IKE case, a YANG data model for IKEv2, SPD, and PAD configuration data and for IKEv2 state data needs to be defined for the I2NSF NSF-Facing Interface (see Section 5).
I2NSFベースのIPSecフロー保護サービスは、フローベースのNSFS内のIPSec SASの動的で柔軟な管理を提供します。IKEケース内のこの機能をサポートするためには、IKEv2、SPD、およびPAD構成データおよびIKEv2状態データのYANDデータモデルをI2NSF NSF対立インターフェースに対して定義する必要がある（セクション5参照）。
In this case, the NSF does not deploy IKEv2 and, therefore, the I2NSF Controller has to perform the IKEv2 security functions and management of IPsec SAs by populating and managing the SPD and the SAD.
この場合、NSFはIKEV2を展開しないため、I2NSFコントローラはSPDとSADを搭載および管理することでIPSec SASのIPSEC SASの管理を実行する必要があります。
As shown in Figure 2, when an I2NSF User enforces flow-based protection policies through the Consumer-Facing Interface, the I2NSF Controller translates these requirements into SPD and SAD entries, which are installed in the NSF. PAD entries are not required, since there is no IKEv2 in the NSF.
図2に示すように、I2NSFユーザがコンシューマ対面インタフェースを介してフローベースの保護ポリシーを強制すると、I2NSFコントローラはこれらの要件をSPDおよびSADエントリに変換し、これはNSFにインストールされます。NSFにIKEv2がないため、パッドエントリは不要です。
+-----------------------------------------+
| IPsec Management System | I2NSF User
+-----------------------------------------+
|
| I2NSF Consumer-Facing Interface
|
+-----------------------------------------+
| SPD and SAD Entries | I2NSF
| Distribution | Controller
+-----------------------------------------+
|
| I2NSF NSF-Facing Interface
|
+-----------------------------------------+
| IPsec (SPD, SAD) | Network
|-----------------------------------------| Security
| IPsec Data Protection and Forwarding | Function
+-----------------------------------------+
Figure 2: IKE-less Case: IPsec (No IKEv2) in the NSF
図2：IKEレスケース：NSFのIPSec（なしIKEv2）
In order to support the IKE-less case, a YANG data model for SPD and SAD configuration data and SAD state data MUST be defined for the NSF-Facing Interface (see Section 5).
IKEレスケースをサポートするためには、SPDおよびSAD構成データおよびSAD状態データのYANDデータモデルをNSF対立インタフェースに対して定義する必要がある（セクション5参照）。
Specifically, the IKE-less case assumes that the I2NSF Controller has to perform some security functions that IKEv2 typically does, namely (non-exhaustive list):
具体的には、IKE - LESSケースは、I2NSFコントローラがIKEv2が通常行うセキュリティ機能を実行しなければならないと仮定しています。つまり、（網羅的なリスト）
* Initialization Vector (IV) generation
* 初期化ベクトル（IV）生成
* prevention of counter resets for the same key
* 同じキーのためのカウンタリセットの防止
* generation of pseudorandom cryptographic keys for the IPsec SAs
* IPsec SASのための擬似乱数暗号鍵の生成
* generation of the IPsec SAs when required based on notifications (i.e., sadb-acquire) from the NSF
* NSFからの通知（すなわち、SADB - 取得）に基づいて必要な場合のIPSec SASの生成
* rekey of the IPsec SAs based on notifications from the NSF (i.e., expire)
* NSFからの通知に基づいてIPsec SASの再キー（すなわち、期限切れ）
* NAT traversal discovery and management
* NATトラバーサル発見と管理
Additionally to these functions, another set of tasks must be performed by the I2NSF Controller (non-exhaustive list):
さらにこれらの関数に加えて、I2NSFコントローラ（非網羅的なリスト）によって別のタスクのセットを実行する必要があります。
* IPsec SA's Security Parameter Index (SPI) random generation
* IPsec SAのセキュリティパラメータインデックス（SPI）ランダム発生
* cryptographic algorithm selection
* 暗号化アルゴリズムの選択
* usage of extended sequence numbers
* 拡張シーケンス番号の使用
* establishment of proper Traffic Selectors
* 適切な交通セレクタの確立
In principle, the IKE case is easier to deploy than the IKE-less case because current flow-based NSFs (either hosts or gateways) have access to IKEv2 implementations. While gateways typically deploy an IKEv2/IPsec implementation, hosts can easily install it. As a downside, the NSF needs more resources to use IKEv2, such as memory for the IKEv2 implementation and computation, since each IPsec Security Association rekeying MAY involve a Diffie-Hellman (DH) exchange.
原則として、現在のフローベースのNSF（ホストまたはゲートウェイ）がIKEv2実装にアクセスできるため、IKEの場合よりもIKEの場合よりも展開が簡単です。ゲートウェイは通常IKEv2 / IPsec実装を展開している間、ホストは簡単にインストールできます。ダウンサイドとして、各IPSecセキュリティアソシエーションの回復がDiffie-Hellman（DH）交換を伴う可能性があるため、NSFはIKEv2実装と計算のメモリなどのIKEv2を使用するためのリソースを必要とします。
Alternatively, the IKE-less case benefits the deployment in resource-constrained NSFs. Moreover, IKEv2 does not need to be performed in gateway-to-gateway and host-to-host scenarios under the same I2NSF Controller (see Appendix D.1). On the contrary, the complexity of creating and managing IPsec SAs is shifted to the I2NSF Controller since IKEv2 is not in the NSF. As a consequence, this may result in a more complex implementation in the controller side in comparison with the IKE case. For example, the I2NSF Controller has to deal with the latency existing in the path between the I2NSF Controller and the NSF (in order to solve tasks, such as rekey) or creation and installation of new IPsec SAs. However, this is not specific to this contribution but a general aspect in any SDN-based network. In summary, this complexity may create some scalability and performance issues when the number of NSFs is high.
あるいは、IKE-LESSケースは、リソース制約付きNSFSの展開に利益をもたらします。さらに、IKEV2は、同じI2NSFコントローラの下でゲートウェイからホストへのシナリオで実行する必要はありません（付録D.1を参照）。それどころか、IPSEV SAの作成と管理の複雑さは、IKEV2がNSFにないため、I2NSFコントローラにシフトします。結果として、これはIKEの場合と比較してコントローラ側でより複雑な実装をもたらす可能性がある。たとえば、I2NSFコントローラは、I2NSFコントローラとNSFのパスに存在するレイテンシ（再キーなどのタスクを解決するために）または新しいIPSec SASの作成とインストールに存在する待ち時間を処理する必要があります。ただし、これはこの貢献に固有のものではありませんが、どのSDNベースのネットワークの一般的な側面です。要約すると、この複雑さは、NSFの数が多いときにいくつかのスケーラビリティとパフォーマンスの問題を生じさせる可能性があります。
Nevertheless, literature around SDN-based network management using a centralized controller (like the I2NSF Controller) is aware of scalability and performance issues, and solutions have been already provided and discussed (e.g., hierarchical controllers, having multiple replicated controllers, dedicated high-speed management networks, etc.). In the context of I2NSF-based IPsec management, one way to reduce the latency and alleviate some performance issues can be to install the IPsec policies and IPsec SAs at the same time (proactive mode, as described in Appendix D.1) instead of waiting for notifications (e.g., a sadb-acquire notification received from an NSF requiring a new IPsec SA) to proceed with the IPsec SA installation (reactive mode). Another way to reduce the overhead and the potential scalability and performance issues in the I2NSF Controller is to apply the IKE case described in this document since the IPsec SAs are managed between NSFs without the involvement of the I2NSF Controller at all, except by the initial configuration (i.e., IKEv2, PAD, and SPD entries) provided by the I2NSF Controller. Other solutions, such as Controller-IKE [IPSECME-CONTROLLER-IKE], have proposed that NSFs provide their DH public keys to the I2NSF Controller so that the I2NSF Controller distributes all public keys to all peers. All peers can calculate a unique pairwise secret for each other peer, and there is no inter-NSF messages. A rekey mechanism is further described in [IPSECME-CONTROLLER-IKE].
それにもかかわらず、集中型コントローラを使用したSDNベースのネットワーク管理に関する文献（I2NSFコントローラのように）は、スケーラビリティとパフォーマンスの問題を認識しており、解決策はすでに提供され、議論されており（例えば、複数の複製コントローラ、専用の高速化を備えた階層コントローラなど）。管理ネットワークなど）。 I2NSFベースのIPSec管理のコンテキストでは、待ち時間を減らし、一部のパフォーマンスの問題を軽減する1つの方法は、待機の代わりに同時にIPSecポリシーとIPSec SASを同時にインストールすることです（付録D.1で説明されているようにプロアクティブモード）。通知の場合（たとえば、新しいIPsec SAを必要とするNSFから受信したSADB-獲得通知）は、IPsec SAのインストール（Reactive Mode）を進めます。 i2nSFコントローラのオーバーヘッドを減らすもう1つの方法は、IPSec SASがすべてのI2NSFコントローラの関与なしにNSFS間で管理されているため、この文書に記載されているIKEケースを適用することです。 I2NSFコントローラによって提供される（IEKEV2、PAD、およびSPDエントリ）。 Controller-IKE [IPSecme-Controller-IKE]などの他の解決策は、NSFSがI2NSFコントローラにDHパブリックキーを提供することを提案し、そのため、I2NSFコントローラはすべてのパブリックキーをすべてのピアに配布します。すべてのピアは、他のピアの独自のペアワイズ秘密を計算でき、NSF間メッセージはありません。 [IPSecme-Controller-IKE]では、リリーキーメカニズムがさらに説明されています。
In terms of security, the IKE case provides better security properties than the IKE-less case, as discussed in Section 7. The main reason is that the NSFs generate the session keys and not the I2NSF Controller.
セキュリティに関しては、IKEケースはセクション7で説明されているように、IKE以降の場合よりも優れたセキュリティ特性を提供します。主な理由は、NSFSがI2NSFコントローラではなくセッションキーを生成することです。
Performing a rekey for IPsec SAs is an important operation during the IPsec SAs management. With the YANG data models defined in this document the I2NSF Controller can configure parameters of the rekey process (IKE case) or conduct the rekey process (IKE-less case). Indeed, depending on the case, the rekey process is different.
IPsec SASのリリーキーを実行することは、IPsec SAS管理中に重要な操作です。この文書で定義されたYangデータモデルでは、I2NSFコントローラはリリースプロセス（IKEケース）のパラメータを設定したり、リリースプロセス（IKEレスケース）を実行できます。実際、ケースによっては、リリースプロセスが異なります。
For the IKE case, the rekeying process is carried out by IKEv2, following the information defined in the SPD and SAD (i.e., based on the IPsec SA lifetime established by the I2NSF Controller using the YANG data model defined in this document). Therefore, IPsec connections will live unless something different is required by the I2NSF User or the I2NSF Controller detects something wrong.
IKEケースの場合、REKINGプロセスは、SPDおよびSADで定義された情報（すなわち、このドキュメントで定義されているYANDデータモデルを使用してI2NSFコントローラによって確立されたIPSec SAライフタイムに基づいて）に従って、IKEv2によって実行されます。したがって、I2NSFユーザーまたはI2NSFコントローラによって異なるものが何が悪いことを検出しない限り、IPsec接続は生きます。
For the IKE-less case, the I2NSF Controller MUST take care of the rekeying process. When the IPsec SA is going to expire (e.g., IPsec SA soft lifetime), it MUST create a new IPsec SA and it MAY remove the old one (e.g., when the lifetime of the old IPsec SA has not been defined). This rekeying process starts when the I2NSF Controller receives a sadb-expire notification or, on the I2NSF Controller's initiative, based on lifetime state data obtained from the NSF. How the I2NSF Controller implements an algorithm for the rekey process is out of the scope of this document. Nevertheless, an example of how this rekey could be performed is described in Appendix D.2.
IKEレスケースの場合、I2NSFコントローラはリークプロセスの世話をする必要があります。IPsec SAが期限切れになると（例えば、IPsec SA Soft Lifetime）、それは新しいIPsec SAを作成する必要があり、それは古いものを削除するかもしれません（例えば、古いIPsec SAの存続期間が定義されていない場合）。このRekingプロセスは、I2NSFコントローラがSADB-EFFIRE通知を受信したとき、またはI2NSFコントローラのイニシアチブで、NSFから取得した寿命の状態データに基づいて開始されます。I2NSFコントローラがリリースプロセスのアルゴリズムを実装する方法は、この文書の範囲外です。それにもかかわらず、このリリースをどのように実行できるかの例は付録D.2に記載されている。
If one of the NSF restarts, it will lose the IPsec state (affected NSF). By default, the I2NSF Controller can assume that all the state has been lost and, therefore, it will have to send IKEv2, SPD, and PAD information to the NSF in the IKE case and SPD and SAD information in the IKE-less case.
NSFの1つが再起動した場合、IPsec状態（影響を受けるNSF）が失われます。デフォルトでは、I2NSFコントローラはすべての状態が失われていると仮定することができ、したがってIKE以降の場合のIKEケースおよびSPDおよびSAD情報のIKEv2、SPD、およびPAD情報を送信する必要があることになります。
In both cases, the I2NSF Controller is aware of the affected NSF (e.g., the NETCONF/TCP connection is broken with the affected NSF, the I2NSF Controller is receiving a sadb-bad-spi notification from a particular NSF, etc.). Moreover, the I2NSF Controller keeps a list of NSFs that have IPsec SAs with the affected NSF. Therefore, it knows the affected IPsec SAs.
どちらの場合も、I2NSFコントローラは影響を受けるNSFを認識している（例えば、NetConf / TCP接続が影響を受けるNSFで破損しているため、I2NSFコントローラは特定のNSFなどからSADB-BAD-SPI通知を受信しています）。さらに、I2NSFコントローラは、影響を受けるNSFを持つIPSec SASを持つNSFのリストを保持します。したがって、影響を受けるIPsec SASを知っています。
In the IKE case, the I2NSF Controller may need to configure the affected NSF with the new IKEv2, SPD, and PAD information. Alternatively, IKEv2 configuration MAY be made permanent between NSF reboots without compromising security by means of the startup configuration datastore in the NSF. This way, each time an NSF reboots, it will use that configuration for each rebooting. It would imply avoiding contact with the I2NSF Controller. Finally, the I2NSF Controller may also need to send new parameters (e.g., a new fresh PSK for authentication) to the NSFs that had IKEv2 SAs and IPsec SAs with the affected NSF.
IKEケースでは、I2NSFコントローラは、影響を受けるNSFを新しいIKEv2、SPD、およびパッド情報に設定する必要があります。あるいは、NSF内のスタートアップコンフィギュレーションデータストアによってセキュリティを犠牲にすることなく、IKEv2構成をNSF再起動の間で永続的にすることができる。このようにして、NSFが再起動するたびに、再起動ごとにその構成を使用します。I2NSFコントローラとの接触を避けることができます。最後に、I2NSFコントローラは、影響を受けるNSFを使用してIKEV2 SASおよびIPSec SASを持つNSFSに新しいパラメータ（例えば、認証用の新しいフレッシュPSK）を送信する必要があるかもしれません。
In the IKE-less case, the I2NSF Controller SHOULD delete the old IPsec SAs in the non-failed nodes established with the affected NSF. Once the affected node restarts, the I2NSF Controller MUST take the necessary actions to reestablish IPsec-protected communication between the failed node and those others having IPsec SAs with the affected NSF. How the I2NSF Controller implements an algorithm for managing a potential NSF state loss is out of the scope of this document. Nevertheless, an example of how this could be performed is described in Appendix D.3.
IKE-LESSケースでは、I2NSFコントローラは、影響を受けるNSFで確立された故障したノード内の古いIPsec SASを削除する必要があります。影響を受けるノードが再起動すると、I2NSFコントローラは、障害が発生したノードとIPsec SASを持つIPsec SASとの間のIPSec保護通信を再確立するために必要なアクションを取ります。I2NSFコントローラが潜在的なNSF状態損失を管理するためのアルゴリズムを実装する方法は、この文書の範囲外です。それにもかかわらず、これがどのように実行され得るかの例は付録D.3に記載されている。
In the IKE case, IKEv2 already provides a mechanism to detect whether some of the peers or both are located behind a NAT. In this case, UDP or TCP encapsulation for Encapsulating Security Payload (ESP) packets [RFC3948] [RFC8229] is required. Note that IPsec transport mode MUST NOT be used in this specification when NAT is required.
IKEケースでは、IKEV2はすでにピアまたはその両方がNATの後ろにあるかどうかを検出するためのメカニズムを提供しています。この場合、セキュリティペイロード（ESP）パケット[RFC3948] [RFC8229]をカプセル化するためのUDPまたはTCPカプセル化が必要です。なお、NATが必要な場合は、この仕様ではIPSecトランスポートモードを使用しないでください。
In the IKE-less case, the NSF does not have the assistance of the IKEv2 implementation to detect if it is located behind a NAT. If the NSF does not have any other mechanism to detect this situation, the I2NSF Controller SHOULD implement a mechanism to detect that case. The SDN paradigm generally assumes the I2NSF Controller has a view of the network under its control. This view is built either by requesting information from the NSFs under its control or information pushed from the NSFs to the I2NSF Controller. Based on this information, the I2NSF Controller MAY guess if there is a NAT configured between two hosts and apply the required policies to both NSFs besides activating the usage of UDP or TCP encapsulation of ESP packets [RFC3948] [RFC8229]. The interface for discovering if the NSF is behind a NAT is out of scope of this document.
IKE-LESSケースでは、NSFはNATの後ろにあるかどうかを検出するためのIKEV2実装の支援を受けていません。この状況を検出するためのNSFに他のメカニズムがない場合、I2NSFコントローラはその場合を検出するためのメカニズムを実装する必要があります。SDNパラダイムは一般に、I2NSFコントローラがその制御下でネットワークのビューを有すると仮定している。このビューは、NSFからの情報またはNSFSからI2NSFコントローラにプッシュされた情報の情報を要求することによって構築されます。この情報に基づいて、I2NSFコントローラは、2つのホスト間に設定されているNATがあるかどうかを推測し、ESPパケットのUDPまたはTCPカプセル化の使用のためにNSFの両方に必要なポリシーを適用します[RFC3948] [RFC8229]。NSFがNATの背後にあるかどうかを検出するためのインタフェースはこの文書の範囲外です。
If the I2NSF Controller does not have any mechanism to know whether a host is behind a NAT or not, then the IKE case MUST be used and not the IKE-less case.
I2NSFコントローラにホストがNATまたはNOTの背後にあるかどうかを知るメカニズムがない場合は、IKEケースを使用する必要があります。
NSF registration refers to the process of providing the I2NSF Controller information about a valid NSF, such as certificate, IP address, etc. This information is incorporated in a list of NSFs under its control.
NSF登録とは、証明書、IPアドレスなどの有効なNSFに関するI2NSFコントローラ情報を提供するプロセスを指します。この情報は、その制御の下でNSFのリストに組み込まれています。
The assumption in this document is that, for both cases, before an NSF can operate in this system, it MUST be registered in the I2NSF Controller. In this way, when the NSF starts and establishes a connection to the I2NSF Controller, it knows that the NSF is valid for joining the system.
この文書の仮定は、このシステムでNSFが動作する前に、どちらの場合も、I2NSFコントローラに登録する必要があることです。このようにして、NSFがI2NSFコントローラへの接続を開始して確立すると、NSFがシステムに参加するために有効であることを知っています。
Either during this registration process or when the NSF connects with the I2NSF Controller, the I2NSF Controller MUST discover certain capabilities of this NSF, such as what are the cryptographic suites supported, the authentication method, the support of the IKE case and/or the IKE-less case, etc.
この登録プロセス中またはNSFがI2NSFコントローラと接続する場合、I2NSFコントローラは、サポートされている暗号化スイート、認証方法、IKEケースのサポート、および/またはIKEなど、このNSFの特定の機能を発見する必要があります。なしの場合など
The registration and discovery processes are out of the scope of this document.
登録および発見プロセスはこの文書の範囲外です。
In order to support the IKE and IKE-less cases, models are provided for the different parameters and values that must be configured to manage IPsec SAs. Specifically, the IKE case requires modeling IKEv2 configuration parameters, SPD and PAD, while the IKE-less case requires configuration YANG data models for the SPD and SAD. Three modules have been defined: ietf-i2nsf-ikec (Section 5.1, common to both cases), ietf-i2nsf-ike (Section 5.2, IKE case), and ietf-i2nsf-ikeless (Section 5.3, IKE-less case). Since the module ietf-i2nsf-ikec has only typedef and groupings common to the other modules, a simplified view of the ietf-i2nsf-ike and ietf-i2nsf-ikeless modules is shown.
IKEやIKEの小さいケースをサポートするために、IPsec SASを管理するように構成する必要があるさまざまなパラメータと値に対してモデルが提供されています。具体的には、IKEケースはIKEV2構成パラメータ、SPDおよびPADをモデル化する必要がありますが、IKEレスケースではSPDとSADの設定YANGデータモデルが必要です。3つのモジュールが定義されています.IETF-I2NSF-IKEC（セクション5.1、両方の場合に共通）、IETF-I2NSF-IKE（セクション5.2、IKEケース）、およびIETF-I2NSF-IKEは（セクション5.3、IKE-LESSケース）。モジュールIETF-I2NSF-IKECはTypedefと他のモジュールに共通のグループ化のみをしているため、IETF-I2NSF-IKEおよびIETF-I2NSF-IKESINESモジュールの簡素化されたビューが示されています。
The module ietf-i2nsf-ikec only has definitions of data types (typedef) and groupings that are common to the other modules.
モジュールIETF-I2NSF-IKECには、他のモジュールに共通のデータ型（Typedef）とグループ化の定義のみがあります。
This module has normative references to [RFC3947], [RFC4301],
[RFC4303], [RFC8174], [RFC8221], [RFC3948], [RFC8229], [RFC6991],
[IANA-Protocols-Number], [IKEv2-Parameters],
[IKEv2-Transform-Type-1], and [IKEv2-Transform-Type-3].
<CODE BEGINS> file "ietf-i2nsf-ikec@2021-07-14.yang"
module ietf-i2nsf-ikec {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec";
prefix nsfikec;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types.";
}
organization
"IETF I2NSF Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/>
WG List: <mailto:i2nsf@ietf.org>
Author: Rafael Marin-Lopez
<mailto:rafa@um.es>
Author: Gabriel Lopez-Millan
<mailto:gabilm@um.es>
Author: Fernando Pereniguez-Garcia <mailto:fernando.pereniguez@cud.upct.es> "; description "Common data model for the IKE and IKE-less cases defined by the SDN-based IPsec flow protection service.
著者：Fernando Pereniguez-Garcia <mailto：fernando.pereniguez@cud.upct.es> ";説明" SDNベースのIPSecフロー保護サービスによって定義されたIKEおよびIKEレスケースの共通データモデル。
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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here.
キーワードは「必須」、「必須」、「shall」、「shall '、'は '、'は '、'推奨 '、'推奨されていない '、' may '、'任意のものではありません。'この文書では、ここに示すように、BCP 14（RFC 2119）（RFC 8174）に記載されているように解釈されるべきです。
Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（c）2021 IETF信頼とコードの著者として識別された人。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info).
修正の有無にかかわらず、ソースおよびバイナリ形式での再配布と使用は、IETF文書に関連するIETF信託の法的規定のセクション4.Cに記載されている単純化されたBSDライセンスに従い、身に付けられたライセンス条項に従って許可されています（https://trustee.ietf.org/License-info）。
This version of this YANG module is part of RFC 9061; see the RFC itself for full legal notices.";
このYangモジュールのこのバージョンはRFC 9061の一部です。完全な法的通知のためのRFC自体を見てください。」
revision 2021-07-14 {
description
"Initial version.";
reference
"RFC 9061: A YANG Data Model for IPsec Flow Protection
Based on Software-Defined Networking (SDN).";
}
typedef encr-alg-t {
type uint16;
description
"The encryption algorithm is specified with a 16-bit
number extracted from the IANA registry. The acceptable
values MUST follow the requirement levels for
encryption algorithms for ESP and IKEv2.";
reference
"IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
IKEv2 Transform Attribute Types, Transform Type 1 -
Encryption Algorithm Transform IDs
RFC 8221: Cryptographic Algorithm Implementation
Requirements and Usage Guidance for Encapsulating
Security Payload (ESP) and Authentication Header
(AH)
RFC 8247: Algorithm Implementation Requirements and Usage
Guidance for the Internet Key Exchange Protocol
Version 2 (IKEv2).";
}
typedef intr-alg-t {
type uint16;
description
"The integrity algorithm is specified with a 16-bit
number extracted from the IANA registry.
The acceptable values MUST follow the requirement
levels for integrity algorithms for ESP and IKEv2.";
reference
"IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
IKEv2 Transform Attribute Types, Transform Type 3 -
Integrity Algorithm Transform IDs
RFC 8221: Cryptographic Algorithm Implementation
Requirements and Usage Guidance for Encapsulating
Security Payload (ESP) and Authentication Header
(AH)
RFC 8247: Algorithm Implementation Requirements and Usage
Guidance for the Internet Key Exchange Protocol
Version 2 (IKEv2).";
}
typedef ipsec-mode {
type enumeration {
enum transport {
description
"IPsec transport mode. No Network Address
Translation (NAT) support.";
}
enum tunnel {
description
"IPsec tunnel mode.";
}
}
description
"Type definition of IPsec mode: transport or
tunnel.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 3.2.";
}
typedef esp-encap {
type enumeration {
enum espintcp {
description
"ESP in TCP encapsulation.";
reference
"RFC 8229: TCP Encapsulation of IKE and
IPsec Packets.";
}
enum espinudp {
description
"ESP in UDP encapsulation.";
reference
"RFC 3948: UDP Encapsulation of IPsec ESP
Packets.";
}
enum none {
description
"No ESP encapsulation.";
}
}
description
"Types of ESP encapsulation when Network Address
Translation (NAT) may be present between two NSFs.";
reference
"RFC 8229: TCP Encapsulation of IKE and IPsec Packets
RFC 3948: UDP Encapsulation of IPsec ESP Packets.";
}
typedef ipsec-protocol-params {
type enumeration {
enum esp {
description
"IPsec ESP protocol.";
}
}
description
"Only the Encapsulation Security Protocol (ESP) is
supported, but it could be extended in the future.";
reference
"RFC 4303: IP Encapsulating Security Payload (ESP).";
}
typedef lifetime-action {
type enumeration {
enum terminate-clear {
description
"Terminates the IPsec SA and allows the
packets through.";
}
enum terminate-hold {
description
"Terminates the IPsec SA and drops the
packets.";
}
enum replace {
description
"Replaces the IPsec SA with a new one:
rekey.";
}
}
description
"When the lifetime of an IPsec SA expires, an action
needs to be performed for the IPsec SA that
reached the lifetime. There are three possible
options: terminate-clear, terminate-hold, and
replace.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.5.";
}
typedef ipsec-traffic-direction {
type enumeration {
enum inbound {
description
"Inbound traffic.";
}
enum outbound {
description
"Outbound traffic.";
}
}
description
"IPsec traffic direction is defined in
two directions: inbound and outbound.
From an NSF perspective, inbound and
outbound are defined as mentioned
in Section 3.1 in RFC 4301.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 3.1.";
}
typedef ipsec-spd-action {
type enumeration {
enum protect {
description
"PROTECT the traffic with IPsec.";
}
enum bypass {
description
"BYPASS the traffic. The packet is forwarded
without IPsec protection.";
}
enum discard {
description
"DISCARD the traffic. The IP packet is
discarded.";
}
}
description
"The action when traffic matches an IPsec security
policy. According to RFC 4301, there are three
possible values: BYPASS, PROTECT, and DISCARD.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.";
}
typedef ipsec-inner-protocol {
type union {
type uint8;
type enumeration {
enum any {
value 256;
description
"Any IP protocol number value.";
}
}
}
default "any";
description
"IPsec protection can be applied to specific IP
traffic and Layer 4 traffic (TCP, UDP, SCTP, etc.)
or ANY protocol in the IP packet payload.
The IP protocol number is specified with a uint8
or ANY defining an enumerate with value 256 to
indicate the protocol number. Note that in case
of IPv6, the protocol in the IP packet payload
is indicated in the Next Header field of the IPv6
packet.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.1
IANA: Protocol Numbers.";
}
grouping encap {
description
"This group of nodes allows defining of the type of
encapsulation in case NAT traversal is
required and includes port information.";
leaf espencap {
type esp-encap;
default "none";
description
"ESP in TCP, ESP in UDP, or ESP in TLS.";
}
leaf sport {
type inet:port-number;
default "4500";
description
"Encapsulation source port.";
}
leaf dport {
type inet:port-number;
default "4500";
description
"Encapsulation destination port.";
}
leaf-list oaddr {
type inet:ip-address;
description
"If required, this is the original address that
was used before NAT was applied over the packet.";
}
reference
"RFC 3947: Negotiation of NAT-Traversal in the IKE
RFC 8229: TCP Encapsulation of IKE and IPsec Packets.";
}
grouping lifetime {
description
"Different lifetime values limited to an IPsec SA.";
leaf time {
type uint32;
units "seconds";
default "0";
description
"Time in seconds since the IPsec SA was added.
For example, if this value is 180 seconds, it
means the IPsec SA expires in 180 seconds since
it was added. The value 0 implies infinite.";
}
leaf bytes {
type uint64;
default "0";
description
"If the IPsec SA processes the number of bytes
expressed in this leaf, the IPsec SA expires and
SHOULD be rekeyed. The value 0 implies
infinite.";
}
leaf packets {
type uint32;
default "0";
description
"If the IPsec SA processes the number of packets
expressed in this leaf, the IPsec SA expires and
SHOULD be rekeyed. The value 0 implies
infinite.";
}
leaf idle {
type uint32;
units "seconds";
default "0";
description
"When an NSF stores an IPsec SA, it
consumes system resources. For an idle IPsec SA, this
is a waste of resources. If the IPsec SA is idle
during this number of seconds, the IPsec SA
SHOULD be removed. The value 0 implies
infinite.";
}
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.2.1.";
}
grouping port-range {
description
"This grouping defines a port range, such as that
expressed in RFC 4301, for example, 1500 (Start
Port Number)-1600 (End Port Number).
A port range is used in the Traffic Selector.";
leaf start {
type inet:port-number;
description
"Start port number.";
}
leaf end {
type inet:port-number;
must '. >= ../start' {
error-message
"The end port number MUST be equal or greater
than the start port number.";
}
description
"End port number. To express a single port, set
the same value as start and end.";
}
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.2.";
}
grouping tunnel-grouping {
description
"The parameters required to define the IP tunnel
endpoints when IPsec SA requires tunnel mode. The
tunnel is defined by two endpoints: the local IP
address and the remote IP address.";
leaf local {
type inet:ip-address;
mandatory true;
description
"Local IP address' tunnel endpoint.";
}
leaf remote {
type inet:ip-address;
mandatory true;
description
"Remote IP address' tunnel endpoint.";
}
leaf df-bit {
type enumeration {
enum clear {
description
"Disable the Don't Fragment (DF) bit
in the outer header. This is the
default value.";
}
enum set {
description
"Enable the DF bit in the outer header.";
}
enum copy {
description
"Copy the DF bit to the outer header.";
}
}
default "clear";
description
"Allow configuring the DF bit when encapsulating
tunnel mode IPsec traffic. RFC 4301 describes
three options to handle the DF bit during
tunnel encapsulation: clear, set, and copy from
the inner IP header. This MUST be ignored or
has no meaning when the local/remote
IP addresses are IPv6 addresses.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 8.1.";
}
leaf bypass-dscp {
type boolean;
default "true";
description
"If true, to copy the Differentiated Services Code
Point (DSCP) value from inner header to outer header.
If false, to map DSCP values
from an inner header to values in an outer header
following ../dscp-mapping.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.2.";
}
list dscp-mapping {
must '../bypass-dscp = "false"';
key "id";
ordered-by user;
leaf id {
type uint8;
description
"The index of list with the
different mappings.";
}
leaf inner-dscp {
type inet:dscp;
description
"The DSCP value of the inner IP packet. If this
leaf is not defined, it means ANY inner DSCP value.";
}
leaf outer-dscp {
type inet:dscp;
default "0";
description
"The DSCP value of the outer IP packet.";
}
description
"A list that represents an array with the mapping from the
inner DSCP value to outer DSCP value when bypass-dscp is
false. To express a default mapping in the list where any
other inner dscp value is not matching a node in the list,
a new node has to be included at the end of the list where
the leaf inner-dscp is not defined (ANY) and the leaf
outer-dscp includes the value of the mapping. If there is
no value set in the leaf outer-dscp, the default value for
this leaf is 0.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.2 and Appendix C.";
}
}
grouping selector-grouping {
description
"This grouping contains the definition of a Traffic
Selector, which is used in the IPsec policies and
IPsec SAs.";
leaf local-prefix {
type inet:ip-prefix;
mandatory true;
description
"Local IP address prefix.";
}
leaf remote-prefix {
type inet:ip-prefix;
mandatory true;
description
"Remote IP address prefix.";
}
leaf inner-protocol {
type ipsec-inner-protocol;
default "any";
description
"Inner protocol that is going to be
protected with IPsec.";
}
list local-ports {
key "start end";
uses port-range;
description
"List of local ports. When the inner
protocol is ICMP, this 16-bit value
represents code and type.
If this list is not defined,
it is assumed that start and
end are 0 by default (any port).";
}
list remote-ports {
key "start end";
uses port-range;
description
"List of remote ports. When the upper layer
protocol is ICMP, this 16-bit value represents
code and type. If this list is not defined,
it is assumed that start and end are 0 by
default (any port).";
}
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.2.";
}
grouping ipsec-policy-grouping {
description
"Holds configuration information for an IPsec SPD
entry.";
leaf anti-replay-window-size {
type uint32;
default "64";
description
"To set the anti-replay window size.
The default value is set
to 64, following the recommendation in RFC 4303.";
reference
"RFC 4303: IP Encapsulating Security Payload (ESP),
Section 3.4.3.";
}
container traffic-selector {
description
"Packets are selected for
processing actions based on Traffic Selector
values, which refer to IP and inner protocol
header information.";
uses selector-grouping;
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.4.1.";
}
container processing-info {
description
"SPD processing. If the required processing
action is protect, it contains the required
information to process the packet.";
leaf action {
type ipsec-spd-action;
default "discard";
description
"If bypass or discard, container
ipsec-sa-cfg is empty.";
}
container ipsec-sa-cfg {
when "../action = 'protect'";
description
"IPsec SA configuration included in the SPD
entry.";
leaf pfp-flag {
type boolean;
default "false";
description
"Each selector has a Populate From
Packet (PFP) flag. If asserted for a
given selector X, the flag indicates
that the IPsec SA to be created should
take its value (local IP address,
remote IP address, Next Layer
Protocol, etc.) for X from the value
in the packet. Otherwise, the IPsec SA
should take its value(s) for X from
the value(s) in the SPD entry.";
}
leaf ext-seq-num {
type boolean;
default "false";
description
"True if this IPsec SA is using extended
sequence numbers. If true, the 64-bit
extended sequence number counter is used;
if false, the normal 32-bit sequence
number counter is used.";
}
leaf seq-overflow {
type boolean;
default "false";
description
"The flag indicating whether
overflow of the sequence number
counter should prevent transmission
of additional packets on the IPsec
SA (false) and, therefore, needs to
be rekeyed or whether rollover is
permitted (true). If Authenticated
Encryption with Associated Data
(AEAD) is used (leaf
esp-algorithms/encryption/algorithm-type),
this flag MUST be false. Setting this
flag to true is strongly discouraged.";
}
leaf stateful-frag-check {
type boolean;
default "false";
description
"Indicates whether (true) or not (false)
stateful fragment checking applies to
the IPsec SA to be created.";
}
leaf mode {
type ipsec-mode;
default "transport";
description
"IPsec SA has to be processed in
transport or tunnel mode.";
}
leaf protocol-parameters {
type ipsec-protocol-params;
default "esp";
description
"Security protocol of the IPsec SA.
Only ESP is supported, but it could be
extended in the future.";
}
container esp-algorithms {
when "../protocol-parameters = 'esp'";
description
"Configuration of Encapsulating
Security Payload (ESP) parameters and
algorithms.";
leaf-list integrity {
type intr-alg-t;
default "0";
ordered-by user;
description
"Configuration of ESP authentication
based on the specified integrity
algorithm. With AEAD encryption
algorithms, the integrity node is
not used.";
reference
"RFC 4303: IP Encapsulating Security Payload (ESP),
Section 3.2.";
}
list encryption {
key "id";
ordered-by user;
leaf id {
type uint16;
description
"An identifier that unequivocally identifies each
entry of the list, i.e., an encryption algorithm
and its key length (if required).";
}
leaf algorithm-type {
type encr-alg-t;
default "20";
description
"Default value 20 (ENCR_AES_GCM_16).";
}
leaf key-length {
type uint16;
default "128";
description
"By default, key length is 128
bits.";
}
description
"Encryption or AEAD algorithm for the
IPsec SAs. This list is ordered
following from the higher priority to
lower priority. First node of the
list will be the algorithm with
higher priority. In case the list
is empty, then no encryption algorithm
is applied (NULL).";
reference
"RFC 4303: IP Encapsulating Security Payload (ESP),
Section 3.2.";
}
leaf tfc-pad {
type boolean;
default "false";
description
"If Traffic Flow Confidentiality
(TFC) padding for ESP encryption
can be used (true) or not (false).";
reference
"RFC 4303: IP Encapsulating Security Payload (ESP),
Section 2.7.";
}
reference
"RFC 4303: IP Encapsulating Security Payload (ESP).";
}
container tunnel {
when "../mode = 'tunnel'";
uses tunnel-grouping;
description
"IPsec tunnel endpoints definition.";
}
}
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.2.";
}
}
}
<CODE ENDS>
In this section, the YANG module for the IKE case is described.
このセクションでは、IKEケースのYANGモジュールについて説明します。
The model related to IKEv2 has been extracted from reading the IKEv2 standard in [RFC7296] and observing some open source implementations, such as strongSwan [strongswan] or Libreswan [libreswan].
IKEV2に関するモデルは、[RFC7296]のIKEV2規格の読み取りから抽出され、StrongSwan [Strongswan]またはLibreSwan [LibreSwan]などのいくつかのオープンソース実装を観察しました。
The definition of the PAD model has been extracted from the specification in Section 4.4.3 of [RFC4301]. (Note that many implementations integrate PAD configuration as part of the IKEv2 configuration.)
PADモデルの定義は、[RFC4301]の4.4.3項の仕様から抽出されました。（多くの実装は、PAD設定をIKEv2構成の一部として統合しています。）
The definition of the SPD model has been mainly extracted from the specification in Section 4.4.1 and Appendix D of [RFC4301].
SPDモデルの定義は主にセクション4.4.1および[RFC4301]の付録Dの仕様から抽出されています。
The YANG data model for the IKE case is defined by the module "ietf-i2nsf-ike". Its structure is depicted in the following diagram, using the notation syntax for YANG tree diagrams [RFC8340].
IKEケースのYangデータモデルは、モジュール "IETF-I2NSF-IKE"によって定義されています。その構造は、Yangツリー図の表記の構文を使用して、次の図に示されています[RFC8340]。
module: ietf-i2nsf-ike
+--rw ipsec-ike
+--rw pad
| +--rw pad-entry* [name]
| +--rw name string
| +--rw (identity)
| | +--:(ipv4-address)
| | | +--rw ipv4-address? inet:ipv4-address
| | +--:(ipv6-address)
| | | +--rw ipv6-address? inet:ipv6-address
| | +--:(fqdn-string)
| | | +--rw fqdn-string? inet:domain-name
| | +--:(rfc822-address-string)
| | | +--rw rfc822-address-string? string
| | +--:(dnx509)
| | | +--rw dnx509? binary
| | +--:(gnx509)
| | | +--rw gnx509? binary
| | +--:(id-key)
| | | +--rw id-key? binary
| | +--:(id-null)
| | +--rw id-null? empty
| +--rw auth-protocol? auth-protocol-type
| +--rw peer-authentication
| +--rw auth-method? auth-method-type
| +--rw eap-method
| | +--rw eap-type uint64
| +--rw pre-shared
| | +--rw secret? yang:hex-string
| +--rw digital-signature
| +--rw ds-algorithm? uint8
| +--rw (public-key)?
| | +--:(raw-public-key)
| | | +--rw raw-public-key? binary
| | +--:(cert-data)
| | +--rw cert-data? binary
| +--rw private-key? binary
| +--rw ca-data* binary
| +--rw crl-data? binary
| +--rw crl-uri? inet:uri
| +--rw oscp-uri? inet:uri
+--rw conn-entry* [name]
| +--rw name string
| +--rw autostartup? autostartup-type
| +--rw initial-contact? boolean
| +--rw version? auth-protocol-type
| +--rw fragmentation
| | +--rw enabled? boolean
| | +--rw mtu? uint16
| +--rw ike-sa-lifetime-soft
| | +--rw rekey-time? uint32
| | +--rw reauth-time? uint32
| +--rw ike-sa-lifetime-hard
| | +--rw over-time? uint32
| +--rw ike-sa-intr-alg* nsfikec:intr-alg-t
| +--rw ike-sa-encr-alg* [id]
| | +--rw id uint16
| | +--rw algorithm-type? nsfikec:encr-alg-t
| | +--rw key-length? uint16
| +--rw dh-group? fs-group
| +--rw half-open-ike-sa-timer? uint32
| +--rw half-open-ike-sa-cookie-threshold? uint32
| +--rw local
| | +--rw local-pad-entry-name string
| +--rw remote
| | +--rw remote-pad-entry-name string
| +--rw encapsulation-type
| | +--rw espencap? esp-encap
| | +--rw sport? inet:port-number
| | +--rw dport? inet:port-number
| | +--rw oaddr* inet:ip-address
| +--rw spd
| | +--rw spd-entry* [name]
| | +--rw name string
| | +--rw ipsec-policy-config
| | +--rw anti-replay-window-size? uint32
| | +--rw traffic-selector
| | | +--rw local-prefix inet:ip-prefix
| | | +--rw remote-prefix inet:ip-prefix
| | | +--rw inner-protocol? ipsec-inner-protocol
| | | +--rw local-ports* [start end]
| | | | +--rw start inet:port-number
| | | | +--rw end inet:port-number
| | | +--rw remote-ports* [start end]
| | | +--rw start inet:port-number
| | | +--rw end inet:port-number
| | +--rw processing-info
| | +--rw action? ipsec-spd-action
| | +--rw ipsec-sa-cfg
| | +--rw pfp-flag? boolean
| | +--rw ext-seq-num? boolean
| | +--rw seq-overflow? boolean
| | +--rw stateful-frag-check? boolean
| | +--rw mode? ipsec-mode
| | +--rw protocol-parameters? ipsec-protocol-params
| | +--rw esp-algorithms
| | | +--rw integrity* intr-alg-t
| | | +--rw encryption* [id]
| | | | +--rw id uint16
| | | | +--rw algorithm-type? encr-alg-t
| | | | +--rw key-length? uint16
| | | +--rw tfc-pad? boolean
| | +--rw tunnel
| | +--rw local inet:ip-address
| | +--rw remote inet:ip-address
| | +--rw df-bit? enumeration
| | +--rw bypass-dscp? boolean
| | +--rw dscp-mapping* [id]
| | +--rw id uint8
| | +--rw inner-dscp? inet:dscp
| | +--rw outer-dscp? inet:dscp
| +--rw child-sa-info
| | +--rw fs-groups* fs-group
| | +--rw child-sa-lifetime-soft
| | | +--rw time? uint32
| | | +--rw bytes? yang:counter64
| | | +--rw packets? uint32
| | | +--rw idle? uint32
| | | +--rw action? nsfikec:lifetime-action
| | +--rw child-sa-lifetime-hard
| | +--rw time? uint32
| | +--rw bytes? yang:counter64
| | +--rw packets? uint32
| | +--rw idle? uint32
| +--ro state
| +--ro initiator? boolean
| +--ro initiator-ikesa-spi? ike-spi
| +--ro responder-ikesa-spi? ike-spi
| +--ro nat-local? boolean
| +--ro nat-remote? boolean
| +--ro encapsulation-type
| | +--ro espencap? esp-encap
| | +--ro sport? inet:port-number
| | +--ro dport? inet:port-number
| | +--ro oaddr* inet:ip-address
| +--ro established? uint64
| +--ro current-rekey-time? uint64
| +--ro current-reauth-time? uint64
+--ro number-ike-sas
+--ro total? yang:gauge64
+--ro half-open? yang:gauge64
+--ro half-open-cookies? yang:gauge64
The YANG data model consists of a unique "ipsec-ike" container defined as follows. Firstly, it contains a "pad" container that serves to configure the Peer Authentication Database with authentication information about local and remote peers (NSFs). More precisely, it consists of a list of entries, each one indicating the identity, authentication method, and credentials that a particular peer (local or remote) will use. Therefore, each entry contains identity, authentication information, and credentials of either the local NSF or the remote NSF. As a consequence, the I2NF Controller can store identity, authentication information, and credentials for the local NSF and the remote NSF.
Yangデータモデルは、次のように定義された固有の「IPSec-IKE」コンテナで構成されています。まず、ローカルピアとリモートピア（NSFS）に関する認証情報を使用してピア認証データベースを設定するのに役立つ「パッド」コンテナが含まれています。より正確には、それはエントリのリストからなり、それぞれが特定のピア（ローカルまたはリモート）が使用するID、認証方法、および認証情報を示すもの。したがって、各エントリには、識別情報、認証情報、およびローカルNSFまたはリモートNSFのいずれかの認証情報が含まれています。結果として、I2NFコントローラは、ローカルNSFとリモートNSFの識別情報、認証情報、および資格情報を格納できます。
Next, a list "conn-entry" is defined with information about the different IKE connections a peer can maintain with others. Each connection entry is composed of a wide number of parameters to configure different aspects of a particular IKE connection between two peers: local and remote peer authentication information, IKE SA configuration (soft and hard lifetimes, cryptographic algorithms, etc.), a list of IPsec policies describing the type of network traffic to be secured (local/remote subnet and ports, etc.) and how it must be protected (ESP, tunnel/transport, cryptographic algorithms, etc.), Child SA configuration (soft and hard lifetimes), and state information of the IKE connection (SPIs, usage of NAT, current expiration times, etc.).
次に、「conn-entry」のリストが異なるIKE接続に関する情報で定義され、ピアは他のものと維持できます。各接続エントリは、2つのピア間の特定のIKE接続の異なる側面を構成するための広い数のパラメータで構成されています。ローカルおよびリモートピア認証情報、IKE SAの設定（ソフトとハードライフタイム、暗号化アルゴリズムなど）、リスト保護されるネットワークトラフィックの種類（ローカル/リモートサブネットおよびポートなど）を説明するIPSecポリシー（ESP、トンネル/トランスポート、暗号化アルゴリズムなど）、Child SAの設定（柔らかくてハードの寿命）（SPI、NATの使用、現在の有効期限など）、およびIKE接続の状態情報（SPI）。
Lastly, the "ipsec-ike" container declares a "number-ike-sas" container to specify state information reported by the IKE software related to the amount of IKE connections established.
最後に、「IPSEC-IKE」コンテナは、「Number-IKE-SAS」コンテナを宣言して、確立されたIKE接続の量に関連するIKEソフトウェアによって報告された状態情報を指定します。
Appendix A shows an example of IKE case configuration for an NSF, in tunnel mode (gateway-to-gateway), with NSF authentication based on X.509 certificates.
付録Aは、Tunnel Mode（Gateway-to-Gateway）のNSFの場合のIKEケース構成の例を示し、NSF認証はX.509証明書に基づいています。
This YANG module has normative references to [RFC5280], [RFC4301],
[RFC5915], [RFC6991], [RFC7296], [RFC7383], [RFC7427], [RFC7619],
[RFC8017], [ITU-T.X.690], [RFC5322], [RFC8229], [RFC8174], [RFC6960],
[IKEv2-Auth-Method], [IKEv2-Transform-Type-4], [IKEv2-Parameters],
and [IANA-Method-Type].
<CODE BEGINS> file "ietf-i2nsf-ike@2021-07-14.yang"
module ietf-i2nsf-ike {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike";
prefix nsfike;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types.";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types.";
}
import ietf-i2nsf-ikec {
prefix nsfikec;
reference
"RFC 9061: A YANG Data Model for IPsec Flow Protection
Based on Software-Defined Networking (SDN).";
}
import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control
Model.";
}
organization
"IETF I2NSF Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/>
WG List: <mailto:i2nsf@ietf.org>
Author: Rafael Marin-Lopez
<mailto:rafa@um.es>
Author: Gabriel Lopez-Millan
<mailto:gabilm@um.es>
Author: Fernando Pereniguez-Garcia <mailto:fernando.pereniguez@cud.upct.es> "; description "This module contains the IPsec IKE case model for the SDN-based IPsec flow protection service.
著者：Fernando Pereniguez-Garcia <mailto：fernando.pereniguez@cud.upct.es> ";説明"このモジュールには、SDNベースのIPSecフロー保護サービスのIPSec IKEケースモデルが含まれています。
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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here.
キーワードは「必須」、「必須」、「shall」、「shall '、'は '、'は '、'推奨 '、'推奨されていない '、' may '、'任意のものではありません。'この文書では、ここに示すように、BCP 14（RFC 2119）（RFC 8174）に記載されているように解釈されるべきです。
Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（c）2021 IETF信頼とコードの著者として識別された人。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
修正の有無にかかわらず、ソースおよびバイナリ形式での再配布と使用は、IETF文書に関連するIETF信託の法的規定のセクション4.Cに記載されている単純化されたBSDライセンスに従い、身に付けられたライセンス条項に従って許可されています（http://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 9061; see the RFC itself for full legal notices.";
このYangモジュールのこのバージョンはRFC 9061の一部です。完全な法的通知のためのRFC自体を見てください。」
revision 2021-07-14 {
description
"Initial version.";
reference
"RFC 9061: A YANG Data Model for IPsec Flow Protection
Based on Software-Defined Networking (SDN).";
}
typedef ike-spi {
type uint64 {
range "0..max";
}
description
"Security Parameter Index (SPI)'s IKE SA.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.6.";
}
typedef autostartup-type {
type enumeration {
enum add {
description
"IKE/IPsec configuration is only loaded into
IKE implementation, but IKE/IPsec SA is not
started.";
}
enum on-demand {
description
"IKE/IPsec configuration is loaded
into IKE implementation. The IPsec policies
are transferred to the NSF, but the
IPsec SAs are not established immediately.
The IKE implementation will negotiate the
IPsec SAs when they are required
(i.e., through an ACQUIRE notification).";
}
enum start {
description
"IKE/IPsec configuration is loaded
and transferred to the NSF's kernel, and the
IKEv2-based IPsec SAs are established
immediately without waiting for any packet.";
}
}
description
"Different policies to set IPsec SA configuration
into NSF's kernel when IKEv2 implementation has
started.";
}
typedef fs-group {
type uint16;
description
"DH groups for IKE and IPsec SA rekey.";
reference
"IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
IKEv2 Transform Attribute Types, Transform Type 4 -
Diffie-Hellman Group Transform IDs
RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 3.3.2.";
}
typedef auth-protocol-type {
type enumeration {
enum ikev2 {
value 2;
description
"IKEv2 authentication protocol. It is the
only one defined right now. An enum is
used for further extensibility.";
}
}
description
"IKE authentication protocol version specified in the
Peer Authorization Database (PAD). It is defined as
enumerated to allow new IKE versions in the
future.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2).";
}
typedef auth-method-type {
type enumeration {
enum pre-shared {
description
"Select pre-shared key as the
authentication method.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2).";
}
enum eap {
description
"Select the Extensible Authentication Protocol (EAP) as
the authentication method.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2).";
}
enum digital-signature {
description
"Select digital signature as the authentication method.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2)
RFC 7427: Signature Authentication in the Internet Key
Exchange Version 2 (IKEv2).";
}
enum null {
description
"Null authentication.";
reference
"RFC 7619: The NULL Authentication Method in the Internet
Key Exchange Protocol Version 2 (IKEv2).";
}
}
description
"Peer authentication method specified in the Peer
Authorization Database (PAD).";
}
container ipsec-ike {
description
"IKE configuration for an NSF. It includes PAD
parameters, IKE connection information, and state
data.";
container pad {
description
"Configuration of the Peer Authorization Database
(PAD). Each entry of PAD contains authentication
information of either the local peer or the remote peer.
Therefore, the I2NSF Controller stores authentication
information (and credentials) not only for the remote NSF
but also for the local NSF. The local NSF MAY use the
same identity for different types of authentication
and credentials. Pointing to the entry for a local NSF
(e.g., A) and the entry for remote NSF (e.g., B)
is possible to specify all the required information to
carry out the authentication between A and B (see
../conn-entry/local and ../conn-entry/remote).";
list pad-entry {
key "name";
ordered-by user;
description
"Peer Authorization Database (PAD) entry. It
is a list of PAD entries ordered by the
I2NSF Controller, and each entry is
unequivocally identified by a name.";
leaf name {
type string;
description
"PAD-unique name to identify this
entry.";
}
choice identity {
mandatory true;
description
"A particular IKE peer will be
identified by one of these identities.
This peer can be a remote peer or local
peer (this NSF).";
reference
"RFC 4301: Security Architecture for the Internet
Protocol, Section 4.4.3.1.";
case ipv4-address {
leaf ipv4-address {
type inet:ipv4-address;
description
"Specifies the identity as
a single 4-octet IPv4 address.";
}
}
case ipv6-address {
leaf ipv6-address {
type inet:ipv6-address;
description
"Specifies the identity as a
single 16-octet IPv6
address. An example is
2001:db8::8:800:200c:417a.";
}
}
case fqdn-string {
leaf fqdn-string {
type inet:domain-name;
description
"Specifies the identity as a
Fully Qualified Domain Name
(FQDN) string. An example is
example.com. The string MUST
NOT contain any terminators
(e.g., NULL, Carriage Return
(CR), etc.).";
}
}
case rfc822-address-string {
leaf rfc822-address-string {
type string;
description
"Specifies the identity as a
fully qualified email address
string (RFC 5322). An example is
jsmith@example.com. The string
MUST NOT contain any
terminators (e.g., NULL, CR,
etc.).";
reference
"RFC 5322: Internet Message Format.";
}
}
case dnx509 {
leaf dnx509 {
type binary;
description
"The binary
Distinguished Encoding Rules (DER)
encoding of an ASN.1 X.500
Distinguished Name, as specified in IKEv2.";
reference
"RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation
List (CRL) Profile
RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 3.5.";
}
}
case gnx509 {
leaf gnx509 {
type binary;
description
"ASN.1 X.509 GeneralName structure,
as specified in RFC 5280, encoded
using ASN.1 Distinguished Encoding Rules
(DER), as specified in ITU-T X.690.";
reference
"RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation
List (CRL) Profile.";
}
}
case id-key {
leaf id-key {
type binary;
description
"Opaque octet stream that may be
used to pass vendor-specific
information for proprietary
types of identification.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 3.5.";
}
}
case id-null {
leaf id-null {
type empty;
description
"The ID_NULL identification is used
when the IKE identification payload
is not used.";
reference
"RFC 7619: The NULL Authentication Method in the
Internet Key Exchange Protocol Version 2
(IKEv2).";
}
}
}
leaf auth-protocol {
type auth-protocol-type;
default "ikev2";
description
"Only IKEv2 is supported right now, but
other authentication protocols may be
supported in the future.";
}
container peer-authentication {
description
"This container allows the security
controller to configure the
authentication method (pre-shared key,
eap, digital-signature, null) that
will be used with a particular peer and
the credentials to use, which will
depend on the selected authentication
method.";
leaf auth-method {
type auth-method-type;
default "pre-shared";
description
"Type of authentication method
(pre-shared key, eap, digital signature,
null).";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.15.";
}
container eap-method {
when "../auth-method = 'eap'";
leaf eap-type {
type uint32 {
range "1 .. 4294967295";
}
mandatory true;
description
"EAP method type specified with
a value extracted from the
IANA registry. This
information provides the
particular EAP method to be
used. Depending on the EAP
method, pre-shared keys or
certificates may be used.";
}
description
"EAP method description used when
authentication method is 'eap'.";
reference
"IANA: Extensible Authentication Protocol (EAP)
Registry, Method Types
RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.16.";
}
container pre-shared {
when "../auth-method[.='pre-shared' or
.='eap']";
leaf secret {
nacm:default-deny-all;
type yang:hex-string;
description
"Pre-shared secret value. The
NSF has to prevent read access
to this value for security
reasons. This value MUST be
set if the EAP method uses a
pre-shared key or pre-shared
authentication has been chosen.";
}
description
"Shared secret value for PSK or
EAP method authentication based on
PSK.";
}
container digital-signature {
when "../auth-method[.='digital-signature'
or .='eap']";
leaf ds-algorithm {
type uint8;
default "14";
description
"The digital signature
algorithm is specified with a
value extracted from the IANA
registry. Default is the generic
digital signature method. Depending
on the algorithm, the following leafs
MUST contain information. For
example, if digital signature or the
EAP method involves a certificate,
then leaves 'cert-data' and 'private-key'
will contain this information.";
reference
"IANA: Internet Key Exchange Version 2 (IKEv2)
Parameters, IKEv2 Authentication Method.";
}
choice public-key {
leaf raw-public-key {
type binary;
description
"A binary that contains the
value of the public key. The
interpretation of the content
is defined by the digital
signature algorithm. For
example, an RSA key is
represented as RSAPublicKey, as
defined in RFC 8017, and an
Elliptic Curve Cryptography
(ECC) key is represented
using the 'publicKey'
described in RFC 5915.";
reference
"RFC 5915: Elliptic Curve Private Key
Structure
RFC 8017: PKCS #1: RSA Cryptography
Specifications Version 2.2.";
}
leaf cert-data {
type binary;
description
"X.509 certificate data in DER
format. If raw-public-key is
defined, this leaf is empty.";
reference
"RFC 5280: Internet X.509 Public Key
Infrastructure Certificate
and Certificate Revocation
List (CRL) Profile.";
}
description
"If the I2NSF Controller
knows that the NSF
already owns a private key
associated to this public key
(e.g., the NSF generated the pair
public key/private key out of
band), it will only configure
one of the leaves of this
choice but not the leaf
private-key. The NSF, based on
the public key value, can know
the private key to be used.";
}
leaf private-key {
nacm:default-deny-all;
type binary;
description
"A binary that contains the
value of the private key. The
interpretation of the content
is defined by the digital
signature algorithm. For
example, an RSA key is
represented as RSAPrivateKey, as
defined in RFC 8017, and an
Elliptic Curve Cryptography
(ECC) key is represented as
ECPrivateKey, as defined in RFC
5915. This value is set
if public key is defined and the
I2NSF Controller is in charge
of configuring the
private key. Otherwise, it is
not set and the value is
kept in secret.";
reference
"RFC 5915: Elliptic Curve Private Key
Structure
RFC 8017: PKCS #1: RSA Cryptography
Specifications Version 2.2.";
}
leaf-list ca-data {
type binary;
description
"List of trusted Certification
Authorities (CAs) certificates
encoded using ASN.1
Distinguished Encoding Rules
(DER). If it is not defined,
the default value is empty.";
}
leaf crl-data {
type binary;
description
"A CertificateList structure, as
specified in RFC 5280,
encoded using ASN.1
Distinguished Encoding Rules
(DER), as specified in ITU-T
X.690. If it is not defined,
the default value is empty.";
reference
"RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation
List (CRL) Profile.";
}
leaf crl-uri {
type inet:uri;
description
"X.509 Certificate Revocation List
(CRL) certificate URI.
If it is not defined,
the default value is empty.";
reference
"RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation
List (CRL) Profile.";
}
leaf oscp-uri {
type inet:uri;
description
"Online Certificate Status Protocol
(OCSP) URI. If it is not defined,
the default value is empty.";
reference
"RFC 6960: X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation
List (CRL) Profile.";
}
description
"digital-signature container.";
} /*container digital-signature*/
} /*container peer-authentication*/
}
}
list conn-entry {
key "name";
description
"IKE peer connection information. This list
contains the IKE connection for this peer
with other peers. This will create, in
real time, IKE Security Associations
established with these nodes.";
leaf name {
type string;
description
"Identifier for this connection
entry.";
}
leaf autostartup {
type autostartup-type;
default "add";
description
"By default, only add configuration
without starting the security
association.";
}
leaf initial-contact {
type boolean;
default "false";
description
"The goal of this value is to deactivate the
usage of INITIAL_CONTACT notification
(true). If this flag remains set to false, it
means the usage of the INITIAL_CONTACT
notification will depend on the IKEv2
implementation.";
}
leaf version {
type auth-protocol-type;
default "ikev2";
description
"IKE version. Only version 2 is supported.";
}
container fragmentation {
leaf enabled {
type boolean;
default "false";
description
"Whether or not to enable IKEv2
fragmentation (true or false).";
reference
"RFC 7383: Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation.";
}
leaf mtu {
when "../enabled='true'";
type uint16 {
range "68..65535";
}
description
"MTU that IKEv2 can use
for IKEv2 fragmentation.";
reference
"RFC 7383: Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation.";
}
description
"IKEv2 fragmentation, as per RFC 7383. If the
IKEv2 fragmentation is enabled, it is possible
to specify the MTU.";
}
container ike-sa-lifetime-soft {
description
"IKE SA lifetime soft. Two lifetime values
can be configured: either rekey time of the
IKE SA or reauth time of the IKE SA. When
the rekey lifetime expires, a rekey of the
IKE SA starts. When reauth lifetime
expires, an IKE SA reauthentication starts.";
leaf rekey-time {
type uint32;
units "seconds";
default "0";
description
"Time in seconds between each IKE SA
rekey. The value 0 means infinite.";
}
leaf reauth-time {
type uint32;
units "seconds";
default "0";
description
"Time in seconds between each IKE SA
reauthentication. The value 0 means
infinite.";
}
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.8.";
}
container ike-sa-lifetime-hard {
description
"Hard IKE SA lifetime. When this
time is reached, the IKE SA is removed.";
leaf over-time {
type uint32;
units "seconds";
default "0";
description
"Time in seconds before the IKE SA is
removed. The value 0 means infinite.";
}
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2).";
}
leaf-list ike-sa-intr-alg {
type nsfikec:intr-alg-t;
default "12";
ordered-by user;
description
"Integrity algorithm for establishing
the IKE SA. This list is ordered following
from the higher priority to lower priority.
The first node of the list will be the
algorithm with higher priority.
Default value 12 (AUTH_HMAC_SHA2_256_128).";
}
list ike-sa-encr-alg {
key "id";
min-elements 1;
ordered-by user;
leaf id {
type uint16;
description
"An identifier that unequivocally
identifies each entry of the list,
i.e., an encryption algorithm and
its key length (if required).";
}
leaf algorithm-type {
type nsfikec:encr-alg-t;
default "12";
description
"Default value 12 (ENCR_AES_CBC).";
}
leaf key-length {
type uint16;
default "128";
description
"By default, key length is 128 bits.";
}
description
"Encryption or AEAD algorithm for the IKE
SAs. This list is ordered following
from the higher priority to lower priority.
The first node of the list will be the
algorithm with higher priority.";
}
leaf dh-group {
type fs-group;
default "14";
description
"Group number for Diffie-Hellman
Exponentiation used during IKE_SA_INIT
for the IKE SA key exchange.";
}
leaf half-open-ike-sa-timer {
type uint32;
units "seconds";
default "0";
description
"Set the half-open IKE SA timeout
duration. The value 0 implies infinite.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.";
}
leaf half-open-ike-sa-cookie-threshold {
type uint32;
default "0";
description
"Number of half-open IKE SAs that activate
the cookie mechanism. The value 0 implies
infinite.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.6.";
}
container local {
leaf local-pad-entry-name {
type string;
mandatory true;
description
"Local peer authentication information.
This node points to a specific entry in
the PAD where the authorization
information about this particular local
peer is stored. It MUST match a
pad-entry-name.";
}
description
"Local peer authentication information.";
}
container remote {
leaf remote-pad-entry-name {
type string;
mandatory true;
description
"Remote peer authentication information.
This node points to a specific entry in
the PAD where the authorization
information about this particular
remote peer is stored. It MUST match a
pad-entry-name.";
}
description
"Remote peer authentication information.";
}
container encapsulation-type {
uses nsfikec:encap;
description
"This container carries configuration
information about the source and destination
ports of encapsulation that IKE should use
and the type of encapsulation that
should be used when NAT traversal is required.
However, this is just a best effort since
the IKE implementation may need to use a
different encapsulation, as described in
RFC 8229.";
reference
"RFC 8229: TCP Encapsulation of IKE and IPsec
Packets.";
}
container spd {
description
"Configuration of the Security Policy
Database (SPD). This main information is
placed in the grouping
ipsec-policy-grouping.";
list spd-entry {
key "name";
ordered-by user;
leaf name {
type string;
description
"SPD-entry-unique name to identify
the IPsec policy.";
}
container ipsec-policy-config {
description
"This container carries the
configuration of an IPsec policy.";
uses nsfikec:ipsec-policy-grouping;
}
description
"List of entries that will constitute
the representation of the SPD. In this
case, since the NSF implements IKE, it
is only required to send an IPsec policy
from this NSF where 'local' is this NSF
and 'remote' the other NSF. The IKE
implementation will install IPsec
policies in the NSF's kernel in both
directions (inbound and outbound) and
their corresponding IPsec SAs based on
the information in this SPD entry.";
}
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.9.";
}
container child-sa-info {
leaf-list fs-groups {
type fs-group;
default "0";
ordered-by user;
description
"If non-zero, forward secrecy is
required when a new IPsec SA is being
created, the (non-zero) value indicates
the group number to use for the key
exchange process used to achieve forward
secrecy.
This list is ordered following from the
higher priority to lower priority. The
first node of the list will be the
algorithm with higher priority.";
}
container child-sa-lifetime-soft {
description
"Soft IPsec SA lifetime.
After the lifetime, the action is
defined in this container
in the leaf action.";
uses nsfikec:lifetime;
leaf action {
type nsfikec:lifetime-action;
default "replace";
description
"When the lifetime of an IPsec SA
expires, an action needs to be
performed over the IPsec SA that
reached the lifetime. There are
three possible options:
terminate-clear, terminate-hold, and
replace.";
reference
"RFC 4301: Security Architecture for the Internet
Protocol, Section 4.5
RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.8.";
}
}
container child-sa-lifetime-hard {
description
"IPsec SA lifetime hard. The action will
be to terminate the IPsec SA.";
uses nsfikec:lifetime;
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.8.";
}
description
"Specific information for IPsec SAs.
It includes the Perfect Forward Secrecy (PFS)
group and IPsec SAs rekey lifetimes.";
}
container state {
config false;
leaf initiator {
type boolean;
description
"It is acting as an initiator for this
connection.";
}
leaf initiator-ikesa-spi {
type ike-spi;
description
"Initiator's IKE SA SPI.";
}
leaf responder-ikesa-spi {
type ike-spi;
description
"Responder's IKE SA SPI.";
}
leaf nat-local {
type boolean;
description
"True if local endpoint is behind a
NAT.";
}
leaf nat-remote {
type boolean;
description
"True if remote endpoint is behind
a NAT.";
}
container encapsulation-type {
uses nsfikec:encap;
description
"This container provides information
about the source and destination
ports of encapsulation that IKE is
using and the type of encapsulation
when NAT traversal is required.";
reference
"RFC 8229: TCP Encapsulation of IKE and IPsec Packets.";
}
leaf established {
type uint64;
units "seconds";
description
"Seconds since this IKE SA has been
established.";
}
leaf current-rekey-time {
type uint64;
units "seconds";
description
"Seconds before IKE SA is rekeyed.";
}
leaf current-reauth-time {
type uint64;
units "seconds";
description
"Seconds before IKE SA is
reauthenticated.";
}
description
"IKE state data for a particular
connection.";
} /* ike-sa-state */
} /* ike-conn-entries */
container number-ike-sas {
config false;
leaf total {
type yang:gauge64;
description
"Total number of active IKE SAs.";
}
leaf half-open {
type yang:gauge64;
description
"Number of half-open active IKE SAs.";
}
leaf half-open-cookies {
type yang:gauge64;
description
"Number of half-open active IKE SAs with
cookie activated.";
}
description
"General information about the IKE SAs. In
particular, it provides the current number of
IKE SAs.";
}
} /* container ipsec-ike */
}
<CODE ENDS>
In this section, the YANG module for the IKE-less case is described.
このセクションでは、IKEレスケース用のYANGモジュールについて説明します。
For this case, the definition of the SPD model has been mainly extracted from the specification in Section 4.4.1 and Appendix D in [RFC4301], though with some changes, namely:
この場合、SPDモデルの定義は主にセクション4.4.1の仕様から[RFC4301]の指定から抽出されていますが、いくつかの変更は次のように変更されています。
* For simplicity, each IPsec policy (spd-entry) contains one Traffic Selector, instead of a list of them. The reason is that actual kernel implementations only admit a single Traffic Selector per IPsec policy.
* 簡単にするために、各IPSecポリシー（SPDエントリ）には、それらのリストの代わりに1つのトラフィックセレクタが含まれています。その理由は、実際のカーネルの実装がIPSecポリシーごとに単一のトラフィックセレクタのみを認めているためです。
* Each IPsec policy contains an identifier (reqid) to relate the policy with the IPsec SA. This is common in Linux-based systems.
* 各IPSecポリシーには、ポリシーをIPsec SAと関連付ける識別子（reqid）が含まれています。これはLinuxベースのシステムで一般的です。
* Each IPsec policy has only one name and not a list of names.
* 各IPsecポリシーには、名前のリストが1つだけではありません。
* Combined algorithms have been removed because encryption algorithms MAY include Authenticated Encryption with Associated Data (AEAD).
* 暗号化アルゴリズムに関連するデータ（AEAD）を含む認証された暗号化が含まれる可能性があるため、組み合わされたアルゴリズムが削除されました。
* Tunnel information has been extended with information about DSCP mapping. The reason is that certain kernel implementations accept configuration of these values.
* トンネル情報は、DSCPマッピングに関する情報で拡張されました。その理由は、特定のカーネル実装がこれらの値の構成を受け入れることです。
The definition of the SAD model has been mainly extracted from the specification in Section 4.4.2 of [RFC4301], though with some changes, namely:
SADモデルの定義は主に[RFC4301]のセクション4.4.2の仕様から抽出されていますが、いくつかの変更は次のように変更されています。
* For simplicity, each IPsec SA (sad-entry) contains one Traffic Selector, instead of a list of them. The reason is that actual kernel implementations only admit a single Traffic Selector per IPsec SA.
* 簡単にするために、各IPSec SA（SADエントリ）には、それらのリストの代わりに1つのトラフィックセレクタが含まれています。その理由は、実際のカーネル実装がIPsec SAごとに1つのトラフィックセレクタのみを認めているためです。
* Each IPsec SA contains an identifier (reqid) to relate the IPsec SA with the IPsec policy. The reason is that real kernel implementations allow this value to be included.
* 各IPsec SAには、IPsec SAをIPsecポリシーに関連付ける識別子（reqid）が含まれています。その理由は、実際のカーネルの実装がこの値を含めることを可能にすることです。
* Each IPsec SA is also named in the same way as IPsec policies.
* 各IPsec SAはIPsecポリシーと同じようにも呼ばれます。
* The model allows specifying the algorithm for encryption. This can be Authenticated Encryption with Associated Data (AEAD) or non-AEAD. If an AEAD algorithm is specified, the integrity algorithm is not required. If a non-AEAD algorithm is specified, the integrity algorithm is required [RFC8221].
* モデルは暗号化のためのアルゴリズムを指定することを可能にします。これは、関連するデータ（AEAD）または非AEADを使用して認証された暗号化を認証できます。AEDアルゴリズムが指定されている場合、整合性アルゴリズムは必要ありません。非AEDアルゴリズムが指定されている場合は、整合性アルゴリズムが必要です[RFC8221]。
* Tunnel information has been extended with information about Differentiated Services Code Point (DSCP) mapping. It is assumed that NSFs involved in this document provide ECN full functionality to prevent discarding of ECN congestion indications [RFC6040].
* トンネル情報は、差別化サービスコードポイント（DSCP）マッピングに関する情報で拡張されました。この文書に関与するNSFは、ECN輻輳指示の廃棄を防ぐためのECN全機能を提供すると仮定されています[RFC6040]。
* The lifetime of the IPsec SAs also includes idle time and the number of IP packets as a threshold to trigger the lifetime. The reason is that actual kernel implementations allow for setting these types of lifetimes.
* IPsec SASの有効期間には、アイドル時間とIPパケットの数が存続期間をトリガするためのしきい値として含まれています。その理由は、実際のカーネルの実装がこれらの種類の寿命を設定することを可能にするからです。
* Information to configure the type of encapsulation (encapsulation-type) for IPsec ESP packets in UDP [RFC3948] or TCP [RFC8229] has been included.
* UDP [RFC3948]またはTCP [RFC8229]のIPsec ESPパケットのカプセル化の種類（カプセル化型）を設定するための情報が含まれています。
The notifications model has been defined using, as reference, the PF_KEYv2 specification in [RFC2367].
通知モデルは、「RFC2367」のPF_Keyv2仕様を参照として、基準として定義されています。
The YANG data model for the IKE-less case is defined by the module "ietf-i2nsf-ikeless". Its structure is depicted in the following diagram, using the notation syntax for YANG tree diagrams [RFC8340].
IKEレスケースのYANDデータモデルは、モジュール "IETF-I2NSF-IKESS"によって定義されています。その構造は、Yangツリー図の表記の構文を使用して、次の図に示されています[RFC8340]。
module: ietf-i2nsf-ikeless
+--rw ipsec-ikeless
+--rw spd
| +--rw spd-entry* [name]
| +--rw name string
| +--rw direction nsfikec:ipsec-traffic-direction
| +--rw reqid? uint64
| +--rw ipsec-policy-config
| +--rw anti-replay-window-size? uint32
| +--rw traffic-selector
| | +--rw local-prefix inet:ip-prefix
| | +--rw remote-prefix inet:ip-prefix
| | +--rw inner-protocol? ipsec-inner-protocol
| | +--rw local-ports* [start end]
| | | +--rw start inet:port-number
| | | +--rw end inet:port-number
| | +--rw remote-ports* [start end]
| | +--rw start inet:port-number
| | +--rw end inet:port-number
| +--rw processing-info
| +--rw action? ipsec-spd-action
| +--rw ipsec-sa-cfg
| +--rw pfp-flag? boolean
| +--rw ext-seq-num? boolean
| +--rw seq-overflow? boolean
| +--rw stateful-frag-check? boolean
| +--rw mode? ipsec-mode
| +--rw protocol-parameters? ipsec-protocol-params
| +--rw esp-algorithms
| | +--rw integrity* intr-alg-t
| | +--rw encryption* [id]
| | | +--rw id uint16
| | | +--rw algorithm-type? encr-alg-t
| | | +--rw key-length? uint16
| | +--rw tfc-pad? boolean
| +--rw tunnel
| +--rw local inet:ip-address
| +--rw remote inet:ip-address
| +--rw df-bit? enumeration
| +--rw bypass-dscp? boolean
| +--rw dscp-mapping* [id]
| +--rw id uint8
| +--rw inner-dscp? inet:dscp
| +--rw outer-dscp? inet:dscp
+--rw sad
+--rw sad-entry* [name]
+--rw name string
+--rw reqid? uint64
+--rw ipsec-sa-config
| +--rw spi uint32
| +--rw ext-seq-num? boolean
| +--rw seq-overflow? boolean
| +--rw anti-replay-window-size? uint32
| +--rw traffic-selector
| | +--rw local-prefix inet:ip-prefix
| | +--rw remote-prefix inet:ip-prefix
| | +--rw inner-protocol? ipsec-inner-protocol
| | +--rw local-ports* [start end]
| | | +--rw start inet:port-number
| | | +--rw end inet:port-number
| | +--rw remote-ports* [start end]
| | +--rw start inet:port-number
| | +--rw end inet:port-number
| +--rw protocol-parameters? nsfikec:ipsec-protocol-params
| +--rw mode? nsfikec:ipsec-mode
| +--rw esp-sa
| | +--rw encryption
| | | +--rw encryption-algorithm? nsfikec:encr-alg-t
| | | +--rw key? yang:hex-string
| | | +--rw iv? yang:hex-string
| | +--rw integrity
| | +--rw integrity-algorithm? nsfikec:intr-alg-t
| | +--rw key? yang:hex-string
| +--rw sa-lifetime-hard
| | +--rw time? uint32
| | +--rw bytes? yang:counter64
| | +--rw packets? uint32
| | +--rw idle? uint32
| +--rw sa-lifetime-soft
| | +--rw time? uint32
| | +--rw bytes? yang:counter64
| | +--rw packets? uint32
| | +--rw idle? uint32
| | +--rw action? nsfikec:lifetime-action
| +--rw tunnel
| | +--rw local inet:ip-address
| | +--rw remote inet:ip-address
| | +--rw df-bit? enumeration
| | +--rw bypass-dscp? boolean
| | +--rw dscp-mapping* [id]
| | | +--rw id uint8
| | | +--rw inner-dscp? inet:dscp
| | | +--rw outer-dscp? inet:dscp
| | +--rw dscp-values* inet:dscp
| +--rw encapsulation-type
| +--rw espencap? esp-encap
| +--rw sport? inet:port-number
| +--rw dport? inet:port-number
| +--rw oaddr* inet:ip-address
+--ro ipsec-sa-state
+--ro sa-lifetime-current
| +--ro time? uint32
| +--ro bytes? yang:counter64
| +--ro packets? uint32
| +--ro idle? uint32
+--ro replay-stats
+--ro replay-window
| +--ro w? uint32
| +--ro t? uint64
| +--ro b? uint64
+--ro packet-dropped? yang:counter64
+--ro failed? yang:counter64
+--ro seq-number-counter? uint64
notifications:
+---n sadb-acquire {ikeless-notification}?
| +--ro ipsec-policy-name string
| +--ro traffic-selector
| +--ro local-prefix inet:ip-prefix
| +--ro remote-prefix inet:ip-prefix
| +--ro inner-protocol? ipsec-inner-protocol
| +--ro local-ports* [start end]
| | +--ro start inet:port-number
| | +--ro end inet:port-number
| +--ro remote-ports* [start end]
| +--ro start inet:port-number
| +--ro end inet:port-number
+---n sadb-expire {ikeless-notification}?
| +--ro ipsec-sa-name string
| +--ro soft-lifetime-expire? boolean
| +--ro lifetime-current
| +--ro time? uint32
| +--ro bytes? yang:counter64
| +--ro packets? uint32
| +--ro idle? uint32
+---n sadb-seq-overflow {ikeless-notification}?
| +--ro ipsec-sa-name string
+---n sadb-bad-spi {ikeless-notification}?
+--ro spi uint32
The YANG data model consists of a unique "ipsec-ikeless" container, which, in turn, is composed of two additional containers: "spd" and "sad". The "spd" container consists of a list of entries that form the Security Policy Database. Compared to the IKE case YANG data model, this part specifies a few additional parameters necessary due to the absence of an IKE software in the NSF: traffic direction to apply the IPsec policy and a "reqid" value to link an IPsec policy with its associated IPsec SAs since it is otherwise a little hard to find by searching. The "sad" container is a list of entries that form the Security Association Database. In general, each entry allows specifying both configuration information (SPI, Traffic Selectors, tunnel/transport mode, cryptographic algorithms and keying material, soft/hard lifetimes, etc.) as well as stating information (time to expire, replay statistics, etc.) of a concrete IPsec SA.
Yangデータモデルは、一意の「IPSec - Ikeseless」コンテナで構成されており、それは次に2つの追加のコンテナで構成されています。 "SPD"と "SAD"。「SPD」コンテナは、セキュリティポリシーデータベースを形成するエントリのリストで構成されています。IKEケースYANGデータモデルと比較して、このパートは、NSFにIKEソフトウェアが存在しないために必要な追加のパラメータを指定します。それ以外の場合は、検索によって見つけるのが少し難しいので、IPsec SAS。「悲しい」コンテナは、セキュリティアソシエーションデータベースを形成するエントリのリストです。一般に、各エントリは、設定情報（SPI、トラフィックセレクタ、トンネル/トランスポートモード、暗号化アルゴリズム、およびキーイングマテリアル、ソフト/ハードライフタイムなど）を指定すること、および述べています（期限切れの時間、再生統計など）。具体的なIPSEC SAの）。
In addition, the module defines a set of notifications to allow the NSF to inform the I2NSF Controller about relevant events, such as IPsec SA expiration, sequence number overflow, or bad SPI in a received packet.
さらに、モジュールは、受信したパケット内のIPsec SAの有効期限、シーケンス番号のオーバーフロー、または不良SPIなど、NSFが関連するイベントについてI2NSFコントローラに通知できるようにするための一連の通知を定義します。
Appendix B shows an example of an IKE-less case configuration for an NSF in transport mode (host-to-host). Additionally, Appendix C shows examples of IPsec SA expire, acquire, sequence number overflow, and bad SPI notifications.
付録Bは、トランスポートモード（ホスト間）のNSFのIKEレスケース構成の例を示しています。さらに、付録CはIPsec SAの期限切れ、取得、シーケンス番号のオーバーフロー、および悪いSPI通知の例を示しています。
This YANG module has normative references to [RFC4301], [RFC4303], [RFC6991], [RFC8174] and [RFC8341].
このYangモジュールには、[RFC4301]、[RFC4303]、[RFC6991]、[RFC8174]、[RFC8341]への規範的な参考文献があります。
<CODE BEGINS> file "ietf-i2nsf-ikeless@2021-07-14.yang"
module ietf-i2nsf-ikeless {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless";
prefix nsfikels;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types.";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types.";
}
import ietf-i2nsf-ikec {
prefix nsfikec;
reference
"RFC 9061: A YANG Data Model for IPsec Flow Protection
Based on Software-Defined Networking (SDN).";
}
import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control
Model.";
}
organization
"IETF I2NSF Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/>
WG List: <mailto:i2nsf@ietf.org>
Author: Rafael Marin-Lopez
<mailto:rafa@um.es>
Author: Gabriel Lopez-Millan
<mailto:gabilm@um.es>
Author: Fernando Pereniguez-Garcia <mailto:fernando.pereniguez@cud.upct.es> "; description "Data model for IKE-less case in the SDN-based IPsec flow protection service.
著者：Fernando Pereniguez-Garcia <mailto：fernando.pereniguez@cud.upct.es> "; SDNベースのIPsecフロー保護サービスのデータモデル。
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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here.
キーワードは「必須」、「必須」、「shall」、「shall '、'は '、'は '、'推奨 '、'推奨されていない '、' may '、'任意のものではありません。'この文書では、ここに示すように、BCP 14（RFC 2119）（RFC 8174）に記載されているように解釈されるべきです。
Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（c）2021 IETF信頼とコードの著者として識別された人。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info).
修正の有無にかかわらず、ソースおよびバイナリ形式での再配布と使用は、IETF文書に関連するIETF信託の法的規定のセクション4.Cに記載されている単純化されたBSDライセンスに従い、身に付けられたライセンス条項に従って許可されています（https://trustee.ietf.org/License-info）。
This version of this YANG module is part of RFC 9061; see the RFC itself for full legal notices.";
このYangモジュールのこのバージョンはRFC 9061の一部です。完全な法的通知のためのRFC自体を見てください。」
revision 2021-07-14 {
description
"Initial version.";
reference
"RFC 9061: A YANG Data Model for IPsec Flow Protection
Based on Software-Defined Networking (SDN).";
}
feature ikeless-notification { description "This feature indicates that the server supports generating notifications in the ikeless module.
機能ikeless-通知{説明 "この機能は、サーバーがIkelessモジュール内の通知の生成をサポートしていることを示します。
To ensure broader applicability of this module,
the notifications are marked as a feature.
For the implementation of the IKE-less case,
the NSF is expected to implement this
feature.";
}
container ipsec-ikeless {
description
"Container for configuration of the IKE-less
case. The container contains two additional
containers: 'spd' and 'sad'. The first allows the
I2NSF Controller to configure IPsec policies in
the Security Policy Database (SPD), and the second
allows the I2NSF Controller to configure IPsec
Security Associations (IPsec SAs) in the Security
Association Database (SAD).";
reference
"RFC 4301: Security Architecture for the Internet Protocol.";
container spd {
description
"Configuration of the Security Policy Database
(SPD).";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.2.";
list spd-entry {
key "name";
ordered-by user;
leaf name {
type string;
description
"SPD-entry-unique name to identify this
entry.";
}
leaf direction {
type nsfikec:ipsec-traffic-direction;
mandatory true;
description
"Inbound traffic or outbound
traffic. In the IKE-less case, the
I2NSF Controller needs to
specify the policy direction to be
applied in the NSF. In the IKE case,
this direction does not need to be
specified, since IKE
will determine the direction that the
IPsec policy will require.";
}
leaf reqid {
type uint64;
default "0";
description
"This value allows linking this
IPsec policy with IPsec SAs with the
same reqid. It is only required in
the IKE-less model since, in the IKE
case, this link is handled internally
by IKE.";
}
container ipsec-policy-config {
description
"This container carries the
configuration of an IPsec policy.";
uses nsfikec:ipsec-policy-grouping;
}
description
"The SPD is represented as a list of SPD
entries, where each SPD entry represents an
IPsec policy.";
} /*list spd-entry*/
} /*container spd*/
container sad {
description
"Configuration of the IPsec Security Association
Database (SAD).";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.2.1.";
list sad-entry {
key "name";
ordered-by user;
leaf name {
type string;
description
"SAD-entry-unique name to identify this
entry.";
}
leaf reqid {
type uint64;
default "0";
description
"This value allows linking this
IPsec SA with an IPsec policy with
the same reqid.";
}
container ipsec-sa-config {
description
"This container allows configuring
details of an IPsec SA.";
leaf spi {
type uint32 {
range "0..max";
}
mandatory true;
description
"IPsec SA of Security Parameter Index (SPI).";
}
leaf ext-seq-num {
type boolean;
default "true";
description
"True if this IPsec SA is using extended
sequence numbers. If true, the 64-bit
extended sequence number counter is used;
if false, the normal 32-bit sequence
number counter is used.";
}
leaf seq-overflow {
type boolean;
default "false";
description
"The flag indicating whether
overflow of the sequence number
counter should prevent transmission
of additional packets on the IPsec
SA (false) and, therefore, needs to
be rekeyed or whether rollover is
permitted (true). If Authenticated
Encryption with Associated Data
(AEAD) is used (leaf
esp-algorithms/encryption/algorithm-type),
this flag MUST BE false. Setting this
flag to true is strongly discouraged.";
}
leaf anti-replay-window-size {
type uint32;
default "64";
description
"To set the anti-replay window size.
The default value is set to 64,
following the recommendation in RFC 4303.";
reference
"RFC 4303: IP Encapsulating Security Payload (ESP),
Section 3.4.3.";
}
container traffic-selector {
uses nsfikec:selector-grouping;
description
"The IPsec SA Traffic Selector.";
}
leaf protocol-parameters {
type nsfikec:ipsec-protocol-params;
default "esp";
description
"Security protocol of IPsec SA, only
ESP so far.";
}
leaf mode {
type nsfikec:ipsec-mode;
default "transport";
description
"Tunnel or transport mode.";
}
container esp-sa {
when "../protocol-parameters = 'esp'";
description
"In case the IPsec SA is an
Encapsulation Security Payload
(ESP), it is required to specify
encryption and integrity
algorithms and key materials.";
container encryption {
description
"Configuration of encryption or
AEAD algorithm for IPsec
Encapsulation Security Payload
(ESP).";
leaf encryption-algorithm {
type nsfikec:encr-alg-t;
default "12";
description
"Configuration of ESP
encryption. With AEAD
algorithms, the integrity-algorithm
leaf is not used.";
}
leaf key {
nacm:default-deny-all;
type yang:hex-string;
description
"ESP encryption key value.
If this leaf is not defined,
the key is not defined
(e.g., encryption is NULL).
The key length is
determined by the
length of the key set in
this leaf. By default, it is
128 bits.";
}
leaf iv {
nacm:default-deny-all;
type yang:hex-string;
description
"ESP encryption IV value. If
this leaf is not defined, the
IV is not defined (e.g.,
encryption is NULL).";
}
}
container integrity {
description
"Configuration of integrity for
IPsec Encapsulation Security
Payload (ESP). This container
allows configuration of integrity
algorithms when no AEAD
algorithms are used and
integrity is required.";
leaf integrity-algorithm {
type nsfikec:intr-alg-t;
default "12";
description
"Message Authentication Code
(MAC) algorithm to provide
integrity in ESP (default
AUTH_HMAC_SHA2_256_128).
With AEAD algorithms,
the integrity leaf is not
used.";
}
leaf key {
nacm:default-deny-all;
type yang:hex-string;
description
"ESP integrity key value.
If this leaf is not defined,
the key is not defined (e.g.,
AEAD algorithm is chosen and
integrity algorithm is not
required). The key length is
determined by the length of
the key configured.";
}
}
} /*container esp-sa*/
container sa-lifetime-hard {
description
"IPsec SA hard lifetime. The action
associated is terminate and hold.";
uses nsfikec:lifetime;
}
container sa-lifetime-soft {
description
"IPsec SA soft lifetime.";
uses nsfikec:lifetime;
leaf action {
type nsfikec:lifetime-action;
description
"Action lifetime: terminate-clear,
terminate-hold, or replace.";
}
}
container tunnel {
when "../mode = 'tunnel'";
uses nsfikec:tunnel-grouping;
leaf-list dscp-values {
type inet:dscp;
description
"DSCP values allowed for ingress packets carried
over this IPsec SA. If no values are specified, no
DSCP-specific filtering is applied. When
../bypass-dscp is false and a dscp-mapping is
defined, each value here would be the same as the
'inner' DSCP value for the DSCP mapping (list
dscp-mapping).";
reference
"RFC 4301: Security Architecture for the Internet
Protocol, Section 4.4.2.1.";
}
description
"Endpoints of the IPsec tunnel.";
}
container encapsulation-type {
uses nsfikec:encap;
description
"This container carries
configuration information about
the source and destination ports
that will be used for ESP
encapsulation of ESP packets and
the type of encapsulation when NAT
traversal is in place.";
}
} /*ipsec-sa-config*/
container ipsec-sa-state {
config false;
description
"Container describing IPsec SA state
data.";
container sa-lifetime-current {
uses nsfikec:lifetime;
description
"SAD lifetime current.";
}
container replay-stats {
description
"State data about the anti-replay
window.";
container replay-window {
leaf w {
type uint32;
description
"Size of the replay window.";
}
leaf t {
type uint64;
description
"Highest sequence number
authenticated so far,
upper bound of window.";
}
leaf b {
type uint64;
description
"Lower bound of window.";
}
description
"This container contains three
parameters that define the state
of the replay window: window size (w),
highest sequence number authenticated (t),
and lower bound of the window (b), according
to Appendix A2.1 in RFC 4303 (w = t - b + 1).";
reference
"RFC 4303: IP Encapsulating Security Payload (ESP),
Appendix A.";
}
leaf packet-dropped {
type yang:counter64;
description
"Packets dropped
because they are
replay packets.";
}
leaf failed {
type yang:counter64;
description
"Number of packets detected out
of the replay window.";
}
leaf seq-number-counter {
type uint64;
description
"A 64-bit counter when this
IPsec SA is using Extended
Sequence Number or 32-bit
counter when it is not.
Current value of sequence
number.";
}
} /* container replay-stats*/
} /*ipsec-sa-state*/
description
"List of SAD entries that form the SAD.";
} /*list sad-entry*/
} /*container sad*/
} /*container ipsec-ikeless*/
/* Notifications */
notification sadb-acquire {
if-feature "ikeless-notification";
description
"The NSF detects and notifies that
an IPsec SA is required for an
outbound IP packet that has matched an SPD entry.
The traffic-selector container in this
notification contains information about
the IP packet that triggered this
notification.";
leaf ipsec-policy-name {
type string;
mandatory true;
description
"It contains the SPD entry name (unique) of
the IPsec policy that hits the IP-packet-required
IPsec SA. It is assumed the
I2NSF Controller will have a copy of the
information of this policy so it can
extract all the information with this
unique identifier. The type of IPsec SA is
defined in the policy so the security
controller can also know the type of IPsec
SA that MUST be generated.";
}
container traffic-selector {
description
"The IP packet that triggered the acquire
and requires an IPsec SA. Specifically, it
will contain the IP source/mask and IP
destination/mask, protocol (udp, tcp,
etc.), and source and destination
ports.";
uses nsfikec:selector-grouping;
}
}
notification sadb-expire {
if-feature "ikeless-notification";
description
"An IPsec SA expiration (soft or hard).";
leaf ipsec-sa-name {
type string;
mandatory true;
description
"It contains the SAD entry name (unique) of
the IPsec SA that is about to expire. It is assumed
the I2NSF Controller will have a copy of the
IPsec SA information (except the cryptographic
material and state data) indexed by this name
(unique identifier) so it can know all the
information (crypto algorithms, etc.) about
the IPsec SA that has expired in order to
perform a rekey (soft lifetime) or delete it
(hard lifetime) with this unique identifier.";
}
leaf soft-lifetime-expire {
type boolean;
default "true";
description
"If this value is true, the lifetime expired is
soft. If it is false, the lifetime is hard.";
}
container lifetime-current {
description
"IPsec SA current lifetime. If
soft-lifetime-expired is true,
this container is set with the
lifetime information about current
soft lifetime.
It can help the NSF Controller
to know which of the (soft) lifetime
limits raised the event: time, bytes,
packets, or idle.";
uses nsfikec:lifetime;
}
}
notification sadb-seq-overflow {
if-feature "ikeless-notification";
description
"Sequence overflow notification.";
leaf ipsec-sa-name {
type string;
mandatory true;
description
"It contains the SAD entry name (unique) of
the IPsec SA that is about to have a sequence
number overflow, and rollover is not permitted.
When the NSF issues this event before reaching
a sequence number, overflow is implementation
specific and out of scope of this specification.
It is assumed the I2NSF Controller will have a
copy of the IPsec SA information (except the
cryptographic material and state data) indexed
by this name (unique identifier) so it can
know all the information (crypto algorithms,
etc.) about the IPsec SA in
order to perform a rekey of the IPsec SA.";
}
}
notification sadb-bad-spi {
if-feature "ikeless-notification";
description
"Notify when the NSF receives a packet with an
incorrect SPI (i.e., not present in the SAD).";
leaf spi {
type uint32 {
range "0..max";
}
mandatory true;
description
"SPI number contained in the erroneous IPsec
packet.";
}
}
}
<CODE ENDS>
IANA has registered the following namespaces in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:
IANAは、「IETF XMLレジストリ」（RFC3688]内の「NS」サブレイストに次の名前空間を登録しました。
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.
URI：URN：IETF：PARAMS：XML：NS：YANG：IETF-I2NSF-IKEC登録者連絡先：IESG。XML：N / A、要求されたURIはXMLネームスペースです。
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.
URI：URN：IETF：PARAMS：XML：NS：YANG：IETF-I2NSF-IKE登録者連絡先：IESG。XML：N / A、要求されたURIはXMLネームスペースです。
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.
URI：URN：IETF：PARAMS：XML：NS：YANG：IETF-I2NSF-IKELESS登録者連絡先：IESG。XML：N / A、要求されたURIはXMLネームスペースです。
IANA has registered the following YANG modules in the "YANG Module Names" registry [RFC6020]:
IANAは、「ヤンモジュール名」レジストリに次のYangモジュールを登録しています[RFC6020]：
Name: ietf-i2nsf-ikec
Maintained by IANA: N
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec
Prefix: nsfikec
Reference: RFC 9061
Name: ietf-i2nsf-ike
Maintained by IANA: N
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike
Prefix: nsfike
Reference: RFC 9061
Name: ietf-i2nsf-ikeless
Maintained by IANA: N
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless
Prefix: nsfikels
Reference: RFC 9061
First of all, this document shares all the security issues of SDN that are specified in the Security Considerations sections of [ITU-T.Y.3300] and [RFC7426].
まず第一に、この文書は[ITU-T.Y.3300]と[RFC7426]のセキュリティ上のセクションで指定されているSDNのすべてのセキュリティ問題を共有しています。
On the one hand, it is important to note that there MUST exist a security association between the I2NSF Controller and the NSFs to protect the critical information (cryptographic keys, configuration parameter, etc.) exchanged between these entities. The nature of and means to create that security association is out of the scope of this document (i.e., it is part of device provisioning or onboarding).
一方では、I2NSFコントローラとNSFSとの間にセキュリティアソシエーションが存在して、これらのエンティティ間で交換された重要な情報（暗号化キー、構成パラメータなど）を保護する必要があることに注意することが重要です。セキュリティ協会がこの文書の範囲外であることを作成することと手段の性質（すなわち、それはデバイスプロビジョニングまたはオンボーディングの一部です）。
On the other hand, if encryption is mandatory for all traffic of an NSF, its default policy MUST be to drop (DISCARD) packets to prevent cleartext packet leaks. This default policy MUST be preconfigured in the startup configuration datastore in the NSF before the NSF contacts the I2NSF Controller. Moreover, the startup configuration datastore MUST be also preconfigured with the required ALLOW policies that allow the NSF to communicate with the I2NSF Controller once the NSF is deployed. This preconfiguration step is not carried out by the I2NSF Controller but by some other entity before the NSF deployment. In this manner, when the NSF starts/reboots, it will always first apply the configuration in the startup configuration before contacting the I2NSF Controller.
一方、暗号化がNSFのすべてのトラフィックに対して必須である場合、そのデフォルトポリシーはパケットを削除（破棄）する必要があります。このデフォルトポリシーは、NSFがI2NSFコントローラに連絡する前に、NSFのStartup Configuration DataStoreで事前設定されている必要があります。さらに、NSFがデプロイされた後にNSFがI2NSFコントローラと通信できるようにするために、起動設定データストアも必要な許可ポリシーで事前設定されなければなりません。この事前設定手順は、I2NSFコントローラによってはなく、NSF展開の前の他のエンティティによって実行されません。このようにして、NSFが起動/再起動すると、I2NSFコントローラに連絡する前に、まず最初に起動設定で設定を適用します。
Finally, this section is divided in two parts in order to analyze different security considerations for both cases: NSF with IKEv2 (IKE case) and NSF without IKEv2 (IKE-less case). In general, the I2NSF Controller, as typically in the SDN paradigm, is a target for different type of attacks; see [SDNSecServ] and [SDNSecurity]. Thus, the I2NSF Controller is a key entity in the infrastructure and MUST be protected accordingly. In particular, the I2NSF Controller will handle cryptographic material; thus, the attacker may try to access this information. The impact is different depending on the IKE case or the IKE-less case.
最後に、このセクションは、両方の場合について異なるセキュリティ上の考慮事項を分析するために2つの部分に分割されています.NSF IKEV2（IKEケース）とNSF（IKE-LESSケース）。一般的に、SDNパラダイムの通常、I2NSFコントローラは、さまざまな種類の攻撃のターゲットです。[SDNSECSERV]と[SDNSecurity]を参照してください。したがって、I2NSFコントローラはインフラストラクチャ内の重要なエンティティであり、それに応じて保護する必要があります。特に、I2NSFコントローラは暗号材料を処理します。したがって、攻撃者はこの情報にアクセスしようとする可能性があります。IKEケースやIKEレスケースによって衝撃が異なります。
In the IKE case, the I2NSF Controller sends IKEv2 credentials (PSK, public/private keys, certificates, etc.) to the NSFs using the security association between the I2NSF Controller and NSFs. The I2NSF Controller MUST NOT store the IKEv2 credentials after distributing them. Moreover, the NSFs MUST NOT allow the reading of these values once they have been applied by the I2NSF Controller (i.e., write-only operations). One option is to always return the same value (i.e., all 0s) if a read operation is carried out.
IKEケースでは、I2NSFコントローラは、I2NSFコントローラとNSFS間のセキュリティアソシエーションを使用して、IKEv2認証情報（PSK、パブリック/プライベートキー、証明書など）をNSFSに送信します。I2NSFコントローラは、それらを配布した後にIKEV2認証情報を保存してはいけません。さらに、NSFSは、I2NSFコントローラ（すなわち書き込み専用操作）によって適用されると、これらの値の読み取りを許可してはいけません。1つの選択肢は、読み出し動作が実行された場合に、常に同じ値（すなわち、全ての0S）を返すことである。
If the attacker has access to the I2NSF Controller during the period of time that key material is generated, it might have access to the key material. Since these values are used during NSF authentication in IKEv2, it may impersonate the affected NSFs. Several recommendations are important.
キーマテリアルが生成された期間中に攻撃者がI2NSFコントローラにアクセスできる場合は、キーマテリアルにアクセスできる可能性があります。これらの値はIKEv2ではNSF認証中に使用されるため、影響を受けるNSFを偽装することがあります。いくつかの推奨事項が重要です。
* IKEv2 configurations SHOULD adhere to the recommendations in [RFC8247].
* IKEV2構成は[RFC8247]の推奨事項を遵守する必要があります。
* If PSK authentication is used in IKEv2, the I2NSF Controller MUST remove the PSK immediately after generating and distributing it.
* PSK認証がIKEv2で使用されている場合、I2NSFコントローラはそれを生成して配布した直後にPSKを削除する必要があります。
* When public/private keys are used, the I2NSF Controller MAY generate both public key and private key. In such a case, the I2NSF Controller MUST remove the associated private key immediately after distributing them to the NSFs. Alternatively, the NSF MAY generate the private key and export only the public key to the I2NSF Controller. How the NSF generates these cryptographic materials (public key/ private keys) and exports the public key is out of scope of this document.
* パブリックキー/秘密鍵が使用されると、I2NSFコントローラは公開鍵と秘密鍵の両方を生成することがあります。そのような場合、I2NSFコントローラはそれらをNSFに配布した直後に関連する秘密鍵を削除する必要があります。あるいは、NSFは秘密鍵を生成し、公開鍵のみをI2NSFコントローラにエクスポートしてもよい。NSFがこれらの暗号材料を生成し（公開鍵/秘密鍵）、公開鍵をエクスポートすることはこの文書の範囲外です。
* If certificates are used, the NSF MAY generate the private key and export the public key for certification to the I2NSF Controller. How the NSF generates these cryptographic material (public key/ private keys) and exports the public key is out of scope of this document.
* 証明書が使用されている場合、NSFは秘密鍵を生成し、認証のために公開鍵をI2NSFコントローラにエクスポートすることがあります。NSFがこれらの暗号化品目を生成し（公開鍵/秘密鍵）、公開鍵をエクスポートする方法は、この文書の範囲外です。
In the IKE-less case, the I2NSF Controller sends the IPsec SA information to the NSF's SAD that includes the private session keys required for integrity and encryption. The I2NSF Controller MUST NOT store the keys after distributing them. Moreover, the NSFs receiving private key material MUST NOT allow the reading of these values by any other entity (including the I2NSF Controller itself) once they have been applied (i.e., write-only operations) into the NSFs. Nevertheless, if the attacker has access to the I2NSF Controller during the period of time that key material is generated, it may obtain these values. In other words, the attacker might be able to observe the IPsec traffic and decrypt, or even modify and re-encrypt, the traffic between peers.
IKE-LESSケースでは、I2NSFコントローラはIPSec SA情報をIPSEC SAの情報をNSFのSADに送信し、整合性と暗号化に必要なプライベートセッションキーを含む。I2NSFコントローラは、それらを配布した後にキーを保存してはいけません。さらに、秘密鍵素材を受信したNSFSは、それらが適用されたら（I2NSFコントローラ自体を含む）他のエンティティ（I2NSFコントローラ自体を含む）によってNSFSへのこれらの値の読み取りを許可してはなりません。それにもかかわらず、攻撃者がキーマテリアルが生成された期間中にI2NSFコントローラにアクセスできる場合は、これらの値を取得できます。言い換えれば、攻撃者はIPsecトラフィックを監視し、ピア間のトラフィックを復号化したり、変更したり再暗号化したりすることさえできる可能性があります。
Finally, the security association between the I2NSF Controller and the NSFs MUST provide, at least, the same degree of protection as the one achieved by the IPsec SAs configured in the NSFs. In particular, the security association between the I2NSF Controller and the NSFs MUST provide forward secrecy if this property is to be achieved in the IPsec SAs that the I2NSF Controller configures in the NSFs. Similarly, the encryption algorithms used in the security association between the I2NSF Controller and the NSF MUST have, at least, the same strength (minimum strength of a 128-bit key) as the algorithms used to establish the IPsec SAs.
最後に、I2NSFコントローラとNSFSとの間のセキュリティアソシエーションは、NSFSで構成されたIPsec SASによって達成されたものと同じ程度の保護を提供する必要があります。特に、I2NSFコントローラがNSFS内で構成されているIPSec SASでこのプロパティを実現する場合、I2NSFコントローラとNSFSのセキュリティの関連付けは、このプロパティがIPSec SASで実現される場合は順序秘密を提供する必要があります。同様に、I2NSFコントローラとNSFとの間のセキュリティアソシエーションで使用される暗号化アルゴリズムは、IPSec SASを確立するために使用されるアルゴリズムとして、少なくとも同じ強度（128ビットキーの最小強度）を持たなければならない。
The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].
このドキュメントで指定されているYangモジュールは、NetConf [RFC6241]またはRESTCONF [RFC8040]などのネットワーク管理プロトコルを介してアクセスするように設計されているデータのスキーマを定義します。最低のNetConfレイヤーはセキュアトランスポート層で、必須の実装セキュアトランスポートはSecure Shell（SSH）[RFC6242]です。最低のRETCONFレイヤーはhttpsで、必須のセキュアトランスポートはTLS [RFC8446]です。
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
ネットワーク構成アクセス制御モデル（NACM）[RFC8341]は、特定のNETCONFまたはRESTCONFユーザへのアクセスを制限する手段を、利用可能なすべてのNetConfまたはRESTCONFプロトコル操作およびコンテンツの事前設定されたサブセットに制限することを可能にします。
There are a number of data nodes defined in these YANG modules that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
書き込み可能/作成可能/削除可能なこれらのYANDモジュールに定義されているデータノードがいくつかあります（すなわち、デフォルトであるConfig True）。これらのデータノードは、一部のネットワーク環境では敏感または脆弱と見なすことができます。適切な保護なしにこれらのデータノードへの書き込み操作（例えば、edit-config）は、ネットワーク操作に悪影響を及ぼす可能性があります。これらはサブツリーとデータノードとその感度/脆弱性です。
For the IKE case (ietf-i2nsf-ike): /ipsec-ike: The entire container in this module is sensitive to write operations. An attacker may add/modify the credentials to be used for the authentication (e.g., to impersonate an NSF), for the trust root (e.g., changing the trusted CA certificates), for the cryptographic algorithms (allowing a downgrading attack), for the IPsec policies (e.g., by allowing leaking of data traffic by changing to an allow policy), and in general, changing the IKE SA conditions and credentials between any NSF.
IKEケース（IETF-I2NSF-IKE）：/ IPSEC-IKE：このモジュールのコンテナ全体は書き込み操作に敏感です。攻撃者は、信頼ルート（例えば、信頼できるCA証明書を変更するため）の認証に使用される資格情報（例えば、信頼済みCA証明書を変更する）、暗号化アルゴリズム（ダウングラード攻撃を許可する）を追加または変更することができます。IPsecポリシー（例えば、許可ポリシーに変更することによってデータトラフィックの漏洩を許可することによって）、一般的には、NSF間のIKE SAの状態と資格情報を変更します。
For the IKE-less case (ietf-i2nsf-ikeless): /ipsec-ikeless: The entire container in this module is sensitive to write operations. An attacker may add/modify/delete any IPsec policies (e.g., by allowing leaking of data traffic by changing to an allow policy) in the /ipsec-ikeless/spd container, add/modify/delete any IPsec SAs between two NSF by means of /ipsec-ikeless/sad container, and, in general, change any IPsec SAs and IPsec policies between any NSF.
IKE-LESSケース（IETF-I2NSF-IKESS）の場合：/ IPSEC-IKESES：このモジュールのコンテナ全体は書き込み操作に敏感です。攻撃者は、/ ipsec-ikeless / spdコンテナ内のIPSecポリシーを追加/変更/削除することができます。/ ipsec-ikesels / sadコンテナのどちらか、一般に、どのNSF間でもIPSec SASおよびIPSecポリシーを変更します。
Some of the readable data nodes in these YANG modules may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:
これらのYANGモジュール内の読み取り可能なデータノードのいくつかは、いくつかのネットワーク環境では敏感または脆弱と見なすことができます。したがって、これらのデータノードへの読み取りアクセス（例えば、get、get - config、または通知）を制御することが重要である。これらはサブツリーとデータノードとその感度/脆弱性です。
For the IKE case (ietf-i2nsf-ike): /ipsec-ike/pad: This container includes sensitive information to read operations. This information MUST NOT be returned to a client. For example, cryptographic material configured in the NSFs (peer-authentication/pre-shared/secret and peer-authentication/digital-signature/private-key) are already protected by the NACM extension "default-deny-all" in this document.
IKEケース（IETF-I2NSF-IKE）の場合：/ IPSEC-IKE / PAD：このコンテナには、読み取り操作に機密情報が含まれています。この情報はクライアントに返されてはいけません。たとえば、NSFSで設定されている暗号化材料（ピア認証/事前共有/シークレット、ピア認証/デジタルシグネチャー/プライベートキー）は、このドキュメントのNACM拡張「デフォルト-deny-all」によってすでに保護されています。
For the IKE-less case (ietf-i2nsf-ikeless): /ipsec-ikeless/sad/sad-entry/ipsec-sa-config/esp-sa: This container includes symmetric keys for the IPsec SAs. For example, encryption/key contains an ESP encryption key value and encryption/iv contains an Initialization Vector value. Similarly, integrity/key has an ESP integrity key value. Those values MUST NOT be read by anyone and are protected by the NACM extension "default-deny-all" in this document.
IKEレスケースの場合（IETF-I2NSF-IKESISE）：/ IPSEC-IKESSERS / SAD / SAD-ENTRY / IPSEC-SA-CONFIG / ESP-SA：このコンテナには、IPsec SASの対称キーが含まれています。たとえば、暗号化/キーにはESP暗号化キー値が含まれ、暗号化/ IVに初期化ベクトル値が含まれています。同様に、Integrity / KeyはESPの整合性キー値を持ちます。これらの値は誰でも読み取られてはならず、このドキュメントのNACM拡張「デフォルト-deny-all」によって保護されています。
[IANA-Method-Type] IANA, "Method Type", <https://www.iana.org/assignments/eap-numbers/>.
[IANA-method-type] IANA、 "メソッドタイプ"、<https：//www.iana.org/assignments/eap-numbers/>。
[IANA-Protocols-Number] IANA, "Protocol Numbers", <https://www.iana.org/assignments/protocol-numbers/>.
[IANA-PROTOCOLS-NUMBER] IANA、「プロトコル番号」、<https：//www.iana.org/assignments/protocol-numbers/>。
[IKEv2-Auth-Method] IANA, "IKEv2 Authentication Method", <https://www.iana.org/assignments/ikev2-parameters/>.
[IKEv2-auth-method] IANA、 "IKEV2認証方法"、<https：//www.iana.org/ashignments/ikev2-parameters/>。
[IKEv2-Parameters] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <https://www.iana.org/assignments/ikev2-parameters/>.
[IKEV2-Parameters] IANA、「インターネットキー交換バージョン2（IKEV2）パラメータ」、<https：//www.iana.org/assignments/ikev2-parameters/>。
[IKEv2-Transform-Type-1] IANA, "Transform Type 1 - Encryption Algorithm Transform IDs", <https://www.iana.org/assignments/ikev2-parameters/>.
[IKEV2変換タイプ1] IANA、「変換タイプ1 - 暗号化アルゴリズムID」、<https://www.iana.org/assignments/ikev2-parameters/>。
[IKEv2-Transform-Type-3] IANA, "Transform Type 3 - Integrity Algorithm Transform IDs", <https://www.iana.org/assignments/ikev2-parameters/>.
[IKEV2変換型3] IANA、「変換タイプ3 - 整合性アルゴリズム変換ID」、<https://www.iana.org/assignments/ikev2-parameters/>。
[IKEv2-Transform-Type-4] IANA, "Transform Type 4 - Diffie-Hellman Group Transform IDs", <https://www.iana.org/assignments/ikev2-parameters/>.
[IKEV2変換型4] IANA、「変換タイプ4 - Diffie-Hellman Group Transform ID」、<https://www.iana.org/ashignments/ikev2-parameters/>。
[ITU-T.X.690] International Telecommunication Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, February 2021.
[ITU-TX690] International Telecommunication Union、「Information Technology - ASN.1符号化規則：基本符号化規則（BER）、正規符号化規則（CER）および識別符号化規則（DER）」、ITU-T勧告X.690、ISO / IEC 8825-1、2021年2月。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, DOI 10.17487/RFC3947, January 2005, <https://www.rfc-editor.org/info/rfc3947>.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A.、およびV. Volpe、「IKEのNAT-TRAVERSALのネゴシエーション」、RFC 3947、DOI 10.17487 / RFC3947、2005年1月、<https：//www.rfc-editor.org/info/rfc3947>。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, January 2005, <https://www.rfc-editor.org/info/rfc3948>.
[RFC3948] Huttunen、A.、Swander、B.、Volpe、V.、Diburro、L.、およびM. Stenberg、「IPsec ESPパケットのUDPカプセル化」、RFC 3948、DOI 10.17487 / RFC3948、2005年1月、<HTTPS：//www.rfc-editor.org/info/rfc3948>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S.およびK.SEO、「インターネットプロトコルのためのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<https：//www.rfc-editor.org/info/rfc4301>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<https：//www.rfc-editor.org/info/rfc4303>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW.Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P.、Ed。、「インターネットメッセージフォーマット」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<https：//www.rfc-editor.org/info/rfc5322>。
[RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, <https://www.rfc-editor.org/info/rfc5915>.
[RFC5915]ターナー、S.およびD. Brown、 "楕円曲線秘密鍵構造"、RFC 5915、DOI 10.17487 / RFC5915、2010年6月、<https：//www.rfc-editor.org/info/rfc5915>。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M.、Ed。、「Yang - ネットワーク構成プロトコルのデータモデリング言語（NetConf）」、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<https：//www.rfc-編集者。org / info / rfc6020>。
[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]、R.Bjorklund、M.、Ed。、Schoenwaelder、J.、Ed。、およびA. Bierman、ED。、「ネットワーク構成プロトコル（NetConf）」、RFC 6241、DOI 10.17487 /RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6242] Wasserman、M.、「Secure Shell（SSH）のNetConfプロトコル（SSH）の使用（SSH）、RFC 6242、DOI 10.17487 / RFC6242、2011年6月、<https://www.rfc-editor.org/info/rfc6242>。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960] Santesson、S、Myers、M.、Ankney、R.、Malpani、A.、Galparin、S、およびC. ADAMS、「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル - OCSP」、RFC6960、DOI 10.17487 / RFC6960、2013年6月、<https：//www.rfc-editor.org/info/rfc6960>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J.、Ed。、「共通ヤンデータ型」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<https：//www.rfc-editor.org/info/rfc6991>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、NIR、Y.、Eronen、P.、およびT.Kivinen、「インターネットキー交換プロトコル版2（IKEV2）」、STD 79、RFC 7296、DOI 10.17487 / RFC72962014年10月、<https：//www.rfc-editor.org/info/rfc7296>。
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, <https://www.rfc-editor.org/info/rfc7383>.
[RFC7383] SmySlov、V.、 "Internet Key Exchange Protocol Version 2（IKEV2）メッセージ断片化"、RFC 7383、DOI 10.17487 / RFC7383、2014年11月、<https://www.rfc-editor.org/info/rfc7383>。
[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, DOI 10.17487/RFC7427, January 2015, <https://www.rfc-editor.org/info/rfc7427>.
[RFC7427] Kivinen、T.およびJ.Snyder、「インターネットキー交換バージョン2（IKEV2）の署名認証、RFC 7427、DOI 10.17487 / RFC7427、2015年1月、<https://www.rfc-editor.org/ Info / RFC7427>。
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, <https://www.rfc-editor.org/info/rfc7619>.
[RFC7619] SmySlov、V.およびP.Wouters、「インターネット鍵交換プロトコルバージョン2（IKEv2）」、RFC 7619、DOI 10.17487 / RFC7619、2015年8月、<https：//www.rfc-editor.org/info/rfc7619>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M.、ED。、「Yang 1.1データモデリング言語」、RFC 7950、DOI 10.17487 / RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[RFC8017] MoriArty、K。、ED。、Kaliski、B.、Jonsson、J.、A. RUSCH、「PKCS＃1：RSA暗号化仕様バージョン2.2」、RFC 8017、DOI 10.17487 / RFC8017、2016年11月、<https://www.rfc-editor.org/info/rfc8017>。
[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 Protoction"、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https：//www.rfc-editor.org/info/rfc8040>。
[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>。
[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, October 2017, <https://www.rfc-editor.org/info/rfc8221>.
[RFC8221] Wouters、P.、Migaute、D.、Mattsson、J.、NIR、Y.、およびT.Kivinen、Cryptographicアルゴリズムの実装要件とセキュリティペイロード（ESP）と認証ヘッダー（AH）） "、RFC 8221、DOI 10.17487 / RFC8221、2017年10月、<https://www.rfc-editor.org/info/rfc8221>。
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[RFC8229] Pouly、T.、Touati、S.、R. Mantha、「IPSとIPsecパケットのTCPカプセル化」、RFC 8229、DOI 10.17487 / RFC8229、2017年8月、<https：//www.rfc-編集者。ORG / INFO / RFC8229>。
[RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, "Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 8247, DOI 10.17487/RFC8247, September 2017, <https://www.rfc-editor.org/info/rfc8247>.
[RFC8247] NIR、Y.、Kivinen、T.、Wouters、P.、およびD. MIGAULT、「インターネット鍵交換プロトコル版2（IKEV2）」、RFC 8247、DOI 10.17487 / RFC82472017年9月、<https：//www.rfc-editor.org/info/rfc8247>。
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8340] Bjorklund、M.およびL. Berger、Ed。、「Yang Tree Diagress」、BCP 215、RFC 8340、DOI 10.17487 / RFC8340、2018年3月、<https：//www.rfc-editor.org/info/RFC8340>。
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8341] Bierman、A.およびM.Bjorklund、「ネットワーク構成アクセス制御モデル」、STD 91、RFC 8341、DOI 10.17487 / RFC8341、2018年3月、<https：//www.rfc-editor.org/info/rfc8341>。
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.
[RFC8342] Bjorklund、M.、Schoenwaelder、J.、Shafer、P.、Watsen、K.、R. Wilton、「ネットワーク管理データストアアーキテクチャ（NMDA）」、RFC 8342、DOI 10.17487 / RFC8342、2018年3月、<https://www.rfc-editor.org/info/rfc8342>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[IPSECME-CONTROLLER-IKE] Carrel, D. and B. Weis, "IPsec Key Exchange using a Controller", Work in Progress, Internet-Draft, draft-carrel-ipsecme-controller-ike-01, 10 March 2019, <https://datatracker.ietf.org/doc/html/draft-carrel-ipsecme-controller-ike-01>.
[IPSecme-controller-ike] Carrele、D.およびB. Weis、「コントローラを使用したIPsecキー交換」、進行中の作業、インターネットドラフト、ドラフト - Carrel-IPsecme-Controller-IKE-01,200月10日、<https://datatracker.ietf.org/doc/html/draft-carrel-ipsecme-controller-ike-01>。
[ITU-T.Y.3300] International Telecommunications Union, "Y.3300: Framework of software-defined networking", June 2014, <https://www.itu.int/rec/T-REC-Y.3300/en>.
[ITU-T.Y.3300]国際電気通信連合「Y.3300：ソフトウェア定義ネットワーキングの枠組み」、2014年6月、<https：//www.itu.int/rec/t-rec-y.3300/en>。
[libreswan] The Libreswan Project, "Libreswan VPN software", <https://libreswan.org/>.
[LibreSwan] LibreSwanプロジェクト「LibreSwan VPN Software」、<https://libreswan.org/>。
[netconf-vpn] Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014, <https://ripe68.ripe.net/presentations/181-NETCONF-YANG-tutorial-43.pdf>.
[NetConf-VPN] Stefan Wallin、 "チュートリアル：NetConf and Yang"、2014年1月、<https：//ripe68.ripe.net/presentations/181-netconf-yang-tutorial-43.pdf>。
[ONF-OpenFlow] Open Networking Foundation, "OpenFlow Switch Specification", Version 1.4.0 (Wire Protocol 0x05), October 2013, <https://www.opennetworking.org/wp-content/uploads/2014/10/openflow-spec-v1.4.0.pdf>.
[ONF-OpenFlow] Open Networking Foundation、「OpenFlow Switch Specification」、バージョン1.4.0、2013年10月、<https://www.opennetworking.org/wp-content/uploads/2014/10/OpenFlow-Spec-v1.4.0.pdf>。
[ONF-SDN-Architecture] Open Networking Foundation, "SDN architecture", Issue 1, June 2014, <https://www.opennetworking.org/wp-content/uploads/2013/02/TR_SDN_ARCH_1.0_06062014.pdf>.
[ONF-SDNアーキテクチャ]オープンネットワーキング財団、「SDNアーキテクチャ」、2014年6月、<https：//www.opennetworking.org/wp-content/uploads/2013/02/tr_sdn_arch_1.0_06062014.pdf>。
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, DOI 10.17487/RFC2367, July 1998, <https://www.rfc-editor.org/info/rfc2367>.
[RFC2367] McDonald、D.、Metz、C.、B. Phan、 "PF_Key Key Management API、バージョン2"、RFC 2367、DOI 10.17487 / RFC2367、1998年7月、<https：///www.rfc-編集者。ORG / INFO / RFC2367>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M.、 "The IETF XMLレジストリ"、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https：//www.rfc-editor.org/info/rfc3688>。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC6040] Briscoe、B.、「明示的輻輳通知のトンネリング」、RFC 6040、DOI 10.17487 / RFC6040、2010年11月、<https：//www.rfc-editor.org/info/rfc6040>。
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, DOI 10.17487/RFC6071, February 2011, <https://www.rfc-editor.org/info/rfc6071>.
[RFC6071] Frankel、S.およびS.クリシュナン、「IPセキュリティ（IPsec）およびインターネットキー交換（IKE）文書ロードマップ」、RFC 6071、DOI 10.17487 / RFC6071、2011年2月、<https：///www.rfc-編集者.ORG / INFO / RFC6071>。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S.、およびJ.Rajahalme、「IPv6フローラベル仕様」、RFC 6437、DOI 10.17487 / RFC6437、2011年11月、<https：//www.rfc-editor.org/info/rfc6437>。
[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, <https://www.rfc-editor.org/info/rfc7149>.
[RFC7149] Boucadair、M.およびC. Jacquenet、「ソフトウェア定義ネットワーキング：サービスプロバイダー環境内からの視点」、RFC 7149、DOI 10.17487 / RFC7149、2014年3月、<https：///www.rfc-編集者。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, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7426] Haleplidis、E.、Ed。、Pentikisis、K.、Ed。、Denazis、S.、Hadi Salim、J.、Meyer、D.、およびO.Koufopavlouou、「ソフトウェア定義ネットワーキング（SDN）：レイヤー2015年1月、<https://www.rfc-editor.org/info/rfc7426>を記録しています、および2015年1月、アーキテクチャの用語、RFC 7426 / RFC7426、RFC7426。
[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., and J. Jeong, "Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases", RFC 8192, DOI 10.17487/RFC8192, July 2017, <https://www.rfc-editor.org/info/rfc8192>.
[RFC8192] HARES、S、Lopez、D.、Zarny、M.、Jacquenet、C、Kumar、R.、およびJ.Jョン、「ネットワークセキュリティ機能へのインタフェース（I2NSF）：問題ステートメントとユースケース」、RFC 8192、DOI 10.17487 / RFC8192、2017年7月、<https://www.rfc-editor.org/info/rfc8192>。
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, <https://www.rfc-editor.org/info/rfc8329>.
[RFC8329] Lopez、D.、Lopez、E.、Dunbar、L.、Strassner、J.、R.Kumar、「ネットワークセキュリティ機能へのインターフェースのためのフレームワーク」、RFC 8329、DOI 10.17487 / RFC8329、2018年2月、<https://www.rfc-editor.org/info/rfc8329>。
[SDNSecServ] Scott-Hayward, S., O'Callaghan, G., and P. Sezer, "Sdn Security: A Survey", 2013 IEEE SDN for Future Networks and Services (SDN4FNS), pp. 1-7, DOI 10.1109/SDN4FNS.2013.6702553, November 2013, <https://doi.org/10.1109/SDN4FNS.2013.6702553>.
[SDNSECSERV] Scott-Hayward、S.、O'Callaghan、G.、およびP. Sezer、「SDNセキュリティ：A調査」、2013 IEEE SDN将来のネットワークとサービス（SDN4FNS）、PP。1-7、DOI 10.1109/sdn4fns.2013.6702553、2013年11月、<https：//doi.org/10.1109/sdn4fns.2013.6702553>。
[SDNSecurity] Kreutz, D., Ramos, F., and P. Verissimo, "Towards secure and dependable software-defined networks", Proceedings of the second ACM SIGCOMM workshop on Hot Topics in software defined networking, pp. 55-60, DOI 10.1145/2491185.2491199, August 2013, <https://doi.org/10.1145/2491185.2491199>.
[SDNSecurity] Kreutz、D.、Ramos、F.、P. Verissimo、「安全性と信頼できるソフトウェア定義ネットワークに向けて」、ソフトウェア定義ネットワーク、PP 55-60のホットトピックに関する2番目のACM SIGCOMMワークショップの手続きDOI 10.1145 / 2491185.2491199、2013年8月、<https://doi.org/10.1145/2491185.2491199>。
[strongswan] CESNET, "strongSwan: the OpenSource IPsec-based VPN Solution", <https://www.strongswan.org/>.
[StrongSwan] CESnet、 "Strongswan：OpenSource IPsecベースのVPNソリューション"、<https://www.strongswan.org/>。
[TRAN-IPSECME-YANG] Tran, K., Wang, H., Nagaraj, V. K., and X. Chen, "Yang Data Model for Internet Protocol Security (IPsec)", Work in Progress, Internet-Draft, draft-tran-ipsecme-yang-01, 18 March 2016, <https://datatracker.ietf.org/doc/html/ draft-tran-ipsecme-yang-01>.
[TRAN-IPSECME-YANG] TRAN、K.、Wang、H.、Nagaraj、VK、およびX。Chen、「インターネットプロトコルセキュリティのためのYangデータモデル（IPSec）」、進行中の作業、インターネットドラフト、ドラフトトラン-ipsecme-yang-01,18月18日、<https://datatracker.ietf.org/doc/html/ romft-tran-ipsecme-yang-01>。
Appendix A. XML Configuration Example for IKE Case (Gateway-to-Gateway)
付録A. IKEケースのXML構成例（ゲートウェイからゲートウェイ）
This example shows an XML configuration file sent by the I2NSF Controller to establish an IPsec SA between two NSFs (see Figure 3) in tunnel mode (gateway-to-gateway) with ESP, with authentication based on X.509 certificates (simplified for brevity with "base64encodedvalue==") and applying the IKE case.
この例では、X.509証明書に基づく認証を使用して、ESPを使用した2つのNSF（ゲートウェイからゲートウェイ）の間にIPSEC SA（Gateway-To-Gateway）の間にIPSEC SAが送信するためにI2NSFコントローラによって送信されたXML構成ファイルを示しています。"base64encodedvalue =="を使ってIKEケースを適用します。
+------------------+
| I2NSF Controller |
+------------------+
I2NSF NSF-Facing |
Interface |
/-----------------+---------------\
/ \
/ \
+----+ +--------+ +--------+ +----+
| h1 |--| nsf_h1 |== IPsec_ESP_Tunnel_mode == | nsf_h2 |--| h2 |
+----+ +--------+ +--------+ +----+
:1 :100 :200 :1
(2001:db8:1:/64) (2001:db8:123:/64) (2001:db8:2:/64)
Figure 3: IKE Case, Tunnel Mode, X.509 Certificate Authentication
図3：IKEケース、トンネルモード、X.509証明書認証
<ipsec-ike xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<pad>
<pad-entry>
<name>nsf_h1_pad</name>
<ipv6-address>2001:db8:123::100</ipv6-address>
<peer-authentication>
<auth-method>digital-signature</auth-method>
<digital-signature>
<cert-data>base64encodedvalue==</cert-data>
<private-key>base64encodedvalue==</private-key>
<ca-data>base64encodedvalue==</ca-data>
</digital-signature>
</peer-authentication>
</pad-entry>
<pad-entry>
<name>nsf_h2_pad</name>
<ipv6-address>2001:db8:123::200</ipv6-address>
<auth-protocol>ikev2</auth-protocol>
<peer-authentication>
<auth-method>digital-signature</auth-method>
<digital-signature>
<!-- RSA Digital Signature -->
<ds-algorithm>1</ds-algorithm>
<cert-data>base64encodedvalue==</cert-data>
<ca-data>base64encodedvalue==</ca-data>
</digital-signature>
</peer-authentication>
</pad-entry>
</pad>
<conn-entry>
<name>nsf_h1-nsf_h2</name>
<autostartup>start</autostartup>
<version>ikev2</version>
<initial-contact>false</initial-contact>
<fragmentation><enabled>false</enabled></fragmentation>
<ike-sa-lifetime-soft>
<rekey-time>60</rekey-time>
<reauth-time>120</reauth-time>
</ike-sa-lifetime-soft>
<ike-sa-lifetime-hard>
<over-time>3600</over-time>
</ike-sa-lifetime-hard>
<!--AUTH_HMAC_SHA2_512_256-->
<ike-sa-intr-alg>14</ike-sa-intr-alg>
<!--ENCR_AES_CBC - 128 bits-->
<ike-sa-encr-alg>
<id>1</id>
</ike-sa-encr-alg>
<!--8192-bit MODP Group-->
<dh-group>18</dh-group>
<half-open-ike-sa-timer>30</half-open-ike-sa-timer>
<half-open-ike-sa-cookie-threshold>
15
</half-open-ike-sa-cookie-threshold>
<local>
<local-pad-entry-name>nsf_h1_pad</local-pad-entry-name>
</local>
<remote>
<remote-pad-entry-name>nsf_h2_pad</remote-pad-entry-name>
</remote>
<spd>
<spd-entry>
<name>nsf_h1-nsf_h2</name>
<ipsec-policy-config>
<anti-replay-window-size>64</anti-replay-window-size>
<traffic-selector>
<local-prefix>2001:db8:1::0/64</local-prefix>
<remote-prefix>2001:db8:2::0/64</remote-prefix>
<inner-protocol>any</inner-protocol>
</traffic-selector>
<processing-info>
<action>protect</action>
<ipsec-sa-cfg>
<pfp-flag>false</pfp-flag>
<ext-seq-num>true</ext-seq-num>
<seq-overflow>false</seq-overflow>
<stateful-frag-check>false</stateful-frag-check>
<mode>tunnel</mode>
<protocol-parameters>esp</protocol-parameters>
<esp-algorithms>
<!-- AUTH_HMAC_SHA1_96 -->
<integrity>2</integrity>
<encryption>
<!-- ENCR_AES_CBC -->
<id>1</id>
<algorithm-type>12</algorithm-type>
<key-length>128</key-length>
</encryption>
<encryption>
<!-- ENCR_3DES-->
<id>2</id>
<algorithm-type>3</algorithm-type>
</encryption>
<tfc-pad>false</tfc-pad>
</esp-algorithms>
<tunnel>
<local>2001:db8:123::100</local>
<remote>2001:db8:123::200</remote>
<df-bit>clear</df-bit>
<bypass-dscp>true</bypass-dscp>
</tunnel>
</ipsec-sa-cfg>
</processing-info>
</ipsec-policy-config>
</spd-entry>
</spd>
<child-sa-info>
<!--8192-bit MODP Group -->
<fs-groups>18</fs-groups>
<child-sa-lifetime-soft>
<bytes>1000000</bytes>
<packets>1000</packets>
<time>30</time>
<idle>60</idle>
<action>replace</action>
</child-sa-lifetime-soft>
<child-sa-lifetime-hard>
<bytes>2000000</bytes>
<packets>2000</packets>
<time>60</time>
<idle>120</idle>
</child-sa-lifetime-hard>
</child-sa-info>
</conn-entry>
</ipsec-ike>
Appendix B. XML Configuration Example for IKE-less Case (Host-to-Host)
付録B. IKEレスケースのXML構成例（ホスト間）
This example shows an XML configuration file sent by the I2NSF Controller to establish an IPsec SA between two NSFs (see Figure 4) in transport mode (host-to-host) with ESP in the IKE-less case.
この例では、IKSFコントローラによって送信されたXML構成ファイルが、IKE-LESSケースではトランスポートモード（ホストからホスト）の2つのNSF（ホスト間）の間にIPsec SAを確立します。
+------------------+
| I2NSF Controller |
+------------------+
I2NSF NSF-Facing |
Interface |
/--------------------+-------------------\
/ \
/ \
+--------+ +--------+
| nsf_h1 |===== IPsec_ESP_Transport_mode =====| nsf_h2 |
+--------+ +--------+
:100 (2001:db8:123:/64) :200
Figure 4: IKE-less Case, Transport Mode
図4：IKEレスケース、トランスポートモード
<ipsec-ikeless
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<spd>
<spd-entry>
<name>
in/trans/2001:db8:123::200/2001:db8:123::100
</name>
<direction>inbound</direction>
<reqid>1</reqid>
<ipsec-policy-config>
<traffic-selector>
<local-prefix>2001:db8:123::200/128</local-prefix>
<remote-prefix>2001:db8:123::100/128</remote-prefix>
<inner-protocol>any</inner-protocol>
</traffic-selector>
<processing-info>
<action>protect</action>
<ipsec-sa-cfg>
<ext-seq-num>true</ext-seq-num>
<seq-overflow>false</seq-overflow>
<mode>transport</mode>
<protocol-parameters>esp</protocol-parameters>
<esp-algorithms>
<!--AUTH_HMAC_SHA1_96-->
<integrity>2</integrity>
<!--ENCR_AES_CBC -->
<encryption>
<id>1</id>
<algorithm-type>12</algorithm-type>
<key-length>128</key-length>
</encryption>
<encryption>
<id>2</id>
<algorithm-type>3</algorithm-type>
</encryption>
</esp-algorithms>
</ipsec-sa-cfg>
</processing-info>
</ipsec-policy-config>
</spd-entry>
<spd-entry>
<name>out/trans/2001:db8:123::100/2001:db8:123::200</name>
<direction>outbound</direction>
<reqid>1</reqid>
<ipsec-policy-config>
<traffic-selector>
<local-prefix>2001:db8:123::100/128</local-prefix>
<remote-prefix>2001:db8:123::200/128</remote-prefix>
<inner-protocol>any</inner-protocol>
</traffic-selector>
<processing-info>
<action>protect</action>
<ipsec-sa-cfg>
<ext-seq-num>true</ext-seq-num>
<seq-overflow>false</seq-overflow>
<mode>transport</mode>
<protocol-parameters>esp</protocol-parameters>
<esp-algorithms>
<!-- AUTH_HMAC_SHA1_96 -->
<integrity>2</integrity>
<!-- ENCR_AES_CBC -->
<encryption>
<id>1</id>
<algorithm-type>12</algorithm-type>
<key-length>128</key-length>
</encryption>
<encryption>
<id>2</id>
<algorithm-type>3</algorithm-type>
</encryption>
</esp-algorithms>
</ipsec-sa-cfg>
</processing-info>
</ipsec-policy-config>
</spd-entry>
</spd>
<sad>
<sad-entry>
<name>out/trans/2001:db8:123::100/2001:db8:123::200</name>
<reqid>1</reqid>
<ipsec-sa-config>
<spi>34501</spi>
<ext-seq-num>true</ext-seq-num>
<seq-overflow>false</seq-overflow>
<anti-replay-window-size>64</anti-replay-window-size>
<traffic-selector>
<local-prefix>2001:db8:123::100/128</local-prefix>
<remote-prefix>2001:db8:123::200/128</remote-prefix>
<inner-protocol>any</inner-protocol>
</traffic-selector>
<protocol-parameters>esp</protocol-parameters>
<mode>transport</mode>
<esp-sa>
<encryption>
<!-- //ENCR_AES_CBC -->
<encryption-algorithm>12</encryption-algorithm>
<key>01:23:45:67:89:AB:CE:DF</key>
<iv>01:23:45:67:89:AB:CE:DF</iv>
</encryption>
<integrity>
<!-- //AUTH_HMAC_SHA1_96 -->
<integrity-algorithm>2</integrity-algorithm>
<key>01:23:45:67:89:AB:CE:DF</key>
</integrity>
</esp-sa>
</ipsec-sa-config>
</sad-entry>
<sad-entry>
<name>in/trans/2001:db8:123::200/2001:db8:123::100</name>
<reqid>1</reqid>
<ipsec-sa-config>
<spi>34502</spi>
<ext-seq-num>true</ext-seq-num>
<seq-overflow>false</seq-overflow>
<anti-replay-window-size>64</anti-replay-window-size>
<traffic-selector>
<local-prefix>2001:db8:123::200/128</local-prefix>
<remote-prefix>2001:db8:123::100/128</remote-prefix>
<inner-protocol>any</inner-protocol>
</traffic-selector>
<protocol-parameters>esp</protocol-parameters>
<mode>transport</mode>
<esp-sa>
<encryption>
<!-- //ENCR_AES_CBC -->
<encryption-algorithm>12</encryption-algorithm>
<key>01:23:45:67:89:AB:CE:DF</key>
<iv>01:23:45:67:89:AB:CE:DF</iv>
</encryption>
<integrity>
<!-- //AUTH_HMAC_SHA1_96 -->
<integrity-algorithm>2</integrity-algorithm>
<key>01:23:45:67:89:AB:CE:DF</key>
</integrity>
</esp-sa>
<sa-lifetime-hard>
<bytes>2000000</bytes>
<packets>2000</packets>
<time>60</time>
<idle>120</idle>
</sa-lifetime-hard>
<sa-lifetime-soft>
<bytes>1000000</bytes>
<packets>1000</packets>
<time>30</time>
<idle>60</idle>
<action>replace</action>
</sa-lifetime-soft>
</ipsec-sa-config>
</sad-entry>
</sad>
</ipsec-ikeless>
In the following, several XML files are shown to illustrate different types of notifications defined in the IKE-less YANG data model, which are sent by the NSF to the I2NSF Controller. The notifications happen in the IKE-less case.
以下では、いくつかのXMLファイルが示されており、NSFによってI2NSFコントローラに送信されるIKEレスヤンデータモデルで定義されているさまざまなタイプの通知を説明することが示されています。通知はIKE-LESSケースで発生します。
<sadb-expire xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless">
<ipsec-sa-name>in/trans/2001:db8:123::200/2001:db8:123::100
</ipsec-sa-name>
<soft-lifetime-expire>true</soft-lifetime-expire>
<lifetime-current>
<bytes>1000000</bytes>
<packets>1000</packets>
<time>30</time>
<idle>60</idle>
</lifetime-current>
</sadb-expire>
Figure 5: Example of the sadb-expire Notification
図5：SADB期限通知の例
<sadb-acquire xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless">
<ipsec-policy-name>in/trans/2001:db8:123::200/2001:db8:123::100
</ipsec-policy-name>
<traffic-selector>
<local-prefix>2001:db8:123::200/128</local-prefix>
<remote-prefix>2001:db8:123::100/128</remote-prefix>
<inner-protocol>any</inner-protocol>
<local-ports>
<start>0</start>
<end>0</end>
</local-ports>
<remote-ports>
<start>0</start>
<end>0</end>
</remote-ports>
</traffic-selector>
</sadb-acquire>
Figure 6: Example of the sadb-acquire Notification
図6：SADB-獲得通知の例
<sadb-seq-overflow
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless">
<ipsec-sa-name>in/trans/2001:db8:123::200/2001:db8:123::100
</ipsec-sa-name>
</sadb-seq-overflow>
Figure 7: Example of the sadb-seq-overflow Notification
図7：SADB-SEQオーバーフロー通知の例
<sadb-bad-spi
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless">
<spi>666</spi>
</sadb-bad-spi>
Figure 8: Example of the sadb-bad-spi Notification
図8：SADB-BAD-SPI通知の例
This appendix exemplifies the applicability of the IKE case and IKE-less case to traditional IPsec configurations, that is, host-to-host and gateway-to-gateway. The following examples assume the existence of two NSFs needing to establish an end-to-end IPsec SA to protect their communications. Both NSFs could be two hosts that exchange traffic (host-to-host) or gateways (gateway-to-gateway), for example, within an enterprise that needs to protect the traffic between the networks of two branch offices.
この付録は、IKEケースとIKEレスケースの従来のIPSec構成、つまりホスト間およびゲートウェイからゲートウェイへの適用可能性を例示しています。次の例では、コミュニケーションを保護するためにエンドツーエンドのIPSec SAを確立する必要がある2つのNSFの存在を想定しています。両方のNSFは、2つのブランチオフィスのネットワーク間のトラフィックを保護する必要がある企業内で、トラフィック（ホスト間）またはゲートウェイ（ゲートウェイからゲートウェイ）を交換する2つのホストであり得る。
Applicability of these configurations appear in current and new networking scenarios. For example, SD-WAN technologies are providing dynamic and on-demand VPN connections between branch offices or between branches and Software as a Service (SaaS) cloud services. Besides, Infrastructure as a Service (IaaS) services providing virtualization environments are deployments that often rely on IPsec to provide secure channels between virtual instances (host-to-host) and providing VPN solutions for virtualized networks (gateway-to-gateway).
これらの構成の適用性は、現在および新しいネットワークシナリオに表示されます。たとえば、SD-WANテクノロジは、ブランチオフィス間またはブランチとソフトウェア間の動的でオンデマンドのVPN接続をサービス（SAAS）クラウドサービスとして提供しています。その上、仮想化環境を提供するサービス（IAAS）サービスとしてのインフラストラクチャは、仮想インスタンス間の安全なチャネル（ホスト間）を提供し、仮想化ネットワーク（ゲートウェイからゲートウェイ）のVPNソリューションを提供するためにIPsecに依存する展開です。
As can be observed in the following, the I2NSF-based IPsec management system (for IKE and IKE-less cases) exhibits various advantages:
以下で観察できるように、I2NSFベースのIPsecマネジメントシステム（IKEおよびIKE専用ケース用）はさまざまな利点を示します。
1. It allows creating IPsec SAs among two NSFs, based only on the application of general flow-based protection policies at the I2NSF User. Thus, administrators can manage all security associations in a centralized point with an abstracted view of the network.
1. I2NSFユーザーの一般的なフローベースの保護ポリシーのアプリケーションのみに基づいて、2つのNSFの間でIPSec SAを作成できます。したがって、管理者はネットワークの抽象化されたビューを持つ集中ポイント内のすべてのセキュリティアソシエーションを管理できます。
2. Any NSF deployed in the system does not need manual configuration, therefore, allowing its deployment in an automated manner.
2. システムに展開されているNSFはすべて手動の設定を必要とせず、自動化された方法での展開を可能にします。
+----------------------------------------+
| I2NSF User (IPsec Management System) |
+----------------------------------------+
|
(1) Flow-based I2NSF Consumer-Facing
Protection Policy Interface
|
+---------|------------------------------+
| | |
| | I2NSF Controller |
| V |
| +--------------+ (2)+--------------+ |
| |Translate into|--->| NETCONF/ | |
| |IPsec Policies| | RESTCONF | |
| +--------------+ +--------------+ |
| | | |
| | | |
+--------------------------|-----|-------+
| |
I2NSF NSF-Facing Interface | |
| (3) |
|-------------------------+ +---|
V V
+----------------------+ +----------------------+
| NSF A | | NSF B |
| IKEv2/IPsec(SPD/PAD) | | IKEv2/IPsec(SPD/PAD) |
+----------------------+ +----------------------+
Figure 9: Host-to-Host/Gateway-to-Gateway for the IKE Case
図9：IKEケースのホスト間/ゲートウェイからゲートウェイへ
Figure 9 describes the application of the IKE case when a data packet needs to be protected in the path between NSF A and NSF B:
図9は、データパケットをNSF AとNSF Bの間の経路で保護する必要がある場合のIKEケースの適用について説明しています。
1. The I2NSF User defines a general flow-based protection policy (e.g., protect data traffic between NSF A and B). The I2NSF Controller looks for the NSFs involved (NSF A and NSF B).
1. I2NSFユーザーは、一般的なフローベースの保護ポリシー（例えば、NSF AとBの間のデータトラフィックの保護）を定義します。I2NSFコントローラは、関与するNSF（NSF AとNSF B）を探します。
2. The I2NSF Controller generates IKEv2 credentials for them and translates the policies into SPD and PAD entries.
2. I2NSFコントローラは、IKEv2認証情報を生成し、ポリシーをSPDエントリとパッドエントリに変換します。
3. The I2NSF Controller inserts an IKEv2 configuration that includes the SPD and PAD entries in both NSF A and NSF B. If some of operations with NSF A and NSF B fail, the I2NSF Controller will stop the process and perform a rollback operation by deleting any IKEv2, SPD, and PAD configuration that had been successfully installed in NSF A or B.
3. I2NSFコントローラは、NSF AとNSF Bの両方のSPDエントリとパッドエントリを含むIKEv2構成を挿入します.NSF AとNSF Bを使用した操作の一部が失敗した場合、I2NSFコントローラはプロセスを停止し、IKEv2を削除してロールバック操作を実行します。NSF AまたはBに正常にインストールされたSPD、およびPAD構成
If the previous steps are successful, the flow is protected by means of the IPsec SA established with IKEv2 between NSF A and NSF B.
前のステップが成功した場合、フローはNSF AとNSF Bの間のIKEV2で確立されたIPsec SAによって保護されます。
+----------------------------------------+
| I2NSF User (IPsec Management System) |
+----------------------------------------+
|
(1) Flow-based I2NSF Consumer-Facing
Protection Policy Interface
|
+---------|------------------------------+
| | |
| | I2NSF Controller |
| V |
| +--------------+ (2) +--------------+ |
| |Translate into|---->| NETCONF/ | |
| |IPsec Policies| | RESTCONF | |
| +--------------+ +--------------+ |
| | | |
+-------------------------|-----|--------+
| |
I2NSF NSF-Facing Interface | |
| (3) |
|----------------------+ +--|
V V
+----------------+ +----------------+
| NSF A | | NSF B |
| IPsec(SPD/SAD) | | IPsec(SPD/SAD) |
+----------------+ +----------------+
Figure 10: Host-to-Host/Gateway-to-Gateway for the IKE-less Case
図10：IKEレスケースのホスト間/ゲートウェイからゲートウェイへ
Figure 10 describes the application of the IKE-less case when a data packet needs to be protected in the path between NSF A and NSF B:
図10は、データパケットがNSF AとNSF Bの間の経路で保護される必要がある場合のIKE遅いケースのアプリケーションを示しています。
1. The I2NSF User establishes a general flow-based protection policy, and the I2NSF Controller looks for the involved NSFs.
1. I2NSFユーザーは一般的なフローベースの保護ポリシーを確立し、I2NSFコントローラは関与するNSFSを探します。
2. The I2NSF Controller translates the flow-based security policies into IPsec SPD and SAD entries.
2. I2NSFコントローラは、フローベースのセキュリティポリシーをIPSec SPDおよびSADエントリに変換します。
3. The I2NSF Controller inserts these entries in both NSF A and NSF B IPsec databases (i.e., SPD and SAD). The following text describes how this would happen:
3. I2NSFコントローラは、これらのエントリをNSF AとNSF B IPSecデータベースの両方に挿入します（すなわち、SPDとSAD）。次のテキストは、これがどのように起こるかについて説明します。
* The I2NSF Controller chooses two random values as SPIs, for example, SPIa1 for the inbound IPsec SA in NSF A and SPIb1 for the inbound IPsec SA in NSF B. The value of the SPIa1 MUST NOT be the same as any inbound SPI in A. In the same way, the value of the SPIb1 MUST NOT be the same as any inbound SPI in B. Moreover, the SPIa1 MUST be used in B for the outbound IPsec SA to A, while SPIb1 MUST be used in A for the outbound IPsec SA to B. It also generates fresh cryptographic material for the new inbound/outbound IPsec SAs and their parameters.
* I2NSFコントローラは、SPISとして2つのランダムな値、NSF AのIPSEC SAのSPIA1、NSF BのインバウンドIPsec SAのSPIB1などの2つのランダムな値を選択します.SPIA1の値は、AのインバウンドSPIと同じである必要はありません。同様に、SPIB1の値はB内のインバウンドSPIと同じにしてはいけません。さらに、SPIA1はAUTBOUND IPSEC SAにBでは使用されますが、SPIB1はアウトバウンドIPsecで使用する必要があります。SAからB.それはまた、新しいインバウンド/アウトバウンドIPSec SASおよびそれらのパラメータのための新鮮な暗号化された材料を生成します。
* After that, the I2NSF Controller simultaneously sends the new inbound IPsec SA with SPIa1 and new outbound IPsec SA with SPIb1 to NSF A and the new inbound IPsec SA with SPIb1 and new outbound IPsec SA with SPIa1 to B, together with the corresponding IPsec policies.
* その後、I2NSFコントローラは、SPIA1をSPIA1と新しいアウトバウンドIPSEC SAと同時にSPIB1とSPIB1と新しい受信IPsec SAとともにSPIB1と新しいアウトバウンドIPsec SAとともに、対応するIPSecポリシーと一緒にSPIB1と新しいアウトバウンドIPSec SAを送信します。
* Once the I2NSF Controller receives confirmation from NSF A and NSF B, it knows that the IPsec SAs are correctly installed and ready.
* I2NSFコントローラがNSF AおよびNSF Bからの確認を受けたら、IPSec SASが正しくインストールされていることを知っています。
Another alternative to this operation is the I2NSF Controller first sends the IPsec policies and new inbound IPsec SAs to A and B. Once it obtains a successful confirmation of these operations from NSF A and NSF B, it proceeds with installing the new outbound IPsec SAs. Even though this procedure may increase the latency to complete the process, no traffic is sent over the network until the IPsec SAs are completely operative. In any case, other alternatives MAY be possible to implement step 3.
この操作のもう1つの代替手段は、I2NSFコントローラが最初にIPsecポリシーと新しいインバウンドIPSec SASをAとBに送信します.NSF AとNSF Bからのこれらの操作の確認が成功したら、新しいアウトバウンドIPSec SASのインストールを進めます。この手順が待ち時間を増加させてプロセスを完了することができる場合でも、IPsec SASが完全に動作するまでトラフィックはネットワーク上で送信されません。いずれにせよ、ステップ3を実施することが可能であり得る。
4. If some of the operations described above fail (e.g., NSF A reports an error when the I2NSF Controller is trying to install the SPD entry, the new inbound or outbound IPsec SAs), the I2NSF Controller MUST perform rollback operations by deleting any new inbound or outbound IPsec SA and SPD entry that had been successfully installed in any of the NSFs (e.g., NSF B) and stop the process. Note that the I2NSF Controller MAY retry several times before giving up.
4. 上記の操作のいくつかが失敗した場合（たとえば、I2NSFコントローラがSPDエントリまたはアウトバウンドIPSec SASをインストールしようとしているときにエラーが報告されている場合）、I2NSFコントローラは新しいインバウンドを削除してROLLBACK操作を実行する必要があります。NSF（例：NSF B）のいずれかに正常にインストールされた送信IPsec SAおよびSPDエントリ。I2NSFコントローラがあきらめる前に数回再試行することがあります。
5. Otherwise, if the steps 1 to 3 are successful, the flow between NSF A and NSF B is protected by means of the IPsec SAs established by the I2NSF Controller. It is worth mentioning that the I2NSF Controller associates a lifetime to the new IPsec SAs. When this lifetime expires, the NSF will send a sadb-expire notification to the I2NSF Controller in order to start the rekeying process.
5. それ以外の場合、ステップ1から3が成功した場合、NSF AとNSF Bの間のフローはI2NSFコントローラによって確立されたIPsec SAによって保護されます。I2NSFコントローラが寿命を新しいIPSec SASに関連付けることを言及する価値があります。この寿命が期限切れになると、NSFは、Rekeingプロセスを開始するために、I2NSFコントローラにSADB-EFFIRE通知を送信します。
Instead of installing IPsec policies (in the SPD) and IPsec SAs (in the SAD) in step 3 (proactive mode), it is also possible that the I2NSF Controller only installs the SPD entries in step 3 (reactive mode). In such a case, when a data packet requires to be protected with IPsec, the NSF that first saw the data packet will send a sadb-acquire notification that informs the I2NSF Controller that needs SAD entries with the IPsec SAs to process the data packet. Again, if some of the operations installing the new inbound/outbound IPsec SAs fail, the I2NSF Controller stops the process and performs a rollback operation by deleting any new inbound/outbound SAs that had been successfully installed.
ステップ3（Proactive Mode）でIPSecポリシー（SPD）とIPSec SAS（SAD）をインストールする代わりに、I2NSFコントローラがステップ3（Reactive Mode）でSPDエントリをインストールすることも可能です。そのような場合、データパケットをIPsecで保護する必要がある場合、最初にデータパケットがデータパケットを処理するためのSADエントリを必要とするSADB-Acquire通知を送信するNSFを送信します。繰り返しになりますが、新しいインバウンド/アウトバウンドIPSec SASをインストールする操作の中には、I2NSFコントローラはプロセスを停止し、正常にインストールされた新しいインバウンド/アウトバウンドSAを削除してロールバック操作を実行します。
To explain an example of the rekeying process between two IPsec NSFs, A and B, assume that SPIa1 identifies the inbound IPsec SA in A and SPIb1 identifies the inbound IPsec SA in B. The rekeying process will take the following steps:
2つのIPSEC NSFS、AとBの間の生後処理の例を説明するために、SPIa1がAとSPIB1でINBOUND IPSEC SAを識別していると仮定します。
1. The I2NSF Controller chooses two random values as SPI for the new inbound IPsec SAs, for example, SPIa2 for the inbound IPsec SA in A and SPIb2 for the inbound IPsec SA in B. The value of the SPIa1 MUST NOT be the same as any inbound SPI in A. In the same way, the value of the SPIb1 MUST NOT be the same as any inbound SPI in B. Then, the I2NSF Controller creates an inbound IPsec SA with SPIa2 in A and another inbound IPsec SA in B with SPIb2. It can send this information simultaneously to A and B.
1. I2NSFコントローラは、BのIPSEC SAのインバウンドIPSec SAのSPIA2のSPIとして2つのランダムな値を選択します.SPIA1の値は、インバウンドと同じにしてはいけません。A. SPIと同じように、SPIB1の値はBのインバウンドSPIと同じにしてはいけません。その後、I2NSFコントローラは、SPIB2のAと他のインバウンドIPsec SAのSPIA2とインバウンドIPSEC SAを作成します。AとBにこの情報を同時に送信できます。
2. Once the I2NSF Controller receives confirmation from A and B, the controller knows that the inbound IPsec SAs are correctly installed. Then, it proceeds to send, in parallel to A and B, the outbound IPsec SAs: the outbound IPsec SA to A with SPIb2 and the outbound IPsec SA to B with SPIa2. At this point, the new IPsec SAs are ready.
2. I2NSFコントローラがAとBから確認を受けたら、コントローラはインバウンドIPSec SASが正しくインストールされていることを認識しています。その後、AND BOUND IPSEC SA：SPIB2とアウトバウンドIPsec SAからSPIA2を持つアウトバウンドIPSec SAへの送信、およびBに送信されます。この時点で、新しいIPsec SASは準備ができています。
3. Once the I2NSF Controller receives confirmation from A and B that the outbound IPsec SAs have been installed, the I2NSF Controller, in parallel, deletes the old IPsec SAs from A (inbound SPIa1 and outbound SPIb1) and B (outbound SPIa1 and inbound SPIb1).
3. I2NSFコントローラがAとBからの確認を受信すると、アウトバウンドIPsec SASがインストールされていることが、I2NSFコントローラが並行して、A（Inbound Spia1とアウトバウンドSPIB1）とB（アウトバウンドSPIA1とインバウンドSPIB1）から古いIPSec SASを削除します。
If some of the operations in step 1 fail (e.g., NSF A reports an error when the I2NSF Controller is trying to install a new inbound IPsec SA), the I2NSF Controller MUST perform rollback operations by removing any new inbound SA that had been successfully installed during step 1.
ステップ1の操作の中に失敗した場合（NSF Aは、I2NSFコントローラが新しいインバウンドIPSec SAのインストールしようとしているときにエラーを報告する）場合、I2NSFコントローラは、正常にインストールされた新しいインバウンドSAを削除することによってロールバック操作を実行する必要があります。ステップ1の間に。
If step 1 is successful but some of the operations in step 2 fail (e.g., NSF A reports an error when the I2NSF Controller is trying to install the new outbound IPsec SA), the I2NSF Controller MUST perform a rollback operation by deleting any new outbound SA that had been successfully installed during step 2 and by deleting the inbound SAs created in step 1, in that order.
ステップ1が成功したが、ステップ2のいくつかの操作が失敗した場合（例えば、I2NSFコントローラが新しいアウトバウンドIPSec SAのインストールを試みているときにエラーが発生した場合）、I2NSFコントローラは新しいアウトバウンドを削除することによってロールバック操作を実行する必要があります。ステップ2の間に、およびステップ1で作成されたインバウンドSAをその順に削除することによって、正常にインストールされたSA。
If the steps 1 and 2 are successful but the step 3 fails, the I2NSF Controller will avoid any rollback of the operations carried out in steps 1 and 2, since new and valid IPsec SAs were created and are functional. The I2NSF Controller MAY reattempt to remove the old inbound and outbound IPsec SAs in NSF A and NSF B several times until it receives a success or it gives up. In the last case, the old IPsec SAs will be removed when their corresponding hard lifetime is reached.
手順1と2が成功したがステップ3に障害が発生した場合、I2NSFコントローラは、新規および有効なIPSec SASが作成され、機能的であるため、ステップ1および2で実行された操作のロールバックを回避します。I2NSFコントローラは、成功を受信するか、またはそれがあきらめるまで、NSF AおよびNSF Bの古いインバウンドおよびアウトバウンドIPSec SASを数回削除することができます。最後の場合、古いIPSec SASは対応するハードライフタイムに達すると削除されます。
In the IKE-less case, if the I2NSF Controller detects that an NSF has lost the IPsec state, it could follow the next steps:
IKE-LESSケースでは、I2NSFコントローラがNSFがIPSec状態を失ったことを検出した場合、次の手順に従うことができます。
1. The I2NSF Controller SHOULD delete the old IPsec SAs on the non-failed nodes, established with the failed node. This prevents the non-failed nodes from leaking plaintext.
1. I2NSFコントローラは、故障したノードで確立された故障したノード上の古いIPSec SASを削除する必要があります。これにより、故障していないノードが平文の漏洩を防ぎます。
2. If the affected node restarts, the I2NSF Controller configures the new inbound IPsec SAs between the affected node and all the nodes it was talking to.
2. 影響を受けるノードが再起動した場合、I2NSFコントローラは影響を受けるノードとそれが通話していたすべてのノードの間の新しいインバウンドIPSec SASを設定します。
3. After these inbound IPsec SAs have been established, the I2NSF Controller configures the outbound IPsec SAs in parallel.
3. これらのインバウンドIPSec SASが確立された後、I2NSFコントローラはアウトバウンドIPSec SASを並列に設定します。
Steps 2 and 3 can be performed at the same time at the cost of a potential packet loss. If this is not critical, then it is an optimization since the number of exchanges between the I2NSF Controller and NSFs is lower.
ステップ2および3は、潜在的なパケット損失のコストで同時に実行することができる。これが重要ではない場合は、I2NSFコントローラとNSFSの間の交換数が少なくなるため、最適化です。
Acknowledgements
謝辞
Authors want to thank Paul Wouters, Valery Smyslov, Sowmini Varadhan, David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham Bartlett, Sandeep Kampati, Linda Dunbar, Mohit Sethi, Martin Bjorklund, Tom Petch, Christian Hopps, Rob Wilton, Carlos J. Bernardos, Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Martinez, Ruben Ricart, and all IESG members that have reviewed this document for their valuable comments.
著者ら、Paul Wouters、Valery Smyslov、Sowmini Varadhan、David Carrel、David Carrel、Tero Kivinen、Martin Bjorklund、Sandeep Kampati、Linda Dunbar、Mohit Seth、Martin Bjorklund、Rob Wilton、CarlosJ. Bernardos、Alejandro Perez-Mendez、Alejandro Abad-Carrascosa、Ignacio Martinez、Ruben Ricart、および貴重なコメントのためにこの文書を検討したすべてのIESGメンバー。
Authors' Addresses
著者の住所
Rafa Marin-Lopez University of Murcia Faculty of Computer Science Campus de Espinardo S/N 30100 Murcia Spain
Rafa Marin-Lopez Murcia大学コンピュータサイエンス学部キャンパス・デ・エスピナルドS / N 30100ムルシアスペイン
Phone: +34 868 88 85 01
Email: rafa@um.es
Gabriel Lopez-Millan University of Murcia Faculty of Computer Science Campus de Espinardo S/N 30100 Murcia Spain
Gabriel Lopez-Millan University Campus de Espinardo S / N 30100ムルシアスペイン
Phone: +34 868 88 85 04
Email: gabilm@um.es
Fernando Pereniguez-Garcia University Defense Center Spanish Air Force Academy MDE-UPCT 30720 San Javier Murcia Spain
フェルナンドPereniguez-Garcia大学防衛センタースペイン語空軍アカデミーMDE-UPCT 30720 San Javier Murciaスペイン
Phone: +34 968 18 99 46
Email: fernando.pereniguez@cud.upct.es