[要約] RFC 6071は、IP Security (IPsec) と Internet Key Exchange (IKE) に関連する文書のロードマップを提供します。この文書の目的は、IPsecとIKEの実装と展開に関わる技術者や研究者が、関連する情報を簡単に見つけられるようにすることです。IPsecは、インターネットプロトコル（IP）通信のセキュリティを提供するための一連のプロトコルであり、IKEはIPsecで使用される鍵交換メカニズムです。利用場面には、VPNの構築、エンドツーエンドの通信の暗号化、認証などがあります。関連するRFCには、RFC 4301 (IPsecのセキュリティアーキテクチャ)、RFC 4302 (IP認証ヘッダ)、RFC 4303 (IP暗号化ペイロード)、RFC 7296 (IKEv2の仕様) などが含まれます。
Internet Engineering Task Force (IETF) S. Frankel
Request for Comments: 6071 NIST
Obsoletes: 2411 S. Krishnan
Category: Informational Ericsson
ISSN: 2070-1721 February 2011
IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap
IPセキュリティ（IPSEC）およびインターネットキーエクスチェンジ（IKE）ドキュメントロードマップ
Abstract
概要
Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic.
過去数年にわたって、IPSECおよびInternet Key Exchange（IKE）を定義および使用するRFCの数は大幅に増殖しました。これは、これらのRFCが多数のIETFワーキンググループに由来するという事実によって複雑になっています。元のIPSEC WG、そのさまざまなスピンオフ、およびIPSECおよび/またはIKEを使用してプロトコルのトラフィックを保護する他のWG。
This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IP Security Document Roadmap."
このドキュメントは、IPSECおよびIKE関連のRFCのスナップショットです。各RFCの簡単な説明と、IPSECの拡張と拡張の動機とコンテキストを説明する背景情報が含まれています。以前の「IPセキュリティドキュメントロードマップ」であるRFC 2411を廃止します。
The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents. The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms.
廃止されたIPSECロードマップ（RFC 2411）は、さまざまなクラスのベースIPSECドキュメントの相互関係を簡単に説明しました。RFC 2411の主な焦点は、追加の暗号化と認証アルゴリズムを指定するドキュメントの推奨コンテンツを指定することでした。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6071.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6071で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
2. IPsec/IKE Background Information ................................5
2.1. Interrelationship of IPsec/IKE Documents ...................5
2.2. Versions of IPsec ..........................................6
2.2.1. Differences between "Old" IPsec (IPsec-v2) and
"New" IPsec (IPsec-v3) ..............................6
2.3. Versions of IKE ............................................7
2.3.1. Differences between IKEv1 and IKEv2 .................8
2.4. IPsec and IKE IANA Registries ..............................9
3. IPsec Documents .................................................9
3.1. Base Documents .............................................9
3.1.1. "Old" IPsec (IPsec-v2) ..............................9
3.1.2. "New" IPsec (IPsec-v3) .............................11
3.2. Additions to IPsec ........................................11
3.3. General Considerations ....................................14
4. IKE Documents ..................................................15
4.1. Base Documents ............................................15
4.1.1. IKEv1 ..............................................15
4.1.2. IKEv2 ..............................................16
4.2. Additions and Extensions ..................................17
4.2.1. Peer Authentication Methods ........................17
4.2.2. Certificate Contents and Management (PKI4IPsec) ....18
4.2.3. Dead Peer Detection ................................19
4.2.4. Remote Access ......................................19
5. Cryptographic Algorithms and Suites ............................21
5.1. Algorithm Requirements ....................................22
5.2. Encryption Algorithms .....................................23
5.3. Integrity-Protection (Authentication) Algorithms ..........27
5.4. Combined Mode Algorithms ..................................30
5.5. Pseudo-Random Functions (PRFs) ............................33
5.6. Cryptographic Suites ......................................34
5.7. Diffie-Hellman Algorithms .................................35
6. IPsec/IKE for Multicast ........................................36
7. Outgrowths of IPsec/IKE ........................................38
7.1. IPsec Policy ..............................................38
7.2. IPsec MIBs ................................................39
7.3. IPComp (Compression) ......................................39
7.4. Better-Than-Nothing Security (BTNS) .......................39
7.5. Kerberized Internet Negotiation of Keys (KINK) ............40
7.6. IPsec Secure Remote Access (IPSRA) ........................41
7.7. IPsec Keying Information Resource Record (IPSECKEY) .......42
8. Other Protocols That Use IPsec/IKE .............................42
8.1. Mobile IP (MIPv4 and MIPv6) ...............................42
8.2. Open Shortest Path First (OSPF) ...........................44
8.3. Host Identity Protocol (HIP) ..............................45
8.4. Stream Control Transmission Protocol (SCTP) ...............46
8.5. Robust Header Compression (ROHC) ..........................46
8.6. Border Gateway Protocol (BGP) .............................47
8.7. IPsec Benchmarking ........................................47
8.8. Network Address Translators (NAT) .........................48
8.9. Session Initiation Protocol (SIP) .........................48
8.10. Explicit Packet Sensitivity Labels .......................49
9. Other Protocols That Adapt IKE for Non-IPsec Functionality .....49
9.1. Extensible Authentication Protocol (EAP) ..................49
9.2. Fibre Channel .............................................49
9.3. Wireless Security .........................................50
10. Acknowledgements ..............................................50
11. Security Considerations .......................................50
12. References ....................................................50
12.1. Informative References ...................................50
Appendix A. Summary of Algorithm Requirement Levels ..............61
IPsec (Internet Protocol Security) is a suite of protocols that provides security to Internet communications at the IP layer. The most common current use of IPsec is to provide a Virtual Private Network (VPN), either between two locations (gateway-to-gateway) or between a remote user and an enterprise network (host-to-gateway); it can also provide end-to-end, or host-to-host, security. IPsec is also used by other Internet protocols (e.g., Mobile IP version 6 (MIPv6)) to protect some or all of their traffic. IKE (Internet Key Exchange) is the key negotiation and management protocol that is most commonly used to provide dynamically negotiated and updated keying material for IPsec. IPsec and IKE can be used in conjunction with both IPv4 and IPv6.
IPSEC（インターネットプロトコルセキュリティ）は、IPレイヤーでのインターネット通信にセキュリティを提供するプロトコルスイートです。IPSECの最も一般的な現在の使用は、2つの場所（ゲートウェイツーゲートウェイ）の間、またはリモートユーザーとエンタープライズネットワーク（ホストツーゲートウェイ）の間の仮想プライベートネットワーク（VPN）を提供することです。また、エンドツーエンド、またはホストツーホストのセキュリティを提供することもできます。IPSECは、トラフィックの一部またはすべてを保護するために、他のインターネットプロトコル（モバイルIPバージョン6（MIPV6）など）でも使用されます。IKE（Internet Key Exchange）は、IPSECの動的にネゴシエートおよび更新されたキーイング資料を提供するために最も一般的に使用される主要な交渉および管理プロトコルです。IPSECとIKEは、IPv4とIPv6の両方と組み合わせて使用できます。
In addition to the base documents for IPsec and IKE, there are numerous RFCs that reference, extend, and in some cases alter the core specifications. This document obsoletes [RFC2411]. It attempts to list and briefly describe those RFCs, providing context and rationale where indicated. The title of each RFC is followed by a letter that indicates its category in the RFC series [RFC2026], as follows:
IPSECおよびIKEのベースドキュメントに加えて、参照、拡張、および場合によってはコア仕様を変更する多数のRFCがあります。この文書は廃止[RFC2411]。これらのRFCをリストし、簡単に説明しようとし、示されている場合にコンテキストと理論的根拠を提供します。各RFCのタイトルの後に、次のように、RFCシリーズ[RFC2026]のカテゴリを示すレターが続きます。
o S: Standards Track (Proposed Standard, Draft Standard, or Standard)
o S：標準トラック（提案された標準、ドラフト標準、または標準）
o E: Experimental
o E：実験
o B: Best Current Practice
o B：現在の最高の練習
o I: Informational
o I：情報
For each RFC, the publication date is also given.
各RFCについて、公開日も与えられます。
This document also categorizes the requirements level of each cryptographic algorithm for use with IKEv1, IKEv2, IPsec-v2, and IPsec-v3. These requirements are summarized in Appendix A. These levels are current as of February 2011; subsequent RFCs may result in altered requirement levels.
このドキュメントは、IKEV1、IKEV2、IPSEC-V2、およびIPSEC-V3で使用する各暗号化アルゴリズムの要件レベルも分類しています。これらの要件は、付録Aにまとめられています。これらのレベルは2011年2月の時点で最新です。その後のRFCは、要件レベルが変更される可能性があります。
This document does not define requirement levels; it simply restates those found in the IKE and IPsec RFCs. If there is a conflict between this document and any other RFC, then the other RFC takes precedence.
このドキュメントは要件レベルを定義しません。IKEおよびIPSEC RFCSで見つかったものを単に修正します。このドキュメントと他のRFCの間に競合がある場合、他のRFCが優先されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The main documents describing the set of IPsec protocols are divided into seven groups. This is illustrated in Figure 1. There is a main Architecture document that broadly covers the general concepts, security requirements, definitions, and mechanisms defining IPsec technology.
IPSECプロトコルのセットを説明する主なドキュメントは、7つのグループに分けられます。これを図1に示します。一般的な概念、セキュリティ要件、定義、およびIPSECテクノロジーを定義するメカニズムを広くカバーする主要なアーキテクチャドキュメントがあります。
There are an Encapsulating Security Payload (ESP) Protocol document and an Authentication Header (AH) Protocol document that cover the packet format and general issues regarding the respective protocols. The "Encryption Algorithm" document set, shown on the left, is the set of documents describing how various encryption algorithms are used for ESP. The "Combined Algorithm" document set, shown in the middle, is the set of documents describing how various combined mode algorithms are used to provide both encryption and integrity protection for ESP. The "Integ-Protection Algorithm" document set, shown on the right, is the set of documents describing how various integrity-protection algorithms are used for both ESP and AH.
セキュリティペイロード（ESP）プロトコルドキュメントと、それぞれのプロトコルに関するパケット形式と一般的な問題をカバーする認証ヘッダー（AH）プロトコルドキュメントがあります。左に示されている「暗号化アルゴリズム」ドキュメントセットは、ESPにさまざまな暗号化アルゴリズムがどのように使用されるかを説明するドキュメントのセットです。中央に示されている「組み合わせたアルゴリズム」ドキュメントセットは、ESPの暗号化と整合性保護の両方を提供するためにさまざまな複合モードアルゴリズムを使用する方法を説明するドキュメントのセットです。右側に示されている「INTEG保護アルゴリズム」ドキュメントセットは、ESPとAHの両方でさまざまな整合性保護アルゴリズムがどのように使用されるかを説明するドキュメントのセットです。
The "IKE" documents, shown at the bottom, are the documents describing the IETF Standards-Track key management schemes.
下部に示されている「IKE」ドキュメントは、IETF標準トラックキー管理スキームを説明するドキュメントです。
+--------------+
| Architecture |
+--------------+
v v
+<-<-<-<-<-<-<-<-+ +->->->->->->->->+
v v
+----------+ +----------+
| ESP | | AH |
| Protocol | | Protocol |
+----------+ +----------+
v v v v
v +->->->->->->->->+->->->->->->->->+ v v
v v v v v v
v v v v v v
v +------------+ +-----------+ +----------------+ v
v | +------------+ | +------------+ | +----------------+ v
v | | Encryption | | | Combined | | |Integ-Protection| v
v +-| Algorithm | +-| Algorithm | +-| Algorithm | v
v +------------+ +------------+ +----------------+ v
v v v v v
v v v v v
+>->->->-+->->->->->->->->->--<-<-<-<-<-<-<-<-<-+-<-<-<-<-+
^
^
+------------+
| IKE |
| Protocol |
+------------+
Figure 1. IPsec/IKE Document Interrelationships
図1. IPSEC/IKEドキュメント相互関係
Two versions of IPsec can currently be found in implementations. The "new" IPsec (referred to as IPsec-v3 in this document; see Section 3.1.1 for the RFC descriptions) obsoleted the "old" IPsec (referred to as IPsec-v2 in this document; see Section 3.1.2 for the RFC descriptions); however, IPsec-v2 is still commonly found in operational use. In this document, when the unqualified term IPsec is used, it pertains to both versions of IPsec. An earlier version of IPsec (defined in RFCs 1825-1829), obsoleted by IPsec-v2, is not covered in this document.
IPSECの2つのバージョンは現在、実装にあります。「新しい」IPSEC（このドキュメントではIPSEC-V3と呼ばれます。RFCの説明についてはセクション3.1.1を参照）は、「古い」IPSEC（このドキュメントでIPSEC-V2と呼ばれます。セクション3.1.2を参照してください。RFC説明）;ただし、IPSEC-V2は依然として運用上の使用で一般的に見られます。このドキュメントでは、資格のない用語IPSECを使用すると、IPSECの両方のバージョンに関係します。IPSEC-V2で廃止されたIPSECの以前のバージョン（RFCS 1825-1829で定義）は、このドキュメントではカバーされていません。
2.2.1. Differences between "Old" IPsec (IPsec-v2) and "New" IPsec (IPsec-v3)
2.2.1. 「古い」IPSEC（IPSEC-V2）と「新しい」IPSEC（IPSEC-V3）の違い
IPsec-v3 incorporates "lessons learned" from implementation and operational experience with IPsec-v2 and its predecessor, IPsec-v1.
IPSEC-V3には、IPSEC-V2およびその前身であるIPSEC-V1を使用した実装と運用経験から「学んだ教訓」が組み込まれています。
Knowledge was gained about the barriers to IPsec deployment, the scenarios in which IPsec is most effective, and the requirements that needed to be added to IPsec to facilitate its use with other protocols. In addition, the documentation for IPsec-v3 clarifies and expands details that were underspecified or ambiguous in IPsec-v2.
IPSECの展開の障壁、IPSECが最も効果的であるシナリオ、および他のプロトコルでの使用を促進するためにIPSECに追加する必要がある要件について知識が得られました。さらに、IPSEC-V3のドキュメントは、IPSEC-V2で不十分なまたは曖昧な詳細を明確にし、拡張します。
Changes to the architecture document [RFC4301] include:
アーキテクチャドキュメントの変更[RFC4301]は次のとおりです。
o More detailed descriptions of IPsec processing, both unicast and multicast, and the interactions among the various IPsec databases
o ユニキャストとマルチキャストの両方のIPSEC処理のより詳細な説明、およびさまざまなIPSECデータベース間の相互作用
o In IPsec-v2, an SA (Security Association) is uniquely identified by a combination of the SPI (Security Parameters Index), protocol (ESP or AH) and the destination address. In IPsec-v3, a unicast SA is uniquely identified by the SPI and, optionally, by the protocol; a multicast SA is identified by a combination of the SPI and the destination address and, optionally, the source address.
o IPSEC-V2では、SA（セキュリティ協会）は、SPI（セキュリティパラメータインデックス）、プロトコル（ESPまたはAH）、および宛先アドレスの組み合わせによって一意に識別されます。IPSEC-V3では、ユニキャストSAはSPI、およびオプションではプロトコルによって一意に識別されます。マルチキャストSAは、SPIと宛先アドレス、およびオプションでソースアドレスの組み合わせによって識別されます。
o More flexible SPD (Security Policy Database) selectors, including ranges of values and ICMP message types as selectors
o より柔軟なSPD（セキュリティポリシーデータベース）セレクター、値の範囲とセレクターとしてのICMPメッセージタイプを含む
o Decorrelated (order-independent) SAD (Security Association Database) replaced the former ordered SAD
o 脱線（注文に依存しない）SAD（セキュリティ協会データベース）が前者の注文SADを置き換えた
o Extended sequence numbers (ESNs) were added
o 拡張シーケンス番号（ESN）が追加されました
o Mandatory algorithms defined in standalone document
o スタンドアロンドキュメントで定義された必須アルゴリズム
o AH [RFC4302] is mandatory to implement (MUST) in IPsec-v2, optional (MAY) in IPsec-v3
o AH [RFC4302]は、IPSEC-V2で実装（必須）、IPSEC-V3でオプション（5月）に実装することが必須です
Changes to ESP [RFC4303] include:
ESP [RFC4303]への変更は次のとおりです。
o Combined mode algorithms were added, necessitating changes to packet format and processing
o 組み合わせたモードアルゴリズムが追加されたため、パケット形式と処理の変更が必要です
o NULL authentication, mandatory (MUST) in ESP-v2, is optional (MAY) in ESP-v3
o null認証、ESP-V2の必須（必須）は、ESP-V3のオプション（5月）です
Two versions of IKE can currently be found in implementations. The "new" IKE (generally referred to as IKEv2) obsoleted the "old" IKE (generally referred to as IKEv1); however, IKEv1 is still commonly found in operational use. In this document, when the unqualified term IKE is used, it pertains to both versions of IKE.
IKEの2つのバージョンは現在、実装にあります。「新しい」IKE（一般にIKEV2と呼ばれる）は、「古い」IKE（一般にIKEV1と呼ばれる）を廃止しました。ただし、IKEV1は依然として運用上の使用で一般的に見られます。このドキュメントでは、資格のない用語IKEが使用される場合、IKEの両方のバージョンに関係します。
As with IPsec-v3, IKEv2 incorporates "lessons learned" from implementation and operational experience with IKEv1. Knowledge was gained about the barriers to IKE deployment, the scenarios in which IKE is most effective, and the requirements that needed to be added to IKE to facilitate its use with other protocols as well as in general-purpose use. The documentation for IKEv2 replaces multiple, at times contradictory, documents with a single document; it also clarifies and expands details that were underspecified or ambiguous in IKEv1.
IPSEC-V3と同様に、IKEV2には、IKEV1の実装と運用経験から「学んだ教訓」が組み込まれています。IKEの展開の障壁、IKEが最も効果的であるシナリオ、およびIKEに追加する必要があるシナリオについての知識が得られ、他のプロトコルでの使用を促進し、汎用の使用において使用しました。IKEV2のドキュメントは、複数の、時には矛盾したドキュメントを単一のドキュメントに置き換えます。また、IKEV1で不足している、または曖昧な詳細を明確にし、拡張します。
Once an IKE negotiation is successfully completed, the peers have established two pairs of one-way (inbound and outbound) SAs. Since IKE always negotiates pairs of SAs, the term "SA" is generally used to refer to a pair of SAs (e.g., an "IKE SA" or an "IPsec SA" is in reality a pair of one-way SAs). The first SA, the IKE SA, is used to protect IKE traffic. The second SA provides IPsec protection to data traffic between the peers and/or other devices for which the peers are authorized to negotiate. It is called the IPsec SA in IKEv1 and, in the IKEv2 RFCs, it is referred to variously as a CHILD_SA, a child SA, and an IPsec SA. This document uses the term "IPsec SA". To further complicate the terminology, since IKEv1 consists of two sequential negotiations, called phases, the IKE SA is also referred to as a Phase 1 SA and the IPsec SA is referred to as a Phase 2 SA.
IKEの交渉が正常に完了すると、ピアは2つのペアの一方向（インバウンドとアウトバウンド）SASを確立しました。Ikeは常にSAのペアを交渉するため、「SA」という用語は一般に、SASのペアを参照するために使用されます（例えば、「Ike SA」または「IPSEC SA」は実際には一方向SASのペアです）。最初のSAであるIKE SAは、IKEトラフィックを保護するために使用されます。2番目のSAは、ピアや他のデバイス間のデータトラフィックをIPSEC保護を提供します。IKEV1のIPSEC SAと呼ばれ、IKEV2 RFCSでは、Child_Sa、Child SA、およびIPSEC SAとさまざまに呼ばれます。このドキュメントでは、「IPSEC SA」という用語を使用しています。IKEV1はフェーズと呼ばれる2つの連続交渉で構成されているため、用語をさらに複雑にするために、IKE SAはフェーズ1 SAとも呼ばれ、IPSEC SAはフェーズ2 SAと呼ばれます。
Changes to IKE include:
IKEへの変更は次のとおりです。
o Replaced multiple alternate exchange types with a single, shorter exchange
o 複数の代替交換タイプを単一の短い交換に置き換えました
o Streamlined negotiation format to avoid combinatorial bloat for multiple proposals
o 複数の提案のための組み合わせ膨満を避けるための合理化されたネゴシエーション形式
o Protect responder from committing significant resources to the exchange until the initiator's existence and identity are confirmed
o イニシエーターの存在とアイデンティティが確認されるまで、レスポンダーが取引所に重要なリソースをコミットするのを防ぐ
o Reliable exchanges: every request expects a response
o 信頼できる交換：すべての要求が応答を期待します
o Protection of IKE messages based on ESP, rather than a method unique to IKE
o IKEに固有の方法ではなく、ESPに基づいたIKEメッセージの保護
o Add traffic selectors: distinct from peer IDs and more flexible
o トラフィックセレクターを追加：ピアIDとは異なる柔軟性とは異なります
o Support of EAP-based authentication methods and asymmetric authentication (i.e., initiator and responder can use different authentication methods)
o EAPベースの認証方法と非対称認証のサポート（つまり、イニシエーターとレスポンダーは異なる認証方法を使用できます）
Numerous IANA registries contain values that are used in IPsec, IKE, and related protocols. They include:
多数のIANAレジストリには、IPSEC、IKE、および関連プロトコルで使用される値が含まれています。それらは次のとおりです。
o IKE Attributes (http://www.iana.org/assignments/ipsec-registry): values used during IKEv1 Phase 1 exchanges, defined in [RFC2409].
o IKE属性（http://www.iana.org/assignments/ipsec-registry）：[RFC2409]で定義されているIKEV1フェーズ1交換中に使用される値。
o "Magic Numbers" for Internet Security Association and Key Management Protocol (ISAKMP) (http://www.iana.org/assignments/isakmp-registry): values used during IKEv1 Phase 2 exchanges, defined in [RFC2407], [RFC2408], and numerous other cryptographic algorithm RFCs.
o インターネットセキュリティ協会および主要な管理プロトコル（ISAKMP）の「マジック番号」（http://www.iana.org/assignments/isakmp-registry）：[RFC2407]で定義されたIKEV1フェーズ2交換中に使用される値、[RFC2408]、および他の多くの暗号化アルゴリズムrfcs。
o IKEv2 Parameters (http://www.iana.org/assignments/ikev2-parameters): values used in IKEv2 exchanges, defined in [RFC5996] and numerous other cryptographic algorithm RFCs.
o IKEV2パラメーター（http://www.iana.org/assignments/ikev2-parameters）：[RFC5996]および他の多数の暗号化アルゴリズムRFCで定義されているIKEV2交換で使用される値。
o Cryptographic Suites for IKEv1, IKEv2, and IPsec (http://www.iana.org/assignments/crypto-suites): names of cryptographic suites in [RFC4308] and [RFC4869].
o IKEV1、IKEV2、およびIPSECの暗号スイート（http://www.iana.org/assignments/crypto-suites）：[RFC4308]および[RFC4869]の暗号化されたスイートの名前。
IPsec protections are provided by two special headers: the Encapsulating Security Payload (ESP) Header and the Authentication Header (AH). In IPv4, these headers take the form of protocol headers; in IPv6, they are classified as extension headers. There are three base IPsec documents: one that describes the IP security architecture, and one for each of the IPsec headers.
IPSEC保護は、2つの特別なヘッダーによって提供されます。セキュリティペイロード（ESP）ヘッダーと認証ヘッダー（AH）です。IPv4では、これらのヘッダーはプロトコルヘッダーの形を取得します。IPv6では、それらは拡張ヘッダーとして分類されます。3つのベースIPSECドキュメントがあります。1つはIPセキュリティアーキテクチャを説明するもの、もう1つはIPSECヘッダーのそれぞれに1つです。
3.1.1.1. RFC 2401, Security Architecture for the Internet Protocol (S, November 1998)
3.1.1.1. RFC 2401、インターネットプロトコルのセキュリティアーキテクチャ（S、1998年11月）
[RFC2401] specifies the mechanisms, procedures, and components required to provide security services at the IP layer. It also describes their interrelationship and the general processing required to inject IPsec protections into the network architecture.
[RFC2401]は、IPレイヤーでセキュリティサービスを提供するために必要なメカニズム、手順、およびコンポーネントを指定します。また、IPSEC保護をネットワークアーキテクチャに注入するために必要な相互関係と一般的な処理についても説明しています。
The components include:
コンポーネントには次のものが含まれます。
- SA (Security Association): a one-way (inbound or outbound) agreement between two communicating peers that specifies the IPsec protections to be provided to their communications. This includes the specific security protections, cryptographic algorithms, and secret keys to be applied, as well as the specific types of traffic to be protected.
- SA（セキュリティ協会）：通信に提供されるIPSEC保護を指定する2つの通信ピア間の一方向（インバウンドまたはアウトバウンド）契約。これには、適用される特定のセキュリティ保護、暗号化アルゴリズム、および保護される特定のタイプのトラフィックが含まれます。
- SPI (Security Parameters Index): a value that, together with the destination address and security protocol (AH or ESP), uniquely identifies a single SA.
- SPI（セキュリティパラメーターインデックス）：宛先アドレスおよびセキュリティプロトコル（AHまたはESP）とともに、単一のSAを一意に識別する値。
- SAD (Security Association Database): each peer's SA repository. The RFC describes how this database functions (SA lookup, etc.) and the types of information it must contain to facilitate SA processing; it does not dictate the format or layout of the database. SAs can be established in either transport mode or tunnel mode (see below).
- Sad（Security Association Database）：各ピアのSAリポジトリ。RFCは、このデータベースがどのように機能するか（SAルックアップなど）と、SA処理を促進するために含まれる必要がある情報の種類を説明します。データベースの形式やレイアウトは指示されません。SASは、輸送モードまたはトンネルモードのいずれかで確立できます（以下を参照）。
- SPD (Security Policy Database): an ordered database that expresses the security protections to be afforded to different types and classes of traffic. The three general classes of traffic are traffic to be discarded, traffic that is allowed without IPsec protection, and traffic that requires IPsec protection.
- SPD（セキュリティポリシーデータベース）：さまざまなタイプとクラスのトラフィックに提供されるセキュリティ保護を表す順序付けられたデータベース。トラフィックの3つの一般的なクラスは、廃棄されるトラフィック、IPSEC保護なしで許可されるトラフィック、およびIPSEC保護を必要とするトラフィックです。
RFC 2401 describes general inbound and outbound IPsec processing; it also includes details on several special cases: packet fragments, ICMP messages, and multicast traffic.
RFC 2401は、一般的なインバウンドおよびアウトバウンドIPSEC処理について説明しています。また、パケットフラグメント、ICMPメッセージ、マルチキャストトラフィックのいくつかの特別なケースの詳細も含まれています。
[RFC2402] defines the Authentication Header (AH), which provides integrity protection; it also provides data-origin authentication, access control, and, optionally, replay protection. A transport mode AH SA, used to protect peer-to-peer communications, protects upper-layer data, as well as those portions of the IP header that do not vary unpredictably during packet delivery. A tunnel mode AH SA can be used to protect gateway-to-gateway or host-to-gateway traffic; it can optionally be used for host-to-host traffic. This class of AH SA protects the inner (original) header and upper-layer data, as well as those portions of the outer (tunnel) header that do not vary unpredictably during packet delivery. Because portions of the IP header are not included in the AH calculations, AH processing is more complex than ESP processing. AH also does not work in the presence of Network Address Translation (NAT). Unlike IPsec-v3, IPsec-v2 classifies AH as mandatory to implement.
[RFC2402]は、整合性保護を提供する認証ヘッダー（AH）を定義します。また、データオリジン認証、アクセス制御、およびオプションでリプレイ保護も提供します。ピアツーピア通信を保護するために使用されるトランスポートモードAH SAは、上層層データと、パケット配信中に予測不可能に異なるIPヘッダーの部分を保護します。トンネルモードAH SAを使用して、ゲートウェイからゲートウェイまたはホストツーゲートウェイのトラフィックを保護できます。オプションでホストからホストへのトラフィックに使用できます。このクラスのAH SAは、内側（元の）ヘッダーと上層層データ、およびパケット配信中に予測不可能に異なる外側（トンネル）ヘッダーの部分を保護します。IPヘッダーの一部はAH計算に含まれていないため、AH処理はESP処理よりも複雑です。AHは、ネットワークアドレス変換（NAT）の存在下でも機能しません。IPSEC-V3とは異なり、IPSEC-V2はAHを実装に必須として分類します。
3.1.1.3. RFC 2406, IP Encapsulating Security Payload (ESP) (S, November 1998)
3.1.1.3. RFC 2406、IPカプセル化セキュリティペイロード（ESP）（S、1998年11月）
[RFC2406] defines the IP Encapsulating Security Payload (ESP), which provides confidentiality (encryption) and/or integrity protection; it also provides data-origin authentication, access control, and, optionally, replay and/or traffic analysis protection. A transport mode ESP SA protects the upper-layer data, but not the IP header. A tunnel mode ESP SA protects the upper-layer data and the inner header, but not the outer header.
[RFC2406]は、セキュリティペイロード（ESP）をカプセル化するIPを定義します。これは、機密性（暗号化）および/または整合性保護を提供します。また、データオリジン認証、アクセス制御、およびオプションでリプレイおよび/またはトラフィック分析保護も提供します。トランスポートモードESP SAは、上層層データを保護しますが、IPヘッダーは保護しません。トンネルモードESP SAは、上層層データと内側のヘッダーを保護しますが、外側のヘッダーは保護しません。
3.1.2.1. RFC 4301, Security Architecture for the Internet Protocol (S, December 2005)
3.1.2.1. RFC 4301、インターネットプロトコルのセキュリティアーキテクチャ（S、2005年12月）
[RFC4301] obsoletes [RFC2401], and it includes a more complete and detailed processing model. The most notable changes are detailed above in Section 2.2.1. IPsec-v3 processing incorporates an additional database:
[RFC4301] Obtoletes [RFC2401]、およびより完全で詳細な処理モデルが含まれています。最も注目すべき変更は、上記のセクション2.2.1で詳しく説明されています。IPSEC-V3処理には、追加のデータベースが組み込まれています。
- PAD (Peer Authorization Database): contains information necessary to conduct peer authentication, providing a link between IPsec and the key management protocol (e.g., IKE)
- PAD（ピア認証データベース）：ピア認証を実施するために必要な情報が含まれており、IPSECと主要な管理プロトコル（IKEなど）の間のリンクを提供します
[RFC4302] obsoletes [RFC2402]. Unlike IPsec-v2, IPsec-v3 classifies AH as optional.
[RFC4302]廃止[RFC2402]。IPSEC-V2とは異なり、IPSEC-V3はAHをオプションとして分類します。
3.1.2.3. RFC 4303, IP Encapsulating Security Payload (ESP) (S, December 2005)
3.1.2.3. RFC 4303、IPカプセル化セキュリティペイロード（ESP）（S、2005年12月）
[RFC4303] obsoletes [RFC2406]. The most notable changes are detailed above in Section 2.2.1.
[RFC4303]廃止[RFC2406]。最も注目すべき変更は、上記のセクション2.2.1で詳しく説明されています。
Once the IKEv1 and IPsec-v2 RFCs were finalized, several additions were defined in separate documents: negotiation of NAT traversal, extended sequence numbers, UDP encapsulation of ESP packets, opportunistic encryption, and IPsec-related ICMP messages. Additional uses of IPsec transport mode were also described: protection of manually configured IPv6-in-IPv4 tunnels and protection of IP-in-IP tunnels. These documents describe atypical uses of IPsec transport mode, but do not define any new IPsec features.
IKEV1およびIPSEC-V2 RFCが最終決定されると、NATトラバーサルの交渉、拡張シーケンス番号、ESPパケットのUDPカプセル化、日和見的暗号化、IPSEC関連のICMPメッセージのいくつかの追加が定義されました。IPSEC輸送モードの追加の使用も説明されています。手動で構成されたIPv6-in-IPV4トンネルの保護とIP-in-IPトンネルの保護。これらのドキュメントは、IPSECトランスポートモードの非定型的な使用について説明しますが、新しいIPSEC機能は定義されていません。
Once the original IPsec Working Group concluded, additional IPsec-related issues were handled by the IPsecME (IPsec Maintenance and Extensions) Working Group. One such problem is the capability of middleboxes to distinguish unencrypted ESP packets (ESP-NULL) from encrypted ones in a fast and accurate manner. Two solutions are described: a new protocol that requires changes to IKEv2 and IPsec-v3 and a heuristic method that imposes no new requirements. Another issue that was addressed is the problem of using IKE and IPsec in a high-availability environment.
元のIPSECワーキンググループが締結されると、IPSECに関連する追加の問題がIPSECME（IPSECメンテナンスと拡張）ワーキンググループによって処理されました。そのような問題の1つは、暗号化されていないESPパケット（ESP-null）と暗号化されたパケットを高速かつ正確な方法で区別するためのミドルボックスの機能です。2つのソリューションについて説明します。IKEV2とIPSEC-V3の変更を必要とする新しいプロトコルと、新しい要件を課さないヒューリスティックな方法です。対処されたもう1つの問題は、高可用性環境でIKEとIPSECを使用する問題です。
3.2.1. RFC 3947, Negotiation of NAT-Traversal in the IKE (S, January 2005)
3.2.1. RFC 3947、IKEでのNAT-Traversalの交渉（S、2005年1月）
[RFC3947] defines an optional extension to IKEv1. It enables IKEv1 to detect whether there are any NATs between the negotiating peers and whether both peers support NAT traversal. It also describes how IKEv1 can be used to negotiate the use of UDP encapsulation of ESP packets for the IPsec SA. For IKEv2, this capability is described in [RFC5996].
[RFC3947]は、IKEV1のオプションの拡張機能を定義します。IKEV1は、交渉の仲間と両方のピアがNATトラバーサルをサポートするかどうかを検出できます。また、IKEV1を使用して、IPSEC SAのESPパケットのUDPカプセル化の使用を交渉する方法についても説明しています。IKEV2の場合、この機能は[RFC5996]で説明されています。
3.2.2. RFC 3948, UDP Encapsulation of IPsec ESP Packets (S, January 2005)
3.2.2. RFC 3948、IPSEC ESPパケットのUDPカプセル化（S、2005年1月）
[RFC3948] is an optional extension for IPsec-v2 and IPsec-v3. It defines how to encapsulate ESP packets in UDP packets to enable the traversal of NATs that discard packets with protocols other than UDP or TCP. This makes it possible for ESP packets to pass through the NAT device without requiring any change to the NAT device itself. The use of this solution is negotiated by IKE, as described in [RFC3947] for IKEv1 and [RFC5996] for IKEv2.
[RFC3948]は、IPSEC-V2およびIPSEC-V3のオプションの拡張機能です。UDPパケットでESPパケットをカプセル化する方法を定義して、UDPまたはTCP以外のプロトコルでパケットを破棄するNATのトラバーサルを有効にします。これにより、ESPパケットはNATデバイス自体に変更を必要とせずにNATデバイスを通過できます。このソリューションの使用は、IKEV1の[RFC3947]およびIKEV2の[RFC5996]の[RFC3947]に記載されているように、IKEによって交渉されます。
3.2.3. RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) (S, December 2005)
3.2.3. RFC 4304、インターネットセキュリティ協会および主要な管理プロトコル（ISAKMP）のIPSEC解釈ドメイン（DOI）への拡張シーケンス番号（ESN）補遺（S、2005年12月）
The use of ESNs allows IPsec to use 64-bit sequence numbers for replay protection, but to send only 32 bits of the sequence number in the packet, enabling shorter packets and avoiding a redesign of the packet format. The larger sequence numbers allow an existing IPsec SA to be used for larger volumes of data. [RFC4304] describes an optional extension to IKEv1 that enables IKEv1 to negotiate the use of ESNs for IPsec SAs. For IKEv2, this capability is described in [RFC5996].
ESNを使用すると、IPSECはリプレイ保護に64ビットシーケンス番号を使用できますが、パケットに32ビットのシーケンス番号のみを送信し、パケットの短縮を有効にし、パケット形式の再設計を回避できます。シーケンス番号が大きいほど、既存のIPSEC SAをより大きなデータに使用することができます。[RFC4304]は、IKEV1がIPSEC SASのESNの使用を交渉できるようにするIKEV1のオプションの拡張を説明しています。IKEV2の場合、この機能は[RFC5996]で説明されています。
Opportunistic encryption allows a pair of end systems to use encryption without any specific pre-arrangements. [RFC4322] specifies a mechanism that uses DNS to distribute the public keys of each system involved and uses DNS Security (DNSSEC) to secure the mechanism against active attackers. It specifies the changes that are needed in existing IPsec and IKE implementations. The majority of the changes are needed in the IKE implementation and these changes relate to the handling of key acquisition requests, the lookup of public keys and TXT records, and the interactions with firewalls and other security facilities that may be co-resident on the same gateway.
日和見暗号化により、一対のエンドシステムが特定の事前配置なしで暗号化を使用できます。[RFC4322]は、DNSを使用して関係する各システムのパブリックキーを配布し、DNSセキュリティ（DNSSEC）を使用してアクティブな攻撃者に対するメカニズムを保護するメカニズムを指定します。既存のIPSECおよびIKEの実装で必要な変更を指定します。IKEの実装では、変更の大部分が必要であり、これらの変更は、キー取得要求の処理、パブリックキーとTXTレコードの検索、および同じものの共同居住者であるファイアウォールやその他のセキュリティ施設とのやり取りに関連しています。ゲートウェイ。
3.2.5. RFC 4891, Using IPsec to Secure IPv6-in-IPv4 Tunnels (I, May 2007)
3.2.5. RFC 4891、IPSECを使用してIPv6-in-IPV4トンネルを保護する（I、2007年5月）
[RFC4891] describes how to use IKE and transport-mode IPsec to provide security protection to manually configured IPv6-in-IPv4 tunnels. This document uses standard IKE and IPsec, without any new extensions. It does not apply to tunnels that are initiated in an automated manner (e.g., 6to4 tunnels [RFC3056]).
[RFC4891]は、IKEおよびトランスポートモードIPSECを使用して、手動で構成されたIPv6-in-IPV4トンネルにセキュリティ保護を提供する方法について説明します。このドキュメントでは、新しい拡張機能なしで標準のIKEとIPSECを使用しています。自動化された方法で開始されるトンネルには適用されません（例：6to4トンネル[RFC3056]）。
3.2.6. RFC 3884, Use of IPsec Transport Mode for Dynamic Routing (I, September 2004)
3.2.6. RFC 3884、動的ルーティングのためのIPSECトランスポートモードの使用（I、2004年9月）
[RFC3884] describes the use of transport-mode IPsec to secure IP-in-IP tunnels, which constitute the links of a multi-hop, distributed virtual network (VN). This allows the traffic to be dynamically routed via the VN's trusted routers, rather than routing all traffic through a statically routed IPsec tunnel. This RFC has not been widely adopted.
[RFC3884]は、マルチホップの分散仮想ネットワーク（VN）のリンクを構成するIP-in-IPトンネルを保護するためのトランスポートモードIPSECの使用について説明しています。これにより、静的にルーティングされたIPSECトンネルを介してすべてのトラフィックをルーティングするのではなく、トラフィックをVNの信頼できるルーターを介して動的にルーティングできます。このRFCは広く採用されていません。
ESP, as defined in [RFC4303], does not allow a network device to easily determine whether protected traffic that is passing through the device is encrypted or only integrity protected (referred to as ESP-NULL packets). [RFC5840] extends ESPv3 to provide explicit notification of integrity-protected packets, and extends IKEv2 to negotiate this capability between the IPsec peers.
ESPは、[RFC4303]で定義されているように、ネットワークデバイスがデバイスを通過している保護されたトラフィックが暗号化されているか、整合性保護されているか（ESP-Nullパケットと呼ばれる）かどうかを簡単に判断することを許可しません。[RFC5840]はESPV3を拡張して整合性保護パケットの明示的な通知を提供し、IKEV2を拡張してIPSECピア間のこの機能を交渉します。
3.2.8. RFC 5879, Heuristics for Detecting ESP-NULL packets (I, May 2010)
3.2.8. RFC 5879、ESP-Nullパケットを検出するためのヒューリスティック（I、2010年5月）
[RFC5879] offers an alternative approach to differentiating between ESP-encrypted and ESP-NULL packets through packet inspection. This method does not require any change to IKE or ESP; it can be used with ESP-v2 or ESP-v3.
[RFC5879]は、パケット検査を通じてESP暗号化されたパケットとESPヌルパケットを区別するための代替アプローチを提供します。この方法では、IKEまたはESPへの変更は必要ありません。ESP-V2またはESP-V3で使用できます。
[RFC3715] "describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them". This is a critical issue, since IPsec is frequently used to provide VPN access to the corporate network for telecommuters, and NATs are widely deployed in home gateways, hotels, and other access networks typically used for remote access.
[RFC3715]「NATとIPSECの間の既知の非互換性を説明し、それらに対処するための要件を説明します」。IPSECは在宅勤務者向けのコーポレートネットワークへのVPNアクセスを提供するために頻繁に使用され、NATはホームゲートウェイ、ホテル、および通常リモートアクセスに使用されるその他のアクセスネットワークに広く展開されているため、これは重大な問題です。
3.3.2. RFC 5406, Guidelines for Specifying the Use of IPsec Version 2 (B, February 2009)
3.3.2. RFC 5406、IPSECバージョン2の使用を指定するためのガイドライン（B、2009年2月）
[RFC5406] offers guidance to protocol designers on how to ascertain whether IPsec is the appropriate security mechanism to provide an interoperable security solution for the protocol. If this is not the case, it advises against attempting to define a new security protocol; rather, it suggests using another standards-based security protocol. The details in this document apply only to IPsec-v2.
[RFC5406]は、IPSECがプロトコルに相互運用可能なセキュリティソリューションを提供する適切なセキュリティメカニズムであるかどうかを確認する方法について、プロトコル設計者にガイダンスを提供します。そうでない場合、新しいセキュリティプロトコルを定義しようとすることを勧めます。むしろ、別の標準ベースのセキュリティプロトコルを使用することを提案しています。このドキュメントの詳細は、IPSEC-V2にのみ適用されます。
[RFC2521] specifies an ICMP message for indicating failures related to the use of IPsec protocols (AH and ESP). The specified ICMP message defines several codes for handling common failure modes for IPsec. The failures that are signaled by this message include invalid or expired SPIs, failure of authenticity or integrity checks on datagrams, decryption and decompression errors, etc. These messages can be used to trigger automated session-key management or to signal to an operator the need to manually reconfigure the SAs. This RFC has not been widely adopted. Furthermore, [RFC4301] discusses the pros and cons of relying on unprotected ICMP messages.
[RFC2521] IPSECプロトコル（AHおよびESP）の使用に関連する障害を示すためのICMPメッセージを指定します。指定されたICMPメッセージは、IPSECの一般的な障害モードを処理するためのいくつかのコードを定義します。このメッセージで合図される障害には、無効または期限切れのスピス、データグラムの信頼性または整合性チェックの障害、復号化および解凍エラーなどが含まれます。これらのメッセージは、自動化されたセッションキー管理をトリガーするか、オペレーターにニーズを通知するために使用できます。SASを手動で再構成する。このRFCは広く採用されていません。さらに、[RFC4301]は、保護されていないICMPメッセージに依存することの長所と短所について説明します。
[RFC6027] describes the problems of using IKE and IPsec in a high availability environment, in which one or both of the peers are clusters of gateways. It details the numerous types of stateful information shared by IKE and IPsec peers that would have to be available to other members of the cluster in order to provide high-availability, load sharing, and/or failover capabilities.
[RFC6027]は、ピアの一方または両方がゲートウェイのクラスターである高可用性環境でIKEとIPSECを使用する問題を説明しています。これは、高利用可能性、負荷共有、および/またはフェイルオーバー機能を提供するために、クラスターの他のメンバーが利用できる必要があるIKEおよびIPSECピアが共有する多数の種類のステートフル情報を詳述しています。
IKE is the preferred key management protocol for IPsec. It is used for peer authentication; to negotiate, modify, and delete SAs; and to negotiate authenticated keying material for use within those SAs. The standard peer authentication methods used by IKEv1 (pre-shared secret keys and digital certificates) had several shortcomings related to use of IKEv1 to enable remote user authentication to a corporate VPN: it could not leverage the use of legacy authentication systems (e.g. RADIUS databases) to authenticate a remote user to a security gateway; and it could not be used to configure remote users with network addresses or other information needed in order to access the internal network. Automatic key distribution is required for IPsec-v2, but alternatives to IKE may be used to satisfy that requirement.
IKEは、IPSECの優先キー管理プロトコルです。ピア認証に使用されます。SASを交渉、変更、削除する。そして、それらのSAS内で使用するための認証されたキーイング素材を交渉する。IKEV1（事前共有シークレットキーとデジタル証明書）が使用する標準のピア認証方法には、IKEV1の使用に関連するいくつかの欠点があり、企業VPNにリモートユーザー認証を有効にします。レガシー認証システムの使用を活用できませんでした（RADIUSデータベースなど）リモートユーザーをセキュリティゲートウェイに認証する。また、内部ネットワークにアクセスするために必要なネットワークアドレスまたはその他の情報を持つリモートユーザーを構成するために使用できませんでした。IPSEC-V2には自動キー分布が必要ですが、IKEの代替品を使用してその要件を満たすことができます。
Several Internet Drafts were written to address these problems: two such documents include "Extended Authentication within IKE (XAUTH)" [IKE-XAUTH] (and its predecessor, "Extended Authentication within ISAKMP/Oakley (XAUTH)" [ISAKMP-XAUTH]) and "The ISAKMP Configuration Method" [IKE-MODE-CFG] (and its predecessor [ISAKMP-MODE-CFG]). These Internet Drafts did not progress to RFC status due to security flaws and other problems related to these solutions. However, many current IKEv1 implementations incorporate aspects of these solutions to facilitate remote user access to corporate VPNs. These solutions were not standardized, and different implementations implemented different versions. Thus, there is no assurance that the implementations adhere fully to the suggested solutions or that one implementation can interoperate with others that claim to incorporate the same features. Furthermore, these solutions have known security issues. All of those problems and security issues have been solved in IKEv2; thus, use of these non-standardized IKEv1 solutions is not recommended.
これらの問題に対処するためにいくつかのインターネットドラフトが書かれています。そのようなドキュメントには、「IKE（Xauth）内の拡張認証」[Ike-Xauth]（およびその前身、「Isakmp/Oakley（Xauth）内の拡張認証」[Isakmp-Xauth]）が含まれます。および「ISAKMP構成方法」[IKE-Mode-CFG]（およびその前身[ISAKMP-Mode-CFG]）。これらのインターネットドラフトは、セキュリティの欠陥やこれらのソリューションに関連するその他の問題により、RFCステータスに進行しませんでした。ただし、現在のIKEV1実装の多くには、これらのソリューションの側面が組み込まれており、企業VPNへのリモートユーザーアクセスを促進しています。これらのソリューションは標準化されておらず、異なる実装で異なるバージョンを実装しました。したがって、実装が提案されたソリューションに完全に付着したり、同じ機能を組み込んだと主張する他のソリューションと相互運用できるという保証はありません。さらに、これらのソリューションにはセキュリティの問題が既知です。これらの問題とセキュリティの問題はすべてIKEV2で解決されています。したがって、これらの標準化されていないIKEV1溶液の使用は推奨されません。
This document defines a key exchange protocol that can be used to negotiate authenticated keying material for SAs. This document implements a subset of the Oakley protocol in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. While, historically, IKEv1 was created by combining two security protocols, ISAKMP and Oakley, in practice, the combination (along with the IPsec DOI) has commonly been viewed as one protocol, IKEv1. The protocol's origins can be seen in the organization of the documents that define it.
このドキュメントでは、SASの認証されたキーイング素材をネゴシエートするために使用できるキーエクスチェンジプロトコルを定義します。このドキュメントでは、ISAKMPと組み合わせてOakleyプロトコルのサブセットを実装して、ISAKMPで使用するための認証されたキーイン材料を取得し、IETF IPSEC DOIのAHやESPなどの他のセキュリティ協会のために取得します。歴史的には、IKEV1は2つのセキュリティプロトコル、ISAKMPとOakleyを組み合わせて作成されましたが、実際には（IPSEC DOIとともに）組み合わせが1つのプロトコルIKEV1と見なされています。プロトコルの起源は、それを定義するドキュメントの編成で見ることができます。
This document defines procedures and packet formats to establish, negotiate, modify, and delete Security Associations (SAs). It is intended to support the negotiation of SAs for security protocols at all layers of the network stack. ISAKMP can work with many different key exchange protocols, each with different security properties.
このドキュメントでは、セキュリティ協会（SAS）を確立、交渉、変更、削除する手順とパケット形式を定義します。ネットワークスタックのすべてのレイヤーでのセキュリティプロトコルのSASの交渉をサポートすることを目的としています。ISAKMPは、それぞれ異なるセキュリティプロパティを持つ多くの異なるキーエクスチェンジプロトコルで動作できます。
Within ISAKMP, a Domain of Interpretation is used to group related protocols using ISAKMP to negotiate security associations. Security protocols sharing a DOI choose security protocol and cryptographic transforms from a common namespace and share key exchange protocol identifiers. This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations.
ISAKMP内では、解釈の領域を使用して、ISAKMPを使用してセキュリティ協会を交渉する関連プロトコルをグループ化します。DOIを共有するセキュリティプロトコルは、共通の名前空間からセキュリティプロトコルと暗号化変換を選択し、キーエクスチェンジプロトコル識別子を共有します。このドキュメントでは、IPがISAKMPを使用してセキュリティ協会を交渉するときにIPで使用するためにISAKMPをインスタンス化するインターネットIPセキュリティDOI（IPSEC doi）を定義します。
4.1.1.4. RFC 2412, The OAKLEY Key Determination Protocol (I, November 1998)
4.1.1.4. RFC 2412、オークリーキー決定プロトコル（I、1998年11月）
[RFC2412] describes a key establishment protocol that two authenticated parties can use to agree on secure and secret keying material. The Oakley protocol describes a series of key exchanges -- called "modes" -- and details the services provided by each (e.g., perfect forward secrecy for keys, identity protection, and authentication). This document provides additional theory and background to explain some of the design decisions and security features of IKE and ISAKMP; it does not include details necessary for the implementation of IKEv1.
[RFC2412]は、2つの認証された当事者が安全で秘密のキーイング資料に同意するために使用できる主要な確立プロトコルについて説明しています。Oakley Protocolは、「モード」と呼ばれる一連のキー交換を説明し、それぞれが提供するサービス（たとえば、キー、アイデンティティ保護、認証のための完全な前進秘密）を詳述しています。このドキュメントは、IKEおよびISAKMPの設計上の決定とセキュリティ機能のいくつかを説明するための追加の理論と背景を提供します。IKEV1の実装に必要な詳細は含まれていません。
4.1.2.1. RFC 4306, Internet Key Exchange (IKEv2) Protocol (S, December 2005)
4.1.2.1. RFC 4306、インターネットキーエクスチェンジ（IKEV2）プロトコル（S、2005年12月）
This document contains the original description of version 2 of the Internet Key Exchange (IKE) protocol. It covers what was previously covered by separate documents: ISAKMP, IKE, and DOI. It also addresses NAT traversal, legacy authentication, and remote address acquisition. IKEv2 is not interoperable with IKEv1. Automatic key distribution is required for IPsec-v3, but alternatives to IKE may be used to satisfy that requirement. This document has been superseded by [RFC5996].
このドキュメントには、インターネットキーエクスチェンジ（IKE）プロトコルのバージョン2の元の説明が含まれています。以前に別々のドキュメントでカバーされていたものをカバーしています：isakmp、ike、およびdoi。また、NATトラバーサル、レガシー認証、およびリモートアドレスの取得にも対応しています。IKEV2はIKEV1と相互運用できません。IPSEC-V3には自動キー分布が必要ですが、IKEの代替品を使用してその要件を満たすことができます。この文書は[RFC5996]に取って代わられています。
4.1.2.2. RFC 4718, IKEv2 Clarifications and Implementation Guidelines (I, October 2006)
4.1.2.2. RFC 4718、IKEV2の明確化と実装ガイドライン（I、2006年10月）
[RFC4718] clarifies many areas of the original IKEv2 specification [RFC4306] that were seen as potentially difficult to understand for developers who were not intimately familiar with the specification and its history. It does not introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The goal of this document was to encourage the development of interoperable implementations. The clarifications in this document have been included in the new version of the IKEv2 specification [RFC5996].
[RFC4718]は、仕様とその歴史に精通していない開発者にとって理解するのが潜在的に理解が困難であると考えられていた元のIKEV2仕様[RFC4306]の多くの領域を明確にします。プロトコルに変更を導入するのではなく、あいまいな解釈が発生しにくい説明を提供します。このドキュメントの目標は、相互運用可能な実装の開発を促進することでした。このドキュメントの説明は、IKEV2仕様[RFC5996]の新しいバージョンに含まれています。
4.1.2.3. RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2) (S, September 2010)
4.1.2.3. RFC 5996、インターネットキーエクスチェンジプロトコルバージョン2（IKEV2）（S、2010年9月）
[RFC5996] combines the original IKEv2 RFC [RFC4306] with the Clarifications RFC [RFC4718], and resolves many implementation issues discovered by the community since the publication of these two documents. This document was developed by the IPsecME (IPsec Maintenance and Extensions) Working Group, after the conclusion of the original IPsec Working Group. Automatic key distribution is required for IPsec-v3, but alternatives to IKE may be used to satisfy that requirement.
[RFC5996]は、元のIKEV2 RFC [RFC4306]と明確化RFC [RFC4718]を組み合わせ、これら2つの文書の公開以来コミュニティによって発見された多くの実装の問題を解決します。このドキュメントは、元のIPSECワーキンググループの終了後、IPSECME（IPSECメンテナンスと拡張機能）ワーキンググループによって開発されました。IPSEC-V3には自動キー分布が必要ですが、IKEの代替品を使用してその要件を満たすことができます。
4.2.1.1. RFC 4478, Repeated Authentication in Internet Key Exchange (IKEv2) Protocol (E, April 2006)
4.2.1.1. RFC 4478、インターネットキーエクスチェンジ（IKEV2）プロトコルでの繰り返し認証（E、2006年4月）
[RFC4478] addresses a problem unique to remote access scenarios. How can the gateway (the IKE responder) force the remote user (the IKE initiator) to periodically reauthenticate, limiting the damage in the case where an unauthorized user gains physical access to the remote host? This document defines a new status notification, that a responder can send to an initiator, which notifies the initiator that the IPsec SA will be revoked unless the initiator reauthenticates within a specified period of time. This optional extension applies only to IKEv2, not to IKEv1.
[RFC4478]は、リモートアクセスシナリオに固有の問題に対処します。ゲートウェイ（IKE Responder）は、リモートユーザー（IKEイニシエーター）に定期的に再認証するように強制し、不正なユーザーがリモートホストに物理的なアクセスを獲得する場合の損傷を制限することができますか？このドキュメントでは、応答者がイニシエーターに送信できる新しいステータス通知を定義します。これにより、指定者が指定された期間内に再認可されない限り、IPSEC SAが取り消されることをイニシエーターに通知します。このオプションの拡張機能は、IKEV1にのみIKEV1に適用されます。
IKEv2 supports several mechanisms for authenticating the parties but each endpoint uses only one of these mechanisms to authenticate itself. [RFC4739] specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user. This also allows for authentication by multiple administrative domains, if needed. This optional extension applies only to IKEv2, not to IKEv1.
IKEV2は、当事者を認証するためのいくつかのメカニズムをサポートしていますが、各エンドポイントはこれらのメカニズムの1つのみを使用して自らを認証します。[RFC4739]は、異なるメカニズムまたは同じメカニズムを使用して、複数の認証交換を使用できるIKEV2の拡張を指定します。この拡張機能により、たとえば、クライアントホストの証明書ベースの認証を実行し、それに続くユーザーのEAP認証を実行できます。これにより、必要に応じて複数の管理ドメインによる認証が可能になります。このオプションの拡張機能は、IKEV1にのみIKEV1に適用されます。
[RFC4754] describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the IKEv1 and IKEv2 protocols. ECDSA provides many benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods like RSA and DSA. This optional extension applies to both IKEv1 and IKEv2.
[RFC4754]は、Elliptic Curve Digital Signature Algorithm（ECDSA）がIKEV1およびIKEV2プロトコル内の認証方法としてどのように使用されるかを説明しています。ECDSAは、RSAやDSAなどの他の利用可能なデジタル署名方法と比較して、計算効率、小さな署名サイズ、最小限の帯域幅など、多くの利点を提供します。このオプションの拡張機能は、IKEV1とIKEV2の両方に適用されます。
4.2.1.4. RFC 5998, An Extension for EAP-Only Authentication in IKEv2 (S, September 2010)
4.2.1.4. RFC 5998、IKEV2（S、2010年9月）でのEAPのみの認証の拡張
IKEv2 allows an initiator to use EAP for peer authentication, but requires the responder to authenticate through the use of a digital signature. [RFC5998] extends IKEv2 so that EAP methods that provide mutual authentication and key agreement can also be used to provide peer authentication for the responder. This optional extension applies only to IKEv2, not to IKEv1.
IKEV2を使用すると、イニシエーターはPEER認証にEAPを使用できますが、デジタル署名を使用して応答者が認証する必要があります。[RFC5998]はIKEV2を拡張して、相互認証と主要な契約を提供するEAPメソッドを使用して、レスポンダーにピア認証を提供できるようにします。このオプションの拡張機能は、IKEV1にのみIKEV1に適用されます。
The format, contents, and interpretation of Public Key Certificates (PKCs) proved to be a source of interoperability problems within IKE and IPsec. PKI4IPsec was an attempt to set in place some common procedures and interpretations to mitigate those problems.
公開キー証明書（PKC）の形式、内容、および解釈は、IKEおよびIPSEC内の相互運用性の問題の原因であることが証明されました。PKI4IPSECは、これらの問題を軽減するためのいくつかの一般的な手順と解釈を設定する試みでした。
[RFC4809] enumerates requirements for Public Key Certificate (PKC) lifecycle transactions between different VPN System and PKI System products in order to better enable large scale, PKI-enabled IPsec deployments with a common set of transactions. This document discusses requirements for both the IPsec and the PKI products. These optional requirements apply to both IKEv1 and IKEv2.
[RFC4809]は、一般的な一連のトランザクションセットで大規模でPKI対応のIPSEC展開をより適切に可能にするために、異なるVPNシステムとPKIシステム製品の間の公開鍵証明書（PKC）ライフサイクルトランザクションの要件を列挙します。このドキュメントでは、IPSEC製品とPKI製品の両方の要件について説明します。これらのオプションの要件は、IKEV1とIKEV2の両方に適用されます。
[RFC4945] defines a profile of the IKE and Public Key Infrastructure using X.509 (PKIX) frameworks in order to provide an agreed-upon standard for using PKI technology in the context of IPsec. It also documents the contents of the relevant IKE payloads and further specifies their semantics. In addition, it summarizes the current state of implementations and deployment and provides advice to avoid common interoperability issues. This optional extension applies to both IKEv1 and IKEv2.
[RFC4945]は、IPSECのコンテキストでPKIテクノロジーを使用するための合意された基準を提供するために、X.509（PKIX）フレームワークを使用してIKEおよび公開キーインフラストラクチャのプロファイルを定義します。また、関連するIKEペイロードの内容を文書化し、さらにそれらのセマンティクスを指定します。さらに、実装と展開の現在の状態を要約し、一般的な相互運用性の問題を回避するためのアドバイスを提供します。このオプションの拡張機能は、IKEV1とIKEV2の両方に適用されます。
When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. [RFC4806] defines the "OCSP Content" extension to IKEv2. This document is applicable when OCSP is desired and security policy (e.g., firewall policy) prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. This optional extension applies only to IKEv2, not to IKEv1.
IKEV2で証明書が使用される場合、通信ピアはピアの証明書の取消しステータスを決定するメカニズムが必要です。OCSPはそのようなメカニズムの1つです。[RFC4806]は、IKEV2の「OCSPコンテンツ」拡張を定義します。このドキュメントは、OCSPが望まれ、セキュリティポリシー（ファイアウォールポリシーなど）がIKEV2ピアの1つが関連するOCSP Responderに直接アクセスすることを防ぐ場合に適用されます。このオプションの拡張機能は、IKEV1にのみIKEV1に適用されます。
When two peers communicate using IKE and IPsec, it is possible for the connectivity between the two peers to drop unexpectedly. But the SAs can still remain until their lifetimes expire, resulting in the packets getting tunneled into a "black hole". [RFC3706] describes an approach to detect peer liveliness without needing to send messages at regular intervals. This RFC defines an optional extension to IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which refers to this feature as a "liveness check" or "liveness test".
IKEとIPSECを使用して2人のピアが通信すると、2人のピア間の接続性が予期せずにドロップする可能性があります。しかし、SASは寿命が切れるまで依然として留まることができ、その結果、パケットが「ブラックホール」にトンネリングされます。[RFC3706]は、定期的にメッセージを送信する必要なく、ピアの活気を検出するアプローチを説明しています。このRFCは、IKEV1のオプションの拡張機能を定義します。Dead Peer Detection（DPD）は、IKEV2の不可欠な部分であり、この機能を「livension Check」または「livension test」と呼びます。
The IKEv2 Mobility and Multihoming (MOBIKE) protocol enables two additional capabilities for IPsec VPN users: 1) moving from one address to another without re-establishing existing SAs and 2) using multiple interfaces simultaneously. These solutions are limited to IPsec VPNs; they are not intended to provide more general mobility or multihoming capabilities.
IKEV2モビリティとマルチホミング（MOBIKE）プロトコルは、IPSEC VPNユーザーに2つの追加機能を有効にします。1）既存のSASを再確立せずに、あるアドレスから別のアドレスに移動し、2）複数のインターフェイスを同時に使用します。これらのソリューションはIPSEC VPNに限定されています。それらは、より一般的なモビリティやマルチホーム機能を提供することを意図していません。
The IPsecME Working Group identified some missing components needed for more extensive IKEv2 and IPsec-v3 support for remote access clients. These include efficient client resumption of a previously established session with a VPN gateway, efficient client redirection to an alternate VPN gateway, and support for IPv6 client configuration using IPsec configuration payloads.
IPSECMEワーキンググループは、リモートアクセスクライアントのより広範なIKEV2およびIPSEC-V3サポートに必要な不足しているコンポーネントをいくつか特定しました。これらには、VPNゲートウェイを使用した以前に確立されたセッションの効率的なクライアント再開、代替VPNゲートウェイへの効率的なクライアントリダイレクト、IPSEC構成ペイロードを使用したIPv6クライアント構成のサポートが含まれます。
4.2.4.1. RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE) (S, June 2006)
4.2.4.1. RFC 4555、IKEV2モビリティおよびマルチホミングプロトコル（MOBIKE）（S、2006年6月）
IKEv2 assumes that an IKE SA is created implicitly between the IP address pair that is used during the protocol execution when establishing the IKEv2 SA. IPsec-related documents had no provision to change this pair after an IKE SA was created. [RFC4555] defines extensions to IKEv2 that enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time.
IKEV2は、IKEV2 SAを確立する際にプロトコル実行中に使用されるIPアドレスペア間でIKE SAが暗黙的に作成されると想定しています。IPSEC関連のドキュメントには、IKE SAが作成された後、このペアを変更する規定はありませんでした。[RFC4555]は、ホストが複数のIPアドレスを所有している場合、および/またはIPSECホストのIPアドレスが時間の経過とともに変化する場合に、IKEおよびIPSECセキュリティ関連の関連性を有効にするIKEV2への拡張機能を定義します。
4.2.4.2. RFC 4621, Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol (I, August 2006)
4.2.4.2. RFC 4621、IKEV2モビリティとマルチホミング（Mobike）プロトコルの設計（I、2006年8月）
[RFC4621] discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. It also records design decisions for the MOBIKE protocol, background information, and records discussions within the working group.
[RFC4621]関係するネットワークエンティティと、IKEV2シグナル伝達と他のプロトコルが提供する情報との関係について説明します。また、Mobikeプロトコル、背景情報、およびワーキンググループ内での記録の議論の設計上の決定を記録します。
[RFC5266] describes a solution using Mobile IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility to enterprise users when they roam into untrusted networks.
[RFC5266]は、モバイルIPv4（MIPV4）とIKEV2（MOBIKE）へのモビリティ拡張を使用して、信頼できないネットワークを歩き回るときにエンタープライズユーザーに安全な接続性とモビリティを提供するソリューションを説明しています。
[RFC5723] enables a remote client that has been disconnected from a gateway to re-establish SAs with the gateway in an expedited manner, without repeating the complete IKEv2 negotiation. This capability requires changes to IKEv2. This optional extension applies only to IKEv2, not to IKEv1.
[RFC5723]は、完全なIKEV2ネゴシエーションを繰り返すことなく、ゲートウェイから切断されたリモートクライアントを迅速な方法でゲートウェイで再確立できるようにします。この機能には、IKEV2の変更が必要です。このオプションの拡張機能は、IKEV1にのみIKEV1に適用されます。
[RFC5685] enables a gateway to securely redirect VPN clients to another VPN gateway, either during or after the IKEv2 negotiation. Possible reasons include, but are not limited to, an overloaded gateway or a gateway that needs to shut down. This requires changes to IKEv2. This optional extension applies only to IKEv2, not to IKEv1.
[RFC5685]は、IKEV2交渉中または後に、VPNクライアントを別のVPNゲートウェイに安全にリダイレクトするゲートウェイを有効にします。考えられる理由には、過負荷のゲートウェイまたはシャットダウンする必要があるゲートウェイが含まれますが、これらに限定されません。これには、IKEV2の変更が必要です。このオプションの拡張機能は、IKEV1にのみIKEV1に適用されます。
In IKEv2, a VPN gateway can assign an internal network address to a remote VPN client. This is accomplished through the use of configuration payloads. For an IPv6 client, the assignment of a single address is not sufficient to enable full-fledged IPv6 communications. [RFC5739] proposes several solutions that might remove this limitation. This optional extension applies only to IKEv2, not to IKEv1.
IKEV2では、VPNゲートウェイは、内部ネットワークアドレスをリモートVPNクライアントに割り当てることができます。これは、構成ペイロードを使用して達成されます。IPv6クライアントの場合、単一のアドレスの割り当てでは、本格的なIPv6通信を有効にするには十分ではありません。[RFC5739]は、この制限を取り除く可能性のあるいくつかのソリューションを提案しています。このオプションの拡張機能は、IKEV1にのみIKEV1に適用されます。
Two basic requirements must be met for an algorithm to be used within IKE and/or IPsec: assignment of one or more IANA values and an RFC that describes how to use the algorithm within the relevant protocol, packet formats, special considerations, etc. For each RFC that describes a cryptographic algorithm, this roadmap will classify its requirement level for each protocol, as either MUST, SHOULD, or MAY [RFC2119]; SHOULD+, SHOULD-, or MUST- [RFC4835]; optional; undefined; or N/A (not applicable). A designation of "optional" means that the algorithm meets the two basic requirements, but its use is not specifically recommended for that protocol. "Undefined" means that one of the basic requirements is not met: either there is no relevant IANA number for the algorithm or there is no RFC specifying how it should be used within that specific protocol. "N/A" means that use of the algorithm is inappropriate in the context (e.g., NULL encryption for IKE, which always requires encryption; or combined mode algorithms, a new feature in IPsec-v3, for use with IPsec-v2).
IKEおよび/またはIPSECで使用するアルゴリズムの2つの基本要件を満たす必要があります。1つまたは複数のIANA値の割り当てと、関連するプロトコル内でアルゴリズムを使用する方法、パケット形式、特別な考慮事項などを説明するRFC。暗号化アルゴリズムを記述する各RFCであるこのロードマップは、各プロトコルの要件レベルを、必要、または可能性のある、または可能性のある[RFC2119]のいずれかに分類します。必要、または必須、または必須[rfc4835];オプション;未定義;またはn/a（該当なし）。「オプション」の指定とは、アルゴリズムが2つの基本的な要件を満たしていることを意味しますが、そのプロトコルにはその使用は特に推奨されません。「未定義」とは、基本的な要件の1つが満たされていないことを意味します。アルゴリズムに関連するIANA番号がないか、その特定のプロトコル内で使用する方法を指定するRFCはありません。「n/a」とは、アルゴリズムの使用がコンテキストでは不適切であることを意味します（たとえば、IKEのヌル暗号化。これは常に暗号化が必要です。または、IPSEC-V2で使用するためのIPSEC-V3の新機能を組み合わせたモードアルゴリズム）。
This document categorizes the requirement level of each algorithm for IKEv1, IKEv2, IPsec-v2, and IPsec-v3. If an algorithm is recommended for use within IKEv1 or IKEv2, it is used either to protect the IKE SA's traffic (encryption and integrity-protection algorithms) or to generate keying material (Diffie-Hellman or DH groups, Pseudorandom Functions or PRFs). If an algorithm is recommended for use within IPsec, it is used to protect the IPsec/child SA's traffic, and IKE is capable of negotiating its use for that purpose. These requirements are summarized in Table 1 (Appendix A). These levels are current as of February 2011; subsequent RFCs may result in altered requirement levels. For algorithms, this could mean the introduction of new algorithms or upgrading or downgrading the requirement levels of current algorithms.
このドキュメントは、IKEV1、IKEV2、IPSEC-V2、およびIPSEC-V3の各アルゴリズムの要件レベルを分類します。アルゴリズムがIKEV1またはIKEV2内で使用することをお勧めする場合、IKE SAのトラフィック（暗号化と整合性保護アルゴリズム）を保護するか、キーイング材料（Diffie-HellmanまたはDHグループ、擬似ランダム機能またはPRF）を生成するために使用されます。IPSEC内での使用が推奨される場合は、IPSEC/Child SAのトラフィックを保護するために使用され、IKEはその目的のためにその使用を交渉することができます。これらの要件を表1（付録A）にまとめます。これらのレベルは2011年2月現在の時点です。その後のRFCは、要件レベルが変更される可能性があります。アルゴリズムの場合、これは新しいアルゴリズムの導入または現在のアルゴリズムの要件レベルのアップグレードまたはダウングレードを意味します。
The IANA registries for IKEv1 and IKEv2 include IANA values for various cryptographic algorithms. IKE uses these values to negotiate IPsec SAs that will provide protection using those algorithms. If a specific algorithm lacks a value for IKEv1 and/or IKEv2, that algorithm's use is classified as "undefined" (no IANA #) within IPsec-v2 and/or IPsec-v3.
IKEV1およびIKEV2のIANAレジストリには、さまざまな暗号化アルゴリズムのIANA値が含まれています。Ikeはこれらの値を使用して、これらのアルゴリズムを使用して保護を提供するIPSEC SASをネゴシエートします。特定のアルゴリズムにIKEV1および/またはIKEV2の値がない場合、そのアルゴリズムの使用は、IPSEC-V2および/またはIPSEC-V3内で「未定義」（IANA＃）に分類されます。
Specifying a core set of mandatory algorithms for each protocol facilitates interoperability. Defining those algorithms in an RFC separate from the base protocol RFC enhances algorithm agility. IPsec-v3 and IKEv2 each have an RFC that specifies their mandatory-to-implement (MUST), recommended (SHOULD), optional (MAY), and deprecated (SHOULD NOT) algorithms. For IPsec-v2, this is included in the base protocol RFC. That was originally the case for IKEv1, but IKEv1's algorithm requirements were updated in [RFC4109].
各プロトコルの必須アルゴリズムのコアセットを指定すると、相互運用性が促進されます。ベースプロトコルRFCとは別のRFCでこれらのアルゴリズムを定義すると、アルゴリズムの俊敏性が向上します。IPSEC-V3とIKEV2には、それぞれ、包括的（必須）、推奨（必要）、オプション（5月）、および非推奨（必要でない）アルゴリズムを指定するRFCがあります。IPSEC-V2の場合、これはベースプロトコルRFCに含まれています。それはもともとIKEV1の場合でしたが、IKEV1のアルゴリズム要件は[RFC4109]で更新されました。
5.1.1. RFC 4835, Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (S, April 2007)
5.1.1. RFC 4835、セキュリティペイロード（ESP）および認証ヘッダー（AH）（S、2007年4月）をカプセル化するための暗号化アルゴリズムの実装要件
[RFC4835] specifies the encryption and integrity-protection algorithms for IPsec (both versions). Algorithms for IPsec-v2 were originally defined in [RFC2402] and [RFC2406]. [RFC4305] obsoleted those requirements, and was in turn obsoleted by [RFC4835]. Therefore, [RFC4835] applies to IPsec-v2 as well as IPsec-v3. Combined mode algorithms are mentioned, but not assigned a requirement level.
[RFC4835] IPSEC（両方のバージョン）の暗号化と整合性保護アルゴリズムを指定します。IPSEC-V2のアルゴリズムは、元々[RFC2402]および[RFC2406]で定義されていました。[RFC4305]これらの要件を廃止し、[RFC4835]によって順番に廃止されました。したがって、[RFC4835]はIPSEC-V2およびIPSEC-V3に適用されます。複合モードアルゴリズムが言及されていますが、要件レベルは割り当てられていません。
[RFC4307] specifies the encryption and integrity-protection algorithms used by IKEv2 to protect its own traffic, the Diffie-Hellman (DH) groups used within IKEv2, and the pseudorandom functions used by IKEv2 to generate keys, nonces, and other random values. [RFC4307] contains conflicting requirements for IKEv2 encryption and integrity-protection algorithms. Where there are contradictory requirements, this document takes its requirement levels from Section 3.1.1, "Encrypted Payload Algorithms", rather than from Section 3.1.3, "IKEv2 Transform Type 1 Algorithms", or Section 3.1.4, "IKEv2 Transform Type 2 Algorithms".
[RFC4307]は、IKEV2が独自のトラフィックを保護するために使用される暗号化と整合性保護アルゴリズム、IKEV2内で使用されるDIFFIE-HELLMAN（DH）グループ、およびIKEV2がキー、ノンセ、その他のランダム値を生成するために使用する擬似ランダム関数を指定します。[RFC4307]には、IKEV2暗号化と整合性保護アルゴリズムの矛盾する要件が含まれています。矛盾した要件がある場合、このドキュメントは、セクション3.1.3、「IKEV2変換タイプ1アルゴリズム」、またはセクション3.1.4、「IKEV2変換タイプ」ではなく、セクション3.1.1、「暗号化されたペイロードアルゴリズム」から要件レベルを取得します。2アルゴリズム "。
5.1.3. RFC 4109, Algorithms for Internet Key Exchange version 1 (IKEv1) (S, May 2005)
5.1.3. RFC 4109、インターネットキーエクスチェンジバージョン1（IKEV1）（S、2005年5月）のアルゴリズム
[RFC4109] updates IKEv1's algorithm specifications, which were originally defined in [RFC2409]. It specifies the encryption and integrity-protection algorithms used by IKEv1 to protect its own traffic; the Diffie-Hellman (DH) groups used within IKEv1; the hash and pseudorandom functions used by IKEv1 to generate keys, nonces and other random values; and the authentication methods and algorithms used by IKEv1 for peer authentication.
[RFC4109]は、元々[RFC2409]で定義されていたIKEV1のアルゴリズム仕様を更新します。IKEV1が独自のトラフィックを保護するために使用する暗号化と整合性保護アルゴリズムを指定します。IKEV1内で使用されるDiffie-Hellman（DH）グループ。IKEV1がキー、ノンセ、その他のランダム値を生成するために使用するハッシュおよび擬似ランダム関数。ピア認証のためにIKEV1が使用する認証方法とアルゴリズム。
The encryption-algorithm RFCs describe how to use these algorithms to encrypt IKE and/or ESP traffic, providing confidentiality protection to the traffic. They describe any special constraints, requirements, or changes to packet format appropriate for the specific algorithm. In general, they do not describe the detailed algorithmic computations; the reference section of each RFC includes pointers to documents that define the inner workings of the algorithm. Some of the RFCs include sample test data, to enable implementors to compare their results with standardized output.
暗号化 - アルゴリズムRFCSは、これらのアルゴリズムを使用してIKEおよび/またはESPトラフィックを暗号化する方法を説明し、トラフィックに機密保護を提供します。特定のアルゴリズムに適したパケット形式の特別な制約、要件、または変更について説明します。一般に、それらは詳細なアルゴリズム計算を説明していません。各RFCの参照セクションには、アルゴリズムの内側の仕組みを定義するドキュメントへのポインターが含まれています。一部のRFCには、サンプルテストデータが含まれており、実装者が結果と標準化された出力を比較できるようにします。
When any encryption algorithm is used to provide confidentiality, the use of integrity protection is strongly recommended. If the encryption algorithm is a stream cipher, omitting integrity protection seriously compromises the security properties of the algorithm.
暗号化アルゴリズムを使用して機密性を提供する場合、整合性保護の使用が強く推奨されます。暗号化アルゴリズムがストリーム暗号である場合、整合性保護を省略すると、アルゴリズムのセキュリティプロパティが深刻に損なわれます。
DES, as described in [RFC2405], was originally a required algorithm for IKEv1 and ESP-v2. Since the use of DES is now deprecated, this roadmap does not include [RFC2405].
[RFC2405]で説明されているように、DESはもともとIKEV1およびESP-V2に必要なアルゴリズムでした。DESの使用は現在廃止されているため、このロードマップには[RFC2405]は含まれていません。
5.2.1. RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec (S, November 1998)
5.2.1. RFC 2410、Null暗号化アルゴリズムとIPSECでのその使用（S、1998年11月）
[RFC2410] is a tongue-in-cheek description of the no-op encryption algorithm (i.e., using ESP without encryption). In order for IKE to negotiate the selection of the NULL encryption algorithm for use in an ESP SA, an identifying IANA number is needed. This number (the value 11 for ESP_NULL) is found on the IANA registries for both IKEv1 and IKEv2, but it is not mentioned in [RFC2410].
[RFC2410]は、NO-OP暗号化アルゴリズムの舌の説明です（つまり、暗号化なしでESPを使用）。IKEがESP SAで使用するためのnull暗号化アルゴリズムの選択を交渉するためには、識別されるIANA番号が必要です。この数（ESP_NULLの値11）は、IKEV1とIKEV2の両方のIANAレジストリにありますが、[RFC2410]では言及されていません。
Requirement levels for ESP-NULL:
ESP-Nullの要件レベル：
IKEv1 - N/A IKEv2 - N/A ESP-v2 - MUST [RFC4835] ESP-v3 - MUST [RFC4835]
IKEV1 -N/A IKEV2 -N/A ESP -V2 -Must [RFC4835] ESP -V3 -Must [RFC4835]
NOTE: RFC 4307 erroneously classifies ESP-NULL as MAY for IKEv2; this has been corrected in an errata submission for RFC 4307.
注：RFC 4307は、IKEV2の場合と誤ってESP-Nullを分類します。これは、RFC 4307のERRATA提出で修正されています。
[RFC2451] describes how to use encryption algorithms in cipher-block-chaining (CBC) mode to encrypt IKE and ESP traffic. It specifically mentions Blowfish, CAST-128, Triple DES (3DES), International Data Encryption Algorithm (IDEA), and RC5, but it is applicable to any block-cipher algorithm used in CBC mode. The algorithms mentioned in the RFC all have a 64-bit blocksize and a 64-bit random Initialization Vector (IV) that is sent in the packet along with the encrypted data.
[RFC2451]は、IKEとESPトラフィックを暗号化するために、暗号ブロックチェーン（CBC）モードで暗号化アルゴリズムを使用する方法について説明します。Blowfish、CAST-128、TRIPLE DES（3DES）、国際データ暗号化アルゴリズム（IDEA）、およびRC5に特に言及していますが、CBCモードで使用されるブロックサイファーアルゴリズムに適用できます。RFCで言及されているアルゴリズムにはすべて、64ビットブロックサイズと、暗号化されたデータとともにパケットに送信される64ビットのランダム初期化ベクトル（IV）があります。
Requirement levels for 3DES-CBC:
3DES-CBCの要件レベル：
IKEv1 - MUST [RFC4109]
IKEv2 - MUST- [RFC4307]
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST- [RFC4835]
Requirement levels for other CBC algorithms (Blowfish, CAST, IDEA, RC5):
他のCBCアルゴリズムの要件レベル（ブローフィッシュ、キャスト、アイデア、RC5）：
IKEv1 - optional IKEv2 - optional ESP-v2 - optional ESP-v3 - optional
IKEV1-オプションIKEV2-オプションのESP -V2-オプションのESP -V3-オプション
5.2.3. RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec (S, September. 2003)
5.2.3. RFC 3602、AES-CBC暗号アルゴリズムとIPSECでのその使用（S、9月。2003）
[RFC3602] describes how to use AES in cipher block chaining (CBC) mode to encrypt IKE and ESP traffic. AES is the successor to DES. AES-CBC is a block-mode cipher with a 128-bit blocksize, a random IV that is sent in the packet along with the encrypted data, and keysizes of 128, 192 and 256 bits. If AES-CBC is implemented, 128-bit keys are MUST; the other sizes are MAY. [RFC3602] includes IANA values for use in IKEv1 and ESP-v2. A single IANA value is defined for AES-CBC, so IKE negotiations need to specify the keysize.
[RFC3602]は、IKEとESPトラフィックを暗号化するために、暗号ブロックチェーン（CBC）モードでAESを使用する方法について説明します。AESはDESの後継者です。AES-CBCは、128ビットブロックサイズを備えたブロックモード暗号、暗号化されたデータとともにパケットに送信されるランダムIV、および128、192、および256ビットのキーのキーサイズです。AES-CBCが実装されている場合、128ビットキーが必要です。他のサイズは5月です。[RFC3602] IKEV1およびESP-V2で使用するIANA値が含まれています。AES-CBCに対して単一のIANA値が定義されているため、IKEの交渉はキーサイズを指定する必要があります。
Requirement levels for AES-CBC with 128-bit keys:
128ビットキーを備えたAES-CBCの要件レベル：
IKEv1 - SHOULD [RFC4109]
IKEv2 - SHOULD+ [RFC4307]
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST [RFC4835]
Requirement levels for AES-CBC with 192- or 256-bit keys:
192または256ビットキーを備えたAES-CBCの要件レベル：
IKEv1 - optional IKEv2 - optional ESP-v2 - optional ESP-v3 - optional
IKEV1-オプションIKEV2-オプションのESP -V2-オプションのESP -V3-オプション
5.2.4. RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP) (S, January 2004)
5.2.4. RFC 3686、Advanced Encryption Standard（AES）カウンターモードを使用して、IPSECをカプセル化するセキュリティペイロード（ESP）（S、2004年1月）
[RFC3686] describes how to use AES in counter (CTR) mode to encrypt ESP traffic. AES-CTR is a stream cipher with a 32-bit random nonce (1/SA) and a 64-bit IV. If AES-CTR is implemented, 128-bit keys are MUST; 192- and 256-byte keys are MAY. Reuse of the IV with the same key and nonce compromises the data's security; thus, AES-CTR should not be used with manual keying. AES-CTR can be pipelined and parallelized; it uses only the AES encryption operations for both encryption and decryption.
[RFC3686]は、ESPトラフィックを暗号化するためにカウンター（CTR）モードでAESを使用する方法について説明します。AES-CTRは、32ビットのランダムノンセ（1/SA）と64ビットIVを備えたストリーム暗号です。AES-CTRが実装されている場合、128ビットキーが必要です。192および256バイトのキーは5月です。IVを同じキーとNonceで再利用し、データのセキュリティが損なわれます。したがって、AES-CTRは手動キーイングで使用しないでください。AES-CTRは、パイプラインおよび並列化できます。暗号化と復号化の両方にAES暗号化操作のみを使用します。
Requirement levels for AES-CTR:
AES-CTRの要件レベル：
IKEv1 - undefined (no IANA #)
IKEv2 - optional [RFC5930]
ESP-v2 - SHOULD [RFC4835]
ESP-v3 - SHOULD [RFC4835]
5.2.5. RFC 5930, Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol (I, July 210).
5.2.5. RFC 5930、インターネットキーエクスチェンジバージョン02（IKEV2）プロトコル（I、7月210）を使用して、高度な暗号化標準カウンターモード（AES-CTR）を使用しています。
[RFC5930] extends [RFC3686] to enable the use of AES-CTR to provide encryption and integrity protection for IKEv2 messages.
[RFC5930]は[RFC3686]を拡張して、AES-CTRを使用してIKEV2メッセージの暗号化と整合性保護を提供できるようにします。
5.2.6. RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec (S, December 2005)
5.2.6. RFC 4312、Camellia暗号アルゴリズムとIPSECでの使用（S、2005年12月）
[RFC4312] describes how to use Camellia in cipher block chaining (CBC) mode to encrypt IKE and ESP traffic. Camellia-CBC is a block-mode cipher with a 128-bit blocksize, a random IV that is sent in the packet along with the encrypted data, and keysizes of 128, 192, and 256 bits. If Camellia-CBC is implemented, 128-bit keys are MUST; the other sizes are MAY. [RFC4312] includes IANA values for use in IKEv1 and IPsec-v2. A single IANA value is defined for Camellia-CBC, so IKEv1 negotiations need to specify the keysize.
[RFC4312]は、IKEとESPトラフィックを暗号化するために、暗号ブロックチェーン（CBC）モードでCamelliaを使用する方法について説明しています。Camellia-CBCは、128ビットブロックサイズを備えたブロックモード暗号、暗号化されたデータとともにパケットに送信されるランダムIV、および128、192、および256ビットのキーサイズです。Camellia-CBCが実装されている場合、128ビットキーが必要です。他のサイズは5月です。[RFC4312] IKEV1およびIPSEC-V2で使用するIANA値が含まれています。Camellia-CBCに対して単一のIANA値が定義されているため、IKEV1交渉はキーサイズを指定する必要があります。
5.2.7. RFC 5529, Modes of Operation for Camellia for Use with IPsec (S, April 2009)
5.2.7. RFC 5529、IPSECで使用するCamelliaの動作モード（S、2009年4月）
[RFC5529] describes the use of the Camellia block-cipher algorithm in conjunction with several different modes of operation. It describes the use of Camellia in cipher block chaining (CBC) mode and counter (CTR) mode as an encryption algorithm within ESP. It also describes the use of Camellia in Counter with CBC-MAC (CCM) mode as a combined mode algorithm in ESP. This document defines how to use IKEv2 to generate keying material for a Camellia ESP SA; it does not define how to use Camellia within IKEv2 to protect an IKEv2 SA's traffic. However, this RFC, in conjunction with IKEv2's generalized description of block-mode encryption, provide enough detail to allow the use of Camellia-CBC algorithms within IKEv2. All three modes can use keys of length 128 bits, 192 bits, or 256 bits. [RFC5529] includes IANA values for use in IKEv2 and IPsec-v3. A single IANA value is defined for each Camellia mode, so IKEv2 negotiations need to specify the keysize.
[RFC5529]は、いくつかの異なる動作モードと組み合わせて、Camelliaブロックサイファーアルゴリズムの使用を説明しています。これは、esp。また、CBC-MAC（CCM）モードを備えたカウンターでのCaMelliaの使用をESPの結合モードアルゴリズムとして説明しています。このドキュメントでは、IKEV2を使用してCamellia ESP SAのキーイング材料を生成する方法を定義しています。IKEV2 SAのトラフィックを保護するためにIKEV2内でCamelliaを使用する方法を定義するものではありません。ただし、このRFCは、IKEV2のブロックモード暗号化の一般化された説明と組み合わせて、IKEV2内でCamellia-CBCアルゴリズムを使用できるように十分な詳細を提供します。3つのモードはすべて、長さ128ビット、192ビット、または256ビットのキーを使用できます。[RFC5529] IKEV2およびIPSEC-V3で使用するIANA値が含まれています。Camelliaモードごとに単一のIANA値が定義されるため、IKEV2の交渉はキーサイズを指定する必要があります。
Requirement levels for Camellia-CBC:
Camellia-CBCの要件レベル：
IKEv1 - optional IKEv2 - optional ESP-v2 - optional ESP-v3 - optional
IKEV1-オプションIKEV2-オプションのESP -V2-オプションのESP -V3-オプション
Requirement levels for Camellia-CTR:
Camellia-Ctrの要件レベル：
IKEv1 - undefined (no IANA #)
IKEv2 - undefined (no RFC)
ESP-v2 - optional (but no IANA #, so cannot be negotiated by IKE)
ESP-v3 - optional
Requirement levels for Camellia-CCM:
Camellia-CCMの要件レベル：
IKEv1 - N/A IKEv2 - undefined (no RFC) ESP-v2 - N/A ESP-v3 - optional
IKEV1 -N/A IKEV2-未定義（RFCなし）ESP -V2 -N/A ESP -V3-オプション
5.2.8. RFC 4196, The SEED Cipher Algorithm and Its Use with IPsec (S, October 2005)
5.2.8. RFC 4196、シード暗号アルゴリズムとIPSECでのその使用（S、2005年10月）
[RFC4196] describes how to use SEED in cipher block chaining (CBC) mode to encrypt ESP traffic. It describes how to use IKEv1 to negotiate a SEED-ESP SA, but does not define the use of SEED to protect IKEv1 traffic. SEED-CBC is a block-mode cipher with a 128-bit blocksize, a random IV that is sent in the packet along with the encrypted data, and a keysize of 128 bits. [RFC4196] includes IANA values for use in IKEv1 and IPsec-v2. [RFC4196] includes test data.
[RFC4196]は、ESPトラフィックを暗号化するために、暗号ブロックチェーン（CBC）モードでシードを使用する方法について説明しています。IKEV1を使用して種子SAを交渉する方法について説明しますが、IKEV1トラフィックを保護するための種子の使用を定義しません。Seed-CBCは、128ビットのブロックサイズを備えたブロックモード暗号、暗号化されたデータとともにパケットに送信されるランダムIV、および128ビットのキーサイズです。[RFC4196] IKEV1およびIPSEC-V2で使用するIANA値が含まれています。[RFC4196]にはテストデータが含まれています。
Requirement levels for SEED-CBC:
Seed-CBCの要件レベル：
IKEv1 - undefined (no IANA #)
IKEv2 - undefined (no IANA #)
ESP-v2 - optional
ESP-v3 - optional (but no IANA #, so cannot be negotiated by IKE)
The integrity-protection algorithm RFCs describe how to use these algorithms to authenticate IKE and/or IPsec traffic, providing integrity protection to the traffic. This protection is provided by computing an Integrity Check Value (ICV), which is sent in the packet. The RFCs describe any special constraints, requirements, or changes to packet format appropriate for the specific algorithm. In general, they do not describe the detailed algorithmic computations; the reference section of each RFC includes pointers to documents that define the inner workings of the algorithm. Some of the RFCs include sample test data, to enable implementors to compare their results with standardized output.
整合性保護アルゴリズムRFCは、これらのアルゴリズムを使用してIKEおよび/またはIPSECトラフィックを認証する方法を説明し、トラフィックに整合性保護を提供します。この保護は、パケットに送信される整合性チェック値（ICV）を計算することにより提供されます。RFCは、特定のアルゴリズムに適したパケット形式の特別な制約、要件、または変更を説明しています。一般に、それらは詳細なアルゴリズム計算を説明していません。各RFCの参照セクションには、アルゴリズムの内側の仕組みを定義するドキュメントへのポインターが含まれています。一部のRFCには、サンプルテストデータが含まれており、実装者が結果と標準化された出力を比較できるようにします。
Some of these algorithms generate a fixed-length ICV, which is truncated when it is included in an IPsec-protected packet. For example, standard HMAC-SHA-1 (Hashed Message Authentication Code) generates a 160-bit ICV, which is truncated to 96 bits when it is used to provide integrity protection to an ESP or AH packet. The individual RFC descriptions mention those algorithms that are truncated. When these algorithms are used to protect IKEv2 SAs, they are also truncated. For IKEv1, HMAC-SHA-1 and HMAC-MD5 are negotiated by requesting the hash algorithms SHA-1 and MD5, respectively; these algorithms are not truncated when used to protect an IKEv1 SA. For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry contains values for both the truncated version and the standard non-truncated version; thus, IKEv2 has the capability to negotiate either version of the algorithm. However, only the truncated version is used for IKEv2 SAs and for IPsec SAs. The non-truncated version is reserved for use by the Fibre Channel protocol [RFC4595]. For the other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and HMAC-RIPEMD), only the truncated version can be used for both IKEv2 and IPsec-v3 SAs.
これらのアルゴリズムの一部は、固定長のICVを生成します。これは、IPSECで保護されたパケットに含まれると切り捨てられます。たとえば、標準のHMAC-SHA-1（Hashed Message Authentication Code）は160ビットICVを生成します。これは、ESPまたはAHパケットに整合性保護を提供するために使用されると96ビットに切り捨てられます。個々のRFCの説明は、切り捨てられたアルゴリズムに言及しています。これらのアルゴリズムがIKEV2 SASを保護するために使用される場合、それらも切り捨てられます。IKEV1の場合、HMAC-SHA-1とHMAC-MD5は、それぞれハッシュアルゴリズムSHA-1とMD5を要求することによりネゴシエートされます。これらのアルゴリズムは、IKEV1 SAを保護するために使用された場合に切り捨てられません。HMAC-SHA-1およびHMAC-MD5の場合、IKEV2 IANAレジストリには、切り捨てられたバージョンと標準の非切り抜きバージョンの両方の値が含まれています。したがって、IKEV2には、いずれかのバージョンのアルゴリズムをネゴシエートする機能があります。ただし、IKEV2 SASおよびIPSEC SASには、切り捨てられたバージョンのみが使用されます。不正なバージョンは、ファイバーチャネルプロトコル[RFC4595]で使用するために予約されています。他のアルゴリズム（AES-XCBC、HMAC-SHA-256/384/512、AES-CMAC、およびHMAC-RIPEMD）の場合、IKEV2とIPSEC-V3 SASの両方に切り捨てられたバージョンのみを使用できます。
One other algorithm, AES-GMAC [RFC4543], can also provide integrity protection. It has two versions: an integrity-protection algorithm for use within AH-v3, and a combined mode algorithm with null encryption for use within ESP-v3. [RFC4543] is described in Section 5.4, "Combined Mode Algorithms".
もう1つのアルゴリズム、AES-GMAC [RFC4543]も、完全性保護を提供できます。2つのバージョンがあります。AH-V3内で使用する整合性保護アルゴリズムと、ESP-V3内で使用するヌル暗号化を備えた複合モードアルゴリズムです。[RFC4543]は、セクション5.4「Combined Mode Algorithms」で説明されています。
5.3.1. RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH (S, November 1998)
5.3.1. RFC 2404、ESPおよびAH内でのHMAC-SHA-1-96の使用（S、1998年11月）
[RFC2404] describes HMAC-SHA-1, an integrity-protection algorithm with a 512-bit blocksize, and a 160-bit key and Integrity Check Value (ICV). For use within IPsec, the ICV is truncated to 96 bits. This is currently the most commonly used integrity-protection algorithm.
[RFC2404]は、512ビットブロックサイズを備えた整合性保護アルゴリズム、160ビットキーおよび完全性チェック値（ICV）を備えたHMAC-SHA-1を説明しています。IPSEC内で使用するために、ICVは96ビットに切り捨てられます。これは現在、最も一般的に使用される整合性保護アルゴリズムです。
Requirement levels for HMAC-SHA-1:
HMAC-SHA-1の要件レベル：
IKEv1 - MUST [RFC4109]
IKEv2 - MUST [RFC4307]
IPsec-v2 - MUST [RFC4835]
IPsec-v3 - MUST [RFC4835]
5.3.2. RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec (S, September 2003)
5.3.2. RFC 3566、AES-XCBC-MAC-96アルゴリズムとIPSECでのその使用（S、2003年9月）
[RFC3566] describes AES-XCBC-MAC, a variant of CBC-MAC, which is secure for messages of varying lengths (unlike classic CBC-MAC). It is an integrity-protection algorithm with a 128-bit blocksize and a 128-bit key and ICV. For use within IPsec, the ICV is truncated to 96 bits. [RFC3566] includes test data.
[RFC3566]は、さまざまな長さのメッセージに対して安全なCBC-MACのバリアントであるAES-XCBC-MACを説明しています（古典的なCBC-MACとは異なります）。これは、128ビットブロックサイズと128ビットキーとICVを備えた整合性保護アルゴリズムです。IPSEC内で使用するために、ICVは96ビットに切り捨てられます。[RFC3566]にはテストデータが含まれています。
Requirement levels for AES-XCBC-MAC:
AES-XCBC-MACの要件レベル：
IKEv1 - undefined (no RFC)
IKEv2 - optional
IPsec-v2 - SHOULD+ [RFC4835]
IPsec-v3 - SHOULD+ [RFC4835]
[RFC4868] describes a family of algorithms, successors to HMAC-SHA-1. HMAC-SHA-256 has a 512-bit blocksize and a 256-bit key and ICV. HMAC-SHA-384 has a 1024-bit blocksize and a 384-bit key and ICV.
[RFC4868]は、HMAC-SHA-1の後継者であるアルゴリズムのファミリーについて説明しています。HMAC-SHA-256には、512ビットブロックサイズと256ビットキーとICVがあります。HMAC-SHA-384には、1024ビットブロックサイズと384ビットキーとICVがあります。
HMAC-SHA-512 has a 1024-bit blocksize and a 512-bit key and ICV. For use within IKE and IPsec, the ICV is truncated to half its original size (128 bits, 192 bits, or 256 bits). Each of the three algorithms has its own IANA value, so IKE does not have to negotiate the keysize.
HMAC-SHA-512には、1024ビットブロックサイズと512ビットキーとICVがあります。IKEおよびIPSEC内で使用するために、ICVは元のサイズの半分に切り捨てられます（128ビット、192ビット、または256ビット）。3つのアルゴリズムにはそれぞれ独自のIANA値があるため、IKEはキーサイズをネゴシエートする必要はありません。
Requirement levels for HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512:
HMAC-SHA-256、HMAC-SHA-384、HMAC-SHA-512の要件レベル：
IKEv1 - optional IKEv2 - optional IPsec-v2 - optional IPsec-v3 - optional
IKEV1-オプションIKEV2-オプションIPSEC -V2-オプションIPSEC -V3-オプション
5.3.4. RFC 2403, The Use of HMAC-MD5-96 within ESP and AH (S, November 1998)
5.3.4. RFC 2403、ESPおよびAH内でのHMAC-MD5-96の使用（S、1998年11月）
[RFC2403] describes HMAC-MD5, an integrity-protection algorithm with a 512-bit blocksize and a 128-bit key and Integrity Check Value (ICV). For use within IPsec, the ICV is truncated to 96 bits. It was a required algorithm for IKEv1 and IPsec-v2. The use of plain MD5 is now deprecated, but [RFC4835] states: "Weaknesses have become apparent in MD5; however, these should not affect the use of MD5 with HMAC".
[RFC2403]は、512ビットブロックサイズと128ビットキーおよび完全性チェック値（ICV）を備えた整合性保護アルゴリズムであるHMAC-MD5を説明しています。IPSEC内で使用するために、ICVは96ビットに切り捨てられます。これは、IKEV1およびIPSEC-V2に必要なアルゴリズムでした。プレーンMD5の使用は現在非推奨になっていますが、[RFC4835]は次のように述べています。
Requirement levels for HMAC-MD5:
HMAC-MD5の要件レベル：
IKEv1 - MAY [RFC4109]
IKEv2 - optional [RFC4307]
IPsec-v2 - MAY [RFC4835]
IPsec-v3 - MAY [RFC4835]
5.3.5. RFC 4494, The AES-CMAC-96 Algorithm and Its Use with IPsec (S, June 2006)
5.3.5. RFC 4494、AES-CMAC-96アルゴリズムとIPSECでのその使用（S、2006年6月）
[RFC4494] describes AES-CMAC, another variant of CBC-MAC, which is secure for messages of varying lengths. It is an integrity-protection algorithm with a 128-bit blocksize and 128-bit key and ICV. For use within IPsec, the ICV is truncated to 96 bits. [RFC4494] includes test data.
[RFC4494]は、さまざまな長さのメッセージに対して安全なCBC-MACの別のバリアントであるAES-CMACを説明しています。これは、128ビットブロックサイズと128ビットキーとICVを備えた整合性保護アルゴリズムです。IPSEC内で使用するために、ICVは96ビットに切り捨てられます。[RFC4494]にはテストデータが含まれています。
Requirement levels for AES-CMAC:
AES-CMACの要件レベル：
IKEv1 - undefined (no IANA #)
IKEv2 - optional
IPsec-v2 - optional (but no IANA #, so cannot be negotiated by IKE)
IPsec-v3 - optional
5.3.6. RFC 2857, The Use of HMAC-RIPEMD-160-96 within ESP and AH (S, June 2000)
5.3.6. RFC 2857、ESPおよびAH内のHMAC-RIPEMD-160-96の使用（S、2000年6月）
[RFC2857] describes HMAC-RIPEMD, an integrity-protection algorithm with a 512-bit blocksize and a 160-bit key and ICV. For use within IPsec, the ICV is truncated to 96 bits.
[RFC2857]は、512ビットブロックサイズと160ビットキーとICVを備えた整合性保護アルゴリズムであるHMAC-Ripemdを説明しています。IPSEC内で使用するために、ICVは96ビットに切り捨てられます。
Requirement levels for HMAC-RIPEMD:
HMAC-RIPEMDの要件レベル：
IKEv1 - undefined (no IANA #)
IKEv2 - undefined (no IANA #)
IPsec-v2 - optional
IPsec-v3 - optional (but no IANA #, so cannot be negotiated by IKE)
In light of recent attacks on MD5 and SHA-1, [RFC4894] examines whether it is necessary to replace the hash functions currently used by IKE and IPsec for key generation, integrity protection, digital signatures, or PKIX certificates. It concludes that the algorithms recommended for IKEv2 [RFC4307] and IPsec-v3 [RFC4305] are not currently susceptible to any known attacks. Nonetheless, it suggests that implementors add support for AES-XCBC-MAC-96 [RFC3566], AES-XCBC-PRF-128 [RFC4434], and HMAC-SHA-256, -384, and -512 [RFC4868] for future use. It also suggests that IKEv2 implementors add support for PKIX certificates signed with SHA-256, -384, and -512.
MD5とSHA-1に対する最近の攻撃に照らして、[RFC4894]は、キー生成、整合性保護、デジタル署名、またはPKIX証明書のためにIKEとIPSECが現在使用しているハッシュ関数を置き換える必要があるかどうかを調べます。IKEV2 [RFC4307]およびIPSEC-V3 [RFC4305]に推奨されるアルゴリズムは、現在、既知の攻撃の影響を受けないと結論付けています。それにもかかわらず、実装者はAES-XCBC-MAC-96 [RFC3566]、AES-XCBC-PRF-128 [RFC4434]、およびHMAC-SHA-256、-384、および-512 [RFC4868]のサポートを追加することを示唆しています。。また、IKEV2実装者は、SHA -256、-384、および-512で署名されたPKIX証明書のサポートを追加することも示唆しています。
IKEv1 and ESP-v2 use separate algorithms to provide encryption and integrity protection, and IKEv1 can negotiate different combinations of algorithms for different SAs. In ESP-v3, a new class of algorithms was introduced, in which a single algorithm can provide both encryption and integrity protection. [RFC5996] describes how IKEv2 can negotiate combined mode algorithms to be used in ESP-v3 SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to negotiate and use combined mode algorithms for its own traffic. When properly designed, these algorithms can provide increased efficiency in both implementation and execution.
IKEV1とESP-V2は、個別のアルゴリズムを使用して暗号化と整合性保護を提供し、IKEV1はさまざまなSAのアルゴリズムの異なる組み合わせを交渉できます。ESP-V3では、新しいクラスのアルゴリズムが導入され、単一のアルゴリズムが暗号化と整合性保護の両方を提供できます。[RFC5996]は、IKEV2がESP-V3 SASで使用される複合モードアルゴリズムをネゴシエートする方法を説明しています。[RFC5282]は、IKEV2にその機能を追加し、IKEV2が独自のトラフィックに対して複合モードアルゴリズムを交渉および使用できるようにします。適切に設計されている場合、これらのアルゴリズムは、実装と実行の両方で効率を高めることができます。
Although ESP-v2 did not originally include combined mode algorithms, some IKEv1 implementations have added the capability to negotiate combined mode algorithms for use in IPsec SAs; these implementations do not include the capability to use combined mode algorithms to protect IKE SAs. IANA numbers for combined mode algorithms have been added to the IKEv1 registry.
ESP-V2にはもともと組み合わせモードアルゴリズムは含まれていませんでしたが、一部のIKEV1実装により、IPSEC SASで使用するための複合モードアルゴリズムをネゴシエートする機能が追加されています。これらの実装には、IKE SASを保護するために複合モードアルゴリズムを使用する機能は含まれていません。結合モードアルゴリズムのIANA番号がIKEV1レジストリに追加されました。
[RFC4309] describes how to use AES in counter with CBC-MAC (CCM) mode, a combined algorithm, to encrypt and integrity protect ESP traffic. AES-CCM is a block-mode cipher with a 128-bit blocksize; a random IV that is sent in the packet along with the encrypted data; a 24-bit salt value (1/SA); keysizes of 128, 192, and 256 bits and ICV sizes of 64, 96 and 128 bits. If AES-CCM is implemented, 128-bit keys are MUST; the other sizes are MAY. ICV sizes of 64 and 128 bits are MUST; 96 bits is MAY. The salt value is generated by IKE during the key-generation process. Reuse of the IV with the same key compromises the data's security; thus, AES-CCM should not be used with manual keying. [RFC4309] includes IANA values that IKE can use to negotiate ESP-v3 SAs. Each of the three ICV lengths has its own IANA value, but IKE negotiations need to specify the keysize. [RFC4309] includes test data. [RFC4309] describes how IKE can negotiate the use of AES-CCM to use in an ESP SA. [RFC5282] extends this to the use of AES-CCM to protect an IKEv2 SA.
[RFC4309]は、CBC-MAC（CCM）モードを使用してカウンターでAESを使用する方法を説明し、ESPトラフィックを暗号化および整合性保護する方法について説明します。AES-CCMは、128ビットブロックサイズのブロックモード暗号です。暗号化されたデータとともにパケットに送信されるランダムIV。24ビットの塩値（1/sa）;128、192、および256ビットとICVサイズのキーサイズ64、96、および128ビット。AES-CCMが実装されている場合、128ビットキーが必要です。他のサイズは5月です。64ビットと128ビットのICVサイズが必須です。96ビットは5月です。塩値は、キージェネレーションプロセス中にIKEによって生成されます。同じ重要なキーでIVを再利用すると、データのセキュリティが損なわれます。したがって、AES-CCMは手動キーイングで使用しないでください。[RFC4309]には、IKEがESP-V3 SASの交渉に使用できるIANA値が含まれています。3つのICVの長さのそれぞれには独自のIANA値がありますが、IKEの交渉はキーサイズを指定する必要があります。[RFC4309]にはテストデータが含まれています。[RFC4309]は、IKEがES-CCMの使用をESP SAで使用する方法をどのように交渉できるかを説明しています。[RFC5282]は、これをAES-CCMの使用に拡張してIKEV2 SAを保護します。
Requirement levels for AES-CCM:
AES-CCMの要件レベル：
IKEv1 - N/A IKEv2 - optional ESP-v2 - N/A ESP-v3 - optional [RFC4835]
IKEV1 -N/A IKEV2-オプションESP -V2 -N/A ESP -V3-オプション[RFC4835]
NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol.
注：IPSEC-V2 IANAレジストリにはAES-CCMの値が含まれていますが、複合モードアルゴリズムはIPSEC-V2の機能ではありません。一部のIKEV1/IPSEC-V2の実装にはこの機能が含まれていますが（セクション5.4を参照）、プロトコルの一部ではありません。
[RFC4106] describes how to use AES in Galois/Counter (GCM) mode, a combined algorithm, to encrypt and integrity protect ESP traffic. AES-GCM is a block-mode cipher with a 128-bit blocksize; a random IV that is sent in the packet along with the encrypted data; a 32-bit salt value (1/SA); keysizes of 128, 192, and 256 bits; and ICV sizes of 64, 96, and 128 bits. If AES-GCM is implemented, 128-bit keys are MUST; the other sizes are MAY. An ICV size of 128 bits is a MUST; 64 and 96 bits are MAY. The salt value is generated by IKE during the key-generation process. Reuse of the IV with the same key compromises the data's security; thus, AES-GCM should not be used with manual keying. [RFC4106] includes IANA values that IKE can use to negotiate ESP-v3 SAs. Each of the three ICV lengths has its own IANA value, but IKE negotiations need to specify the keysize.
[RFC4106]は、ESPトラフィックを暗号化し、整合性を保護するために、組み合わせたアルゴリズムであるGalois/Counter（GCM）モードでAESを使用する方法について説明します。AES-GCMは、128ビットブロックサイズのブロックモード暗号です。暗号化されたデータとともにパケットに送信されるランダムIV。32ビットの塩値（1/sa）;128、192、および256ビットの鍵。64、96、および128ビットのICVサイズ。AES-GCMが実装されている場合、128ビットキーが必要です。他のサイズは5月です。128ビットのICVサイズは必須です。64および96ビットは5月です。塩値は、キージェネレーションプロセス中にIKEによって生成されます。同じ重要なキーでIVを再利用すると、データのセキュリティが損なわれます。したがって、AES-GCMは手動キーイングで使用しないでください。[RFC4106]には、IKEがESP-V3 SASのネゴシエーションに使用できるIANA値が含まれています。3つのICVの長さのそれぞれには独自のIANA値がありますが、IKEの交渉はキーサイズを指定する必要があります。
[RFC4106] includes test data. [RFC4106] describes how IKE can negotiate the use of AES-GCM to use in an ESP SA. [RFC5282] extends this to the use of AES-GCM to protect an IKEv2 SA.
[RFC4106]にはテストデータが含まれています。[RFC4106]は、IKEがESS SAで使用するAES-GCMの使用をどのように交渉できるかを説明しています。[RFC5282]は、これをAES-GCMの使用に拡張してIKEV2 SAを保護します。
Requirement levels for AES-GCM:
AES-GCMの要件レベル：
IKEv1 - N/A IKEv2 - optional ESP-v2 - N/A ESP-v3 - optional [RFC4835]
IKEV1 -N/A IKEV2-オプションESP -V2 -N/A ESP -V3-オプション[RFC4835]
NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol.
注：IPSEC-V2 IANAレジストリにはAES-GCMの値が含まれていますが、複合モードアルゴリズムはIPSEC-V2の機能ではありません。一部のIKEV1/IPSEC-V2の実装にはこの機能が含まれていますが（セクション5.4を参照）、プロトコルの一部ではありません。
[RFC4543] is the variant of AES-GCM [RFC4106] that provides integrity protection without encryption. It has two versions: an integrity-protection algorithm for use within AH, and a combined mode algorithm with null encryption for use within ESP. It can use a key of 128-, 192-, or 256-bits; the ICV is always 128 bits, and is not truncated. AES-GMAC uses a nonce, consisting of a 64-bit IV and a 32-bit salt (1/SA). The salt value is generated by IKE during the key generation process. Reuse of the salt value with the same key compromises the data's security; thus, AES-GMAC should not be used with manual keying. For use within AH, each keysize has its own IANA value, so IKE does not have to negotiate the keysize. For use within ESP, there is only one IANA value, so IKE negotiations must specify the keysize. AES-GMAC cannot be used by IKE to protect its own SAs, since IKE traffic requires encryption.
[RFC4543]は、暗号化なしで整合性保護を提供するAES-GCM [RFC4106]のバリアントです。2つのバージョンがあります。AH内で使用する整合性保護アルゴリズムと、ESP内で使用するヌル暗号化を備えた複合モードアルゴリズム。128、192、または256ビットのキーを使用できます。ICVは常に128ビットであり、切り捨てられていません。AES-GMACは、64ビットIVと32ビット塩（1/SA）で構成されるNonCEを使用します。塩値は、キー生成プロセス中にIKEによって生成されます。同じ重要なキーで塩値を再利用すると、データのセキュリティが損なわれます。したがって、AES-GMACは手動キーイングで使用しないでください。AH内で使用するには、各キーサイズに独自のIANA値があるため、IKEはキーサイズをネゴシエートする必要はありません。ESP内で使用するには、IANA値が1つしかないため、IKEの交渉はキーイジーを指定する必要があります。IKEのトラフィックには暗号化が必要なため、AES-GMACはIKEが独自のSASを保護するために使用することはできません。
Requirement levels for AES-GMAC:
AES-GMACの要件レベル：
IKEv1 - N/A IKEv2 - N/A IPsec-v2 - N/A IPsec-v3 - optional
IKEV1 -N/A IKEV2 -N/A IPSEC -V2 -N/A IPSEC -V3-オプション
NOTE: The IPsec-v2 IANA registry includes values for AES-GMAC, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol.
注：IPSEC-V2 IANAレジストリにはAES-GMACの値が含まれていますが、複合モードアルゴリズムはIPSEC-V2の機能ではありません。一部のIKEV1/IPSEC-V2の実装にはこの機能が含まれていますが（セクション5.4を参照）、プロトコルの一部ではありません。
5.4.4. RFC 5282, Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol (S, August 2008)
5.4.4. RFC 5282、インターネットキーエクスチェンジバージョン2（IKEV2）プロトコルの暗号化されたペイロードを使用した認証された暗号化アルゴリズムを使用しています（S、2008年8月）
[RFC5282] extends [RFC4309] and [RFC4106] to enable the use of AES-CCM and AES-GCM to provide encryption and integrity protection for IKEv2 messages.
[RFC5282]は[RFC4309]と[RFC4106]を拡張して、AES-CCMとAES-GCMを使用してIKEV2メッセージの暗号化と整合性保護を提供できるようにします。
IKE uses pseudorandom functions (PRFs) to generate the secret keys that are used in IKE SAs and IPsec SAs. These PRFs are generally the same algorithms used for integrity protection, but their output is not truncated, since all of the generated bits are generally needed for the keys. If the PRF's output is not long enough to supply the required number of bits of keying material, the PRF is applied iteratively until the requisite amount of keying material is generated.
Ikeは、擬似ランダム関数（PRF）を使用して、IKE SASおよびIPSEC SASで使用される秘密キーを生成します。これらのPRFは一般に、整合性保護に使用されるアルゴリズムと同じですが、生成されたビットのすべてが一般的にキーに必要であるため、出力は切り捨てられません。PRFの出力が必要な数のキーイン材料を供給するのに十分な長さでない場合、PRFは必要な量のキーイン材料が生成されるまで繰り返し適用されます。
For each IKEv2 SA, the peers negotiate both a PRF algorithm and an integrity-protection algorithm; the former is used to generate keying material and other values, and the latter is used to provide protection to the IKE SA's traffic.
各IKEV2 SAについて、ピアはPRFアルゴリズムと整合性保護アルゴリズムの両方を交渉します。前者はキーイング材料やその他の値を生成するために使用され、後者はIKE SAのトラフィックを保護するために使用されます。
IKEv1's approach is more complicated. IKEv1 [RFC2409] does not specify any PRF algorithms. For each IKEv1 SA, the peers agree on an unkeyed hash function (e.g., SHA-1). IKEv1 uses the HMAC version of this function to generate keying material and to provide integrity protection for the IKE SA. Therefore, PRFs that are not HMACs cannot currently be used in IKEv1.
IKEV1のアプローチはより複雑です。IKEV1 [RFC2409]は、PRFアルゴリズムを指定しません。各IKEV1 SAについて、ピアは鍵のないハッシュ関数（SHA-1など）に同意します。IKEV1は、この関数のHMACバージョンを使用してキーイング材料を生成し、IKE SAに整合性保護を提供します。したがって、HMACSではないPRFは現在IKEV1では使用できません。
Requirement levels for PRF-HMAC-SHA1:
PRF-HMAC-SHA1の要件レベル：
IKEv1 - MUST [RFC4109] IKEv2 - MUST [RFC4307]
IKEV1 -[rfc4109] ikev2 -must [rfc4307]
Requirement levels for PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512:
PRF-HMAC-SHA-256、PRF-HMAC-SHA-384、およびPRF-HMAC-SHA-512の要件レベル：
IKEv1 - optional [RFC4868] IKEv2 - optional [RFC4868]
IKEV1-オプション[RFC4868] IKEV2-オプション[RFC4868]
[RFC3566] defines AES-XCBC-MAC-96, which is used for integrity protection within IKE and IPsec. [RFC4434] enables the use of AES-XCBC-MAC as a PRF within IKE. The PRF differs from the integrity- protection algorithm in two ways: its 128-bit output is not truncated to 96 bits, and it accepts a variable-length key, which is modified (lengthened via padding or shortened through application of AES-XCBC) to a 128-bit key. [RFC4434] includes test data.
[RFC3566]は、IKEおよびIPSEC内の整合性保護に使用されるAES-XCBC-MAC-96を定義します。[RFC4434]は、IKE内のPRFとしてAES-XCBC-MACを使用することを可能にします。PRFは、2つの方法で整合性保護アルゴリズムとは異なります。128ビット出力は96ビットに切り捨てられず、変数の長さキーを受け入れます。128ビットキーに。[RFC4434]にはテストデータが含まれています。
Requirement levels for AES-XCBC-PRF:
AES-XCBC-PRFの要件レベル：
IKEv1 - undefined (no RFC) IKEv2 - SHOULD+ [RFC4307]
IKEV1-未定義（RFCなし）IKEV2 -[RFC4307]
NOTE: RFC 4109 erroneously classifies AES-XCBC-PRF as SHOULD for IKEv1; this has been corrected in an errata submission for RFC 4109.
注：RFC 4109は、IKEV1の場合と同様にAES-XCBC-PRFを誤って分類します。これは、RFC 4109のERRATA提出で修正されています。
5.5.2. RFC 4615, The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudorandom Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE) (S, August 2006)
5.5.2. RFC 4615、Advanced Encryption Standard-Cipherベースのメッセージ認証Code-Pseudorandom Function-128（AES-CMAC-PRF-128）インターネットキーエクスチェンジプロトコル（IKE）（S、2006年8月）のアルゴリズム
[RFC4615] extends [RFC4494] to enable the use of AES-CMAC as a PRF within IKEv2, in a manner analogous to that used by [RFC4434] for AES-XCBC.
[RFC4615]は[RFC4494]を拡張して、AES-XCBCの[RFC4434]で使用される方法に類似した方法で、IKEV2内のAES-CMACをPRFとして使用できるようにします。
Requirement levels for AES-CMAC-PRF:
AES-CMAC-PRFの要件レベル：
IKEv1 - undefined (no IANA #) IKEv2 - optional
ikev1-未定義（no iana＃）ikev2-オプション
An IKE negotiation consists of multiple cryptographic attributes, both for the IKE SA and for the IPsec SA. The number of possible combinations can pose a challenge to peers trying to find a common policy. To enhance interoperability, [RFC4308] defines two pre-defined suites, consisting of combinations of algorithms that comprise typical security policies. IKE/ESP suite "VPN-A" includes use of 3DES, HMAC-SHA-1, and 1024-bit modular exponentiation group (MODP) Diffie-Hellman (DH); IKE/ESP suite "VPN-B" includes AES-CBC, AES-XCBC-MAC, and 2048-bit MODP DH. These suites are intended to be named "single-button" choices in the administrative interface, but do not prevent the use of alternative combinations.
IKE交渉は、IKE SAとIPSEC SAの両方の複数の暗号化属性で構成されています。可能な組み合わせの数は、共通のポリシーを見つけようとするピアに挑戦する可能性があります。相互運用性を高めるために、[RFC4308]は、典型的なセキュリティポリシーを構成するアルゴリズムの組み合わせで構成される2つの事前定義されたスイートを定義します。IKE/ESPスイート「VPN-A」には、3DES、HMAC-SHA-1、および1024ビットモジュラーエクスポンゲーショングループ（MODP）Diffie-Hellman（DH）の使用が含まれます。IKE/ESPスイート "VPN-B"には、AES-CBC、AES-XCBC-MAC、および2048ビットMODP DHが含まれます。これらのスイートは、管理インターフェイスで「シングルボタン」の選択肢と名付けられることを目的としていますが、代替の組み合わせの使用を妨げません。
[RFC4869] adds four pre-defined suites, based upon the United States National Security Agency's "Suite B" specifications, to those specified in [RFC4308]. IKE/ESP suites "Suite-B-GCM-128" and "Suite- B-GCM-256" include use of AES-CBC, AES-GCM, HMAC-SHA-256, or HMAC-SHA-384, and 256-bit or 384-bit elliptic-curve (EC) DH groups. IKE/AH suites "Suite-B-GMAC-128" and "Suite-B-GMAC-256" include use of AES-CBC, AES-GMAC, HMAC-SHA-256, or HMAC-SHA-384, and 256-bit or 384-bit EC DH groups. While [RFC4308] does not specify a peer-authentication method, [RFC4869] mandates pre-shared key authentication for IKEv1; public key authentication using ECDSA is recommended for IKEv1 and required for IKEv2.
[RFC4869]は、米国国家安全保障局の「スイートB」仕様に基づいて、[RFC4308]で指定されたものに4つの事前定義されたスイートを追加します。IKE/ESPスイート「Suite-B-GCM-128」および「Suite-B-GCM-256」には、AES-CBC、AES-GCM、HMAC-SHA-256、またはHMAC-SHA-384、および256-ビットまたは384ビット楕円曲線（EC）DHグループ。IKE/AH SUITES「Suite-B-GMAC-128」および「Suite-B-GMAC-256」には、AES-CBC、AES-GMAC、HMAC-SHA-256、またはHMAC-SHA-384、および256-の使用が含まれます。ビットまたは384ビットEC DHグループ。[RFC4308]はピア認証方法を指定していませんが、[RFC4869]はIKEV1の事前共有キー認証を義務付けています。ECDSAを使用した公開キー認証は、IKEV1に推奨され、IKEV2に必要です。
IKE negotiations include a Diffie-Hellman exchange, which establishes a shared secret to which both parties contributed. This value is used to generate keying material to protect both the IKE SA and the IPsec SA.
Ikeの交渉には、Diffie-Hellman Exchangeが含まれます。これは、両当事者が貢献した共有秘密を確立します。この値は、IKE SAとIPSEC SAの両方を保護するためのキーイング材料を生成するために使用されます。
IKEv1 [RFC2409] contains definitions of two DH MODP groups and two elliptic curve (EC) groups; IKEv2 [RFC5996] only references the MODP groups. The requirements levels of these groups are:
IKEV1 [RFC2409]には、2つのDH MODPグループと2つの楕円曲線（EC）グループの定義が含まれています。IKEV2 [RFC5996]は、MODPグループのみを参照しています。これらのグループの要件レベルは次のとおりです。
Requirement levels for DH MODP group 1:
DH MODPグループ1の要件レベル：
IKEv1 - MAY [RFC4109] IKEv2 - optional
IKEV1 -5月[RFC4109] IKEV2-オプション
Requirement levels for DH MODP group 2:
DH MODPグループ2の要件レベル：
IKEv1 - MUST [RFC4109] IKEv2 - MUST- [RFC4307]
IKEV1 -必須[RFC4109] IKEV2 -必須[RFC4307]
Requirement levels for EC groups 3-4:
ECグループの要件レベル3-4：
IKEv1 - MAY [RFC4109] IKEv2 - undefined (no IANA #)
IKEV1 -5月[RFC4109] IKEV2-未定義（IANA＃）
[RFC2409] and [RFC5996] define two MODP DH groups (groups 1 and 2) for use within IKE. [RFC3526] adds six more groups (groups 5 and 14-18). Group 14 is a 2048-bit group that is strongly recommended for use in IKE.
[RFC2409]および[RFC5996]は、IKE内で使用する2つのMODP DHグループ（グループ1および2）を定義します。[RFC3526]は、さらに6つのグループ（グループ5および14-18）を追加します。グループ14は2048ビットグループで、IKEでの使用を強くお勧めします。
Requirement levels for DH MODP group 14:
DH MODPグループ14の要件レベル：
IKEv1 - SHOULD [RFC4109] IKEv2 - SHOULD+ [RFC4307]
IKEV1 -[RFC4109] IKEV2 -SOUST [RFC4307]
Requirement levels for DH MODP groups 5, 15-18:
DH MODPグループ5、15-18の要件レベル：
IKEv1 - optional [RFC4109] IKEv2 - optional
IKEV1-オプション[RFC4109] IKEV2-オプション
[RFC4753] defines three EC DH groups (groups 19-21) for use within IKE.
[RFC4753]は、IKE内で使用する3つのEC DHグループ（グループ19-21）を定義しています。
The document includes test data.
ドキュメントにはテストデータが含まれています。
Requirement levels for DH EC groups 19-21:
DH ECグループの要件レベル19-21：
IKEv1 - optional [RFC4109] IKEv2 - optional
IKEV1-オプション[RFC4109] IKEV2-オプション
[RFC5903] obsoletes [RFC4753], fixing an inconsistency in the DH shared secret value.
[RFC5903]廃止[RFC4753]、DH共有秘密の値の矛盾を修正しました。
[RFC5114] defines five additional DH groups (MODP groups 22-24 and EC groups 25-26) for use in IKE. It also includes three EC DH groups (groups 19-21) that were originally defined in [RFC4753]; however, the current specification for these groups is [RFC5903]. The IANA group numbers are specific to IKE, but the DH groups are intended for use in multiple IETF protocols, including Transport Layer Security/Secure Socket Layer (TLS/SSL), Secure/Multipurpose Internet Mail Extensions (S/MIME), and X.509 Certificates.
[RFC5114]は、IKEで使用するための5つの追加のDHグループ（MODPグループ22-24およびECグループ25-26）を定義しています。また、[RFC4753]で元々定義されていた3つのEC DHグループ（グループ19-21）も含まれます。ただし、これらのグループの現在の仕様は[RFC5903]です。IANAグループ番号はIKEに固有ですが、DHグループは、トランスポートレイヤーセキュリティ/セキュアソケットレイヤー（TLS/SSL）、安全/多目的インターネットメール拡張（S/MIME）、Xなど、複数のIETFプロトコルで使用することを目的としています。.509証明書。
Requirement levels for DH MODP groups 22-24, EC groups 25-26:
DH MODPグループ22-24、ECグループ25-26の要件レベル：
IKEv1 - optional IKEv2 - optional
IKEV1-オプションIKEV2-オプション
[RFC4301] describes IPsec processing for unicast and multicast traffic. However, classical IPsec SAs provide point-to-point protection; the security afforded by IPsec's cryptographic algorithms is not applicable when the SA is one-to-many or many-to-many, the case for multicast. The Multicast Security (msec) Working Group has defined alternatives to IKE and extensions to IPsec for use with multicast traffic. Different multicast groups have differing characteristics and requirements: number of senders (one-to-many or many-to-many), number of members (few, moderate, very large), volatility of membership, real-time delivery, etc. Their security requirements vary as well. Each solution defined by msec applies to a subset of the large variety of possible multicast groups.
[RFC4301]は、ユニキャストおよびマルチキャストトラフィックのIPSEC処理について説明しています。ただし、古典的なIPSEC SASはポイントツーポイント保護を提供します。IPSECの暗号化アルゴリズムによって提供されるセキュリティは、SAが1対多または多くの場合、マルチキャストの場合は適用されません。マルチキャストセキュリティ（MSEC）ワーキンググループは、IKEの代替案と、マルチキャストトラフィックで使用するためにIPSECの拡張を定義しています。さまざまなマルチキャストグループには、特性と要件が異なります。送信者数（1対多または多数）、メンバーの数（少数、中程度、非常に大きい）、メンバーシップのボラティリティ、リアルタイム配達など。セキュリティ要件も異なります。MSECで定義された各ソリューションは、多種多様なマルチキャストグループのサブセットに適用されます。
6.1. RFC 3740, The Multicast Group Security Architecture (I, March 2004)
6.1. RFC 3740、マルチキャストグループセキュリティアーキテクチャ（I、2004年3月）
[RFC3740] defines the multicast security architecture, which is used to provide security for packets exchanged by large multicast groups. It defines the components of the architectural framework; discusses Group Security Associations (GSAs), key management, data handling, and security policies. Several existing protocols, including Group DOI (GDOI) [RFC3547], Group Secure Association Key Management Protocol (GSAKMP) [RFC4535], and Multimedia Internet KEYing (MIKEY) [RFC3830], satisfy the group key management requirements defined in this document. Both the architecture and the components for Multicast Group Security differ from IPsec.
[RFC3740]は、大規模なマルチキャストグループが交換するパケットのセキュリティを提供するために使用されるマルチキャストセキュリティアーキテクチャを定義します。アーキテクチャフレームワークのコンポーネントを定義します。グループセキュリティ協会（GSA）、主要な管理、データ処理、セキュリティポリシーについて説明します。グループDOI（GDOI）[RFC3547]、グループセキュアアソシエーションキー管理プロトコル（GSAKMP）[RFC4535]、およびマルチメディアインターネットキーイング（Mikey）[RFC3830]を含むいくつかの既存のプロトコルは、この文書で定義されたグループキー管理要件を満たしています。マルチキャストグループセキュリティのアーキテクチャとコンポーネントの両方がIPSECとは異なります。
[RFC5374] extends the security architecture defined in [RFC4301] to apply to multicast traffic. It defines a new class of SAs (GSAs - Group Security Associations) and additional databases used to apply IPsec protection to multicast traffic. It also describes revisions and additions to the processing algorithms in [RFC4301].
[RFC5374]は、[RFC4301]で定義されたセキュリティアーキテクチャをマルチキャストトラフィックに適用するために拡張します。新しいクラスのSAS（GSAS -Group Security Associations）と、マルチキャストトラフィックにIPSEC保護を適用するために使用される追加のデータベースを定義します。また、[RFC4301]の処理アルゴリズムへの改訂と追加についても説明しています。
GDOI [RFC3547] extends IKEv1 so that it can be used to establish SAs to protect multicast traffic. This document defines additional exchanges and payloads to be used for that purpose.
GDOI [RFC3547]はIKEV1を拡張して、マルチキャストトラフィックを保護するためにSASを確立するために使用できるようにします。このドキュメントでは、その目的のために使用される追加の交換とペイロードを定義します。
[RFC4046] sets out the general requirements and design principles for protocols that are used for multicast key management. It does not go into the specifics of an individual protocol that can be used for that purpose.
[RFC4046]は、マルチキャストキー管理に使用されるプロトコルの一般的な要件と設計原則を定めています。その目的に使用できる個々のプロトコルの詳細には入りません。
6.5. RFC 4359, The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) (S, January 2006)
6.5. RFC 4359、セキュリティペイロード（ESP）および認証ヘッダー（AH）（S、2006年1月）内でのRSA/SHA-1シグネチャの使用
[RFC4359] describes the use of the RSA digital signature algorithm to provide integrity protection for multicast traffic within ESP and AH. The algorithms used for integrity protection for unicast traffic (e.g., HMAC) are not suitable for this purpose when used with multicast traffic.
[RFC4359]は、ESPおよびAH内のマルチキャストトラフィックに整合性保護を提供するために、RSAデジタル署名アルゴリズムの使用を説明しています。ユニキャストトラフィック（HMACなど）の整合性保護に使用されるアルゴリズムは、マルチキャストトラフィックで使用する場合、この目的には適していません。
Operational experience with IPsec revealed additional capabilities that could make IPsec more useful in real-world scenarios. These include support for IPsec policy mechanisms, IPsec MIBs, payload compression (IPComp), extensions to facilitate additional peer authentication methods (Better-Than-Nothing Security (BTNS), Kerberized Internet Negotiation of Keys (KINK), and IPSECKEY), and additional capabilities for VPN clients (IPSRA).
IPSECでの運用エクスペリエンスにより、実際のシナリオでIPSECをより便利にする可能性のある追加の機能が明らかになりました。これらには、IPSECポリシーメカニズム、IPSEC MIBS、ペイロード圧縮（IPCOMP）、追加のピア認証方法（より良いもののないセキュリティ（BTN）を容易にするための拡張、Kerberizedインターネット交渉（キンク）、およびIPSECKEY）のサポートが含まれます。VPNクライアントの機能（IPSRA）。
The IPsec Policy (ipsp) Working Group originally planned an RFC that would allow entities with no common Trust Anchor and no prior knowledge of each other's security policies to establish an IPsec-protected connection. The solutions that were proposed for gateway discovery and security policy negotiation proved to be overly complex and fragile, in the absence of prior knowledge or compatible configuration policies.
IPSECポリシー（IPSP）ワーキンググループは、当初、共通の信頼アンカーも互いのセキュリティポリシーの事前知識もないエンティティがIPSECで保護された接続を確立できるようにするRFCを計画していました。ゲートウェイの発見とセキュリティポリシーの交渉のために提案されたソリューションは、事前知識または互換性のある構成ポリシーがない場合、過度に複雑で脆弱であることが証明されました。
7.1.1. RFC 3586, IP Security Policy (IPSP) Requirements (S, August 2003)
7.1.1. RFC 3586、IPセキュリティポリシー（IPSP）要件（S、2003年8月）
[RFC3586] describes the functional requirements of a generalized IPsec policy framework, that could be used to discover, negotiate, and manage IPsec policies.
[RFC3586]は、IPSECポリシーを発見、交渉、および管理するために使用できる、一般化されたIPSECポリシーフレームワークの機能要件を説明しています。
7.1.2. RFC 3585, IPsec Configuration Policy Information Model (S, August 2003)
7.1.2. RFC 3585、IPSEC構成ポリシー情報モデル（S、2003年8月）
As stated in [RFC3585]:
[RFC3585]に記載されているように：
This document presents an object-oriented information model of IP Security (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints.
このドキュメントは、IPSECポリシーのコンテンツとセマンティクスに関する一致を促進するように設計されたオブジェクト指向情報モデル（IPSEC）ポリシーを提示し、ストレージスキーマ、配布表現、ポリシーなどのIPSECポリシーのタスク固有の表現の導出を可能にしますIPSEC対応エンドポイントの構成に使用される仕様言語。
This RFC has not been widely adopted.
このRFCは広く採用されていません。
Over the years, several MIB-related Internet Drafts were proposed for IPsec and IKE, but only one progressed to RFC status.
長年にわたり、IPSECとIKEにはMIB関連のインターネットドラフトがいくつか提案されていましたが、RFCステータスに進行したのは1つだけでした。
7.2.1. RFC 4807, IPsec Security Policy Database Configuration MIB (S, March 2007)
7.2.1. RFC 4807、IPSECセキュリティポリシーデータベース構成MIB（S、2007年3月）
[RFC4807] defines a MIB module that can be used to configure the SPD of an IPsec device. This RFC has not been widely adopted.
[RFC4807]は、IPSECデバイスのSPDを構成するために使用できるMIBモジュールを定義します。このRFCは広く採用されていません。
The IP Payload Compression Protocol (IPComp) is a protocol that provides lossless compression for IP datagrams. Although IKE can be used to negotiate the use of IPComp in conjunction with IPsec, IPComp can also be used when IPsec is not applied.
IPペイロード圧縮プロトコル（IPComp）は、IPデータグラムにロスレス圧縮を提供するプロトコルです。IKEを使用してIPSECと組み合わせてIPCOMPの使用を交渉することができますが、IPSECが適用されない場合にもIPCOMPを使用できます。
The IPComp protocol allows the compression of IP datagrams by supporting different compression algorithms. Three of these algorithms are: DEFLATE [RFC2394], LZS [RFC2395], and the ITU-T V.44 Packet Method [RFC3051], which is based on the LZJH algorithm.
IPCOMPプロトコルは、異なる圧縮アルゴリズムをサポートすることにより、IPデータグラムの圧縮を可能にします。これらのアルゴリズムの3つは、DEFLATE [RFC2394]、LZS [RFC2395]、およびLZJHアルゴリズムに基づくITU-T V.44パケットメソッド[RFC3051]、およびITU-T V.44パケットメソッドです。
7.3.1. RFC 3173, IP Payload Compression Protocol (IPComp) (S, September 2001)
7.3.1. RFC 3173、IPペイロード圧縮プロトコル（IPComp）（S、2001年9月）
IP payload compression is especially useful when IPsec-based encryption is applied to IP datagrams. Encrypting the IP datagram causes the data to be random in nature, rendering compression at lower protocol layers ineffective. If IKE is used to negotiate compression in conjunction with IPsec, compression can be performed prior to encryption. [RFC3173] defines the payload compression protocol, the IPComp packet structure, the IPComp Association (IPCA), and several methods to negotiate the IPCA.
IPペイロード圧縮は、IPSECベースの暗号化がIPデータグラムに適用される場合に特に役立ちます。IPデータグラムを暗号化すると、データが本質的にランダムになり、低いプロトコル層での圧縮が効果的ではありません。IKEがIPSECと組み合わせて圧縮を交渉するために使用される場合、暗号化の前に圧縮を実行できます。[RFC3173]は、ペイロード圧縮プロトコル、IPCompパケット構造、IPComp Association（IPCA）、およびIPCAをネゴシエートするいくつかの方法を定義します。
One of the major obstacles to widespread implementation of IPsec is the lack of pre-existing credentials that can be used for peer authentication. Better-Than-Nothing Security (BTNS) is an attempt to sidestep this problem by allowing IKE to negotiate unauthenticated (anonymous) IPsec SAs, using credentials such as self-signed certificates or "bare" public keys (public keys that are not connected to a public key certificate) for peer authentication. This ensures that subsequent traffic protected by the SA is conducted with the same peer, and protects the communications from passive attack. These SAs can then be cryptographically bound to a higher-level application protocol, which performs its own peer authentication.
IPSECの広範な実装に対する主要な障害の1つは、ピア認証に使用できる既存の資格情報がないことです。より良いセキュリティ（BTNS）は、自己署名証明書や「ベア」パブリックキーなどの資格情報（接続されていないパブリックキーなどの資格情報を使用して、IKEが無認定（匿名）IPSEC SASを交渉できるようにすることにより、この問題を回避する試みです。ピア認証のための公開鍵証明書）。これにより、SAによって保護された後続のトラフィックが同じピアで行われ、パッシブ攻撃から通信を保護することが保証されます。これらのSASは、独自のピア認証を実行する高レベルのアプリケーションプロトコルに暗号化されて結合することができます。
[RFC5660] specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create channels by latching connections (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.
[RFC5660]は、接続（パケットフロー）を特定のIPSECセキュリティアソシエーション（SA）パラメーターにラッチングすることでチャネルを作成するために、IPSECとのアプリケーションと輸送プロトコルをインターフェイスし、接続の寿命をかける方法を指定します。接続ラッチはIPSECの上に階層化されており、基礎となるIPSECアーキテクチャを変更しません。
[RFC5386] specifies how to use IKEv2 to set up unauthenticated security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). This document does not require any changes to the bits on the wire, but specifies extensions to the Peer Authorization Database (PAD) and Security Policy Database (SPD).
[RFC5386]は、IKEV2を使用して、IPSECをカプセル化するセキュリティペイロード（ESP）とIPSEC認証ヘッダー（AH）をカプセル化するための未認証のセキュリティ協会（SAS）を設定する方法を指定します。このドキュメントでは、ワイヤー上のビットの変更は必要ありませんが、Peer Authorizationデータベース（PAD）およびセキュリティポリシーデータベース（SPD）への拡張機能を指定します。
[RFC5387] considers that the need to deploy authentication information and its associated identities is a significant obstacle to the use of IPsec. This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication.
[RFC5387]は、認証情報とそれに関連するアイデンティティを展開する必要性がIPSECの使用に対する重要な障害であると考えています。このドキュメントでは、認証なしでIPSECセキュリティサービスの使用を可能にするために、インターネットネットワークセキュリティプロトコルスイートを拡張するための根拠を説明しています。
Kerberized Internet Negotiation of Keys (KINK) is an attempt to provide an alternative to IKE for IPsec peer authentication. It uses Kerberos, instead of IKE, to establish IPsec SAs. For enterprises that already deploy the Kerberos centralized key management system, IPsec can then be implemented without the need for additional peer credentials. Some vendors have implemented proprietary extensions for using Kerberos in IKEv1, as an alternative to the use of KINK. These extensions, as well as the KINK protocol, apply only to IKEv1, and not to IKEv2.
Kerberized Internet Negatiation of Keys（Kink）は、IPSECピア認証のためのIKEの代替手段を提供する試みです。Ikeの代わりにKerberosを使用して、IPSEC SASを確立します。Kerberos集中化されたキー管理システムを既に展開している企業の場合、IPSECを追加のピア資格情報を必要とせずに実装できます。一部のベンダーは、キンクの使用に代わるものとして、IKEV1でKerberosを使用するための独自の拡張機能を実装しています。これらの拡張機能とKinkプロトコルは、IKEV1にのみ適用され、IKEV2には適用されません。
[RFC3129] considers that peer-to-peer authentication and keying mechanisms have inherent drawbacks such as computational complexity and difficulty in enforcing security policies. This document specifies the requirements for using basic features of Kerberos and uses them to its advantage to create a protocol that can establish and maintain IPsec security associations ([RFC2401]).
[RFC3129]は、ピアツーピア認証とキーイングメカニズムには、計算の複雑さやセキュリティポリシーの実施の難しさなどの固有の欠点があると考えています。このドキュメントは、Kerberosの基本的な機能を使用するための要件を指定し、それらを有利に使用して、IPSECセキュリティ関連を確立および維持できるプロトコルを作成します（[RFC2401]）。
7.5.2. RFC 4430, Kerberized Internet Negotiation of Keys (KINK) (S, March 2006)
7.5.2. RFC 4430、Kerberized Internet Negotiation of Keys（Kink）（S、2006年3月）
[RFC4430] defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. This document reuses the Quick Mode payloads of IKEv1 in order to foster substantial reuse of IKEv1 implementations. This RFC has not been widely adopted.
[RFC4430]は、Kerberos認証システムを使用してセキュリティ関連を確立および維持するために、低遅延、計算的に安価で簡単に管理され、暗号化されたサウンドプロトコルを定義します。このドキュメントでは、IKEV1の実装の実質的な再利用を促進するために、IKEV1のクイックモードペイロードを再利用します。このRFCは広く採用されていません。
IPsec Secure Remote Access (IPSRA) was an attempt to extend IPsec protection to "road warriors", allowing IKE to authenticate not only the user's device but also the user, without changing IKEv1. The working group defined generic requirements of different IPsec remote access scenarios. An attempt was made to define an IKE-like protocol that would use legacy authentication mechanisms to create a temporary or short-lived user credential that could be used for peer authentication within IKE. This protocol proved to be more cumbersome than standard Public Key protocols, and was abandoned. This led to the development of IKEv2, which incorporates the use of EAP for user authentication.
IPSEC Secure Remote Access（IPSRA）は、IPSEC保護を「ロードウォリアーズ」に拡張する試みであり、IKEはIKEV1を変更せずにユーザーのデバイスだけでなくユーザーも認証できるようにしました。ワーキンググループは、さまざまなIPSECリモートアクセスシナリオの一般的な要件を定義しました。Legacy認証メカニズムを使用して、IKE内のピア認証に使用できる一時的または短命のユーザー資格情報を作成するIKEのようなプロトコルを定義する試みが行われました。このプロトコルは、標準的な公開キープロトコルよりも面倒であることが判明し、放棄されました。これにより、ユーザー認証のためにEAPを使用するIKEV2の開発につながりました。
7.6.1. RFC 3457, Requirements for IPsec Remote Access Scenarios (I, January 2003)
7.6.1. RFC 3457、IPSECリモートアクセスシナリオの要件（i、2003年1月）
[RFC3457] explores and enumerates the requirements of various IPsec remote access scenarios, without suggesting particular solutions for them.
[RFC3457]は、特定のソリューションを提案することなく、さまざまなIPSECリモートアクセスシナリオの要件を調査および列挙します。
[RFC3456] explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (DHCPv4) may be used for providing such configuration information. This RFC has not been widely adopted.
[RFC3456]は、IPSECトンネルモードでのホスト構成の要件を調査し、そのような構成情報を提供するために動的ホスト構成プロトコル（DHCPV4）をどのように使用できるかを説明します。このRFCは広く採用されていません。
The IPsec Keying Information Resource Record (IPSECKEY) enables the storage of public keys and other information that can be used to facilitate opportunistic IPsec in a new type of DNS resource record.
IPSECキーイング情報リソースレコード（IPSECKEY）により、新しいタイプのDNSリソースレコードで日和見的なIPSECを促進するために使用できるパブリックキーやその他の情報の保存が可能になります。
7.7.1. RFC 4025, A method for storing IPsec keying material in DNS (S, February 2005)
7.7.1. RFC 4025、DNSにIPSECキーイン素材を保存する方法（S、2005年2月）
[RFC4025] describes a method of storing IPsec keying material in the DNS using a new type of resource record. This document describes how to store the public key of the target node in this resource record. This RFC has not been widely adopted.
[RFC4025]は、新しいタイプのリソースレコードを使用して、DNSにIPSECキーイング材料を保存する方法を説明しています。このドキュメントでは、このリソースレコードにターゲットノードの公開キーを保存する方法について説明します。このRFCは広く採用されていません。
IPsec and IKE were designed to provide IP-layer security protection to other Internet protocols' traffic as well as generic communications. Since IPsec is a general-purpose protocol, in some cases, its features do not provide the granularity or distinctive features required by another protocol; in some cases, its overhead or prerequisites do not match another protocol's requirements. However, a number of other protocols do use IKE and/or IPsec to protect some or all of their communications.
IPSECとIKEは、他のインターネットプロトコルのトラフィックや一般的な通信にIP層セキュリティ保護を提供するように設計されています。IPSECは汎用プロトコルであるため、場合によっては、その機能は、別のプロトコルで必要な粒度または特徴的な機能を提供しません。場合によっては、そのオーバーヘッドまたは前提条件が別のプロトコルの要件と一致しません。ただし、他の多くのプロトコルでは、IKEおよび/またはIPSECを使用して、通信の一部またはすべてを保護しています。
[RFC4093] describes the issues with deploying Mobile IPv4 across virtual private networks (VPNs). IPsec is one of the VPN technologies covered by this document. It identifies and describes practical deployment scenarios for Mobile IPv4 running alongside IPsec in enterprise and operator environments. It also specifies a set of framework guidelines to evaluate proposed solutions for supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN gateways.
[RFC4093]は、仮想プライベートネットワーク（VPN）にモバイルIPv4を展開する問題を説明しています。IPSECは、このドキュメントでカバーされているVPNテクノロジーの1つです。エンタープライズ環境およびオペレーター環境でIPSECと並んで実行されているモバイルIPv4の実用的な展開シナリオを特定および説明します。また、IPSECベースのVPNゲートウェイ全体でマルチベンダーのシームレスなIPv4モビリティをサポートするための提案されたソリューションを評価するための一連のフレームワークガイドラインを指定します。
8.1.2. RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways (S, June 2008)
8.1.2. RFC 5265、IPSECベースのVPNゲートウェイを横断するモバイルIPv4トラバーサル（S、2008年6月）
[RFC5265] describes a basic solution that uses Mobile IPv4 and IPsec to provide session mobility between enterprise intranets and external networks. The proposed solution minimizes changes to existing firewall/VPN/DMZ deployments and does not require any changes to IPsec or key exchange protocols. It also proposes a mechanism to minimize IPsec renegotiation when the mobile node moves.
[RFC5265]は、モバイルIPv4とIPSECを使用してエンタープライズイントラネットと外部ネットワーク間のセッションモビリティを提供する基本的なソリューションを説明しています。提案されたソリューションは、既存のファイアウォール/VPN/DMZ展開の変更を最小限に抑え、IPSECまたはキー交換プロトコルの変更は必要ありません。また、モバイルノードが移動したときにIPSEC再交渉を最小限に抑えるメカニズムを提案します。
This document specifies the use of IPsec in securing Mobile IPv6 traffic between mobile nodes and home agents. It specifies the required wire formats for the protected packets and illustrates examples of Security Policy Database and Security Association Database entries that can be used to protect Mobile IPv6 signaling messages. It also describes how to configure either manually keyed IPsec security associations or IKEv1 to establish the SAs automatically. Mobile IPv6 requires considering the home address destination option and Routing Header in IPsec processing. Also, IPsec and IKE security association addresses can be updated by Mobile IPv6 signaling messages.
このドキュメントは、モバイルノードとホームエージェント間のモバイルIPv6トラフィックを保護する際のIPSECの使用を指定しています。保護されたパケットに必要なワイヤー形式を指定し、モバイルIPv6シグナル伝達メッセージを保護するために使用できるセキュリティポリシーデータベースおよびセキュリティアソシエーションデータベースエントリの例を示しています。また、SASを自動的に確立するために、手動でキー付きIPSECセキュリティアソシエーションまたはIKEV1を構成する方法についても説明します。モバイルIPv6では、IPSEC処理でホームアドレスの宛先オプションとルーティングヘッダーを考慮する必要があります。また、IPSECおよびIKEセキュリティ協会のアドレスは、モバイルIPv6シグナリングメッセージによって更新できます。
This document updates [RFC3776] in order to work with the revised IPsec architecture [RFC4301]. Since the revised IPsec architecture expands the list of selectors to include the Mobility Header message type, it becomes much easier to differentiate between different mobility header messages. Since the ICMP message type and code are also newly added as selectors, this document uses them to protect Mobile Prefix Discovery messages. This document also specifies the use of IKEv2 configuration payloads for dynamic home address configuration. Finally, this document describes the use of IKEv2 in order to set up the SAs for Mobile IPv6.
このドキュメントは、改訂されたIPSECアーキテクチャ[RFC4301]を使用するために[RFC3776]を更新します。改訂されたIPSECアーキテクチャは、モビリティヘッダーメッセージタイプを含めるようにセレクターのリストを拡張するため、異なるモビリティヘッダーメッセージを区別するのがはるかに簡単になります。ICMPメッセージの種類とコードもセレクターとして新しく追加されているため、このドキュメントではモバイルプレフィックスディスカバリーメッセージを保護するために使用します。このドキュメントは、動的ホームアドレス構成にIKEV2構成ペイロードの使用も指定しています。最後に、このドキュメントでは、モバイルIPv6のSASをセットアップするためのIKEV2の使用について説明します。
8.1.5. RFC 5026, Mobile IPv6 Bootstrapping in Split Scenario (S, October 2007)
8.1.5. RFC 5026、スプリットシナリオでのモバイルIPv6ブートストラップ（S、2007年10月）
[RFC5026] extends [RFC4877] to support dynamic discovery of home agents and the home network prefix; for the latter purpose, it specifies a new IKEv2 configuration attribute and notification. It describes how a Mobile IPv6 node can obtain the address of its home agent, its home address, and create IPsec security associations with its home agent using DNS lookups and security credentials preconfigured on the Mobile Node. It defines how a mobile node (MN) can request its home address and home prefixes through the Configuration Payload in the IKE_AUTH exchange and what attributes need to be present in the CFG_REQUEST messages in order to do this. It also specifies how the home agent can authorize the credentials used for IKEv2 exchange.
[RFC5026]は[RFC4877]を拡張して、ホームエージェントとホームネットワークプレフィックスの動的な発見をサポートします。後者の目的のために、新しいIKEV2構成属性と通知を指定します。モバイルIPv6ノードがホームエージェントのアドレス、ホームアドレスのアドレスを取得し、モバイルノードで事前に設定されたDNSルックアップとセキュリティ資格情報を使用してホームエージェントとIPSECセキュリティ関連を作成する方法を説明します。これを行うには、モバイルノード（MN）がIKE_AUTH Exchangeの構成ペイロードを介してホームアドレスとホームプレフィックスを要求する方法と、CFG_REQUESTメッセージに存在する必要がある属性を定義します。また、ホームエージェントがIKEV2 Exchangeに使用される資格情報をどのように承認できるかを指定します。
[RFC5213] describes a network-based mobility management protocol that is used to provide mobility services to hosts without requiring their participation in any mobility-related signaling. It uses IPsec to protect the mobility signaling messages between the two network entities called the mobile access gateway (MAG) and the local mobility anchor (LMA). It also uses IKEv2 in order to set up the security associations between the MAG and the LMA.
[RFC5213]は、モビリティ関連のシグナル伝達への参加を必要とせずにホストにモビリティサービスを提供するために使用されるネットワークベースのモビリティ管理プロトコルを説明しています。IPSECを使用して、モバイルアクセスゲートウェイ（MAG）とローカルモビリティアンカー（LMA）と呼ばれる2つのネットワークエンティティ間のモビリティシグナリングメッセージを保護します。また、MAGとLMAの間にセキュリティ関連を設定するためにIKEV2を使用します。
When Mobile IPv6 is used for a handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. [RFC5568] specifies a protocol between the Previous Access Router (PAR) and the New Access Router (NAR) to improve handover latency due to Mobile IPv6 procedures. It uses IPsec ESP in transport mode with integrity protection for protecting the signaling messages between the PAR and the NAR. It also describes the SPD entries and the PAD entries when IKEv2 is used for setting up the required SAs.
モバイルIPv6がハンドオーバーに使用される場合、リンクの切り替え遅延とIPプロトコル操作のために、モバイルノードがパケットを送信または受信できない期間があります。[RFC5568]は、モバイルIPv6手順によりハンドオーバーレイテンシを改善するために、以前のアクセスルーター（PAR）と新しいアクセスルーター（NAR）の間のプロトコルを指定します。PARとNARの間の信号メッセージを保護するために、整合性保護を備えたIPSEC ESPを輸送モードで使用します。また、IKEV2が必要なSASのセットアップに使用される場合のSPDエントリとパッドエントリについても説明します。
8.1.8. RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management (S, October 2008)
8.1.8. RFC 5380、階層モバイルIPv6（HMIPV6）モビリティ管理（S、2008年10月）
[RFC5380] describes extensions to Mobile IPv6 and IPv6 Neighbor Discovery to allow for local mobility handling in order to reduce the amount of signaling between the mobile node, its correspondent nodes, and its home agent. It also improves handover speed of Mobile IPv6. It uses IPsec for protecting the signaling between the mobile node and a local mobility management entity called the Mobility Anchor Point (MAP). The MAP also uses IPsec Peer Authorization Database (PAD) entries and configuration payloads described in [RFC4877] in order to allocate a Regional Care-of Address (RCoA) for mobile nodes.
[RFC5380]は、モバイルノード、その特派員ノード、およびホームエージェント間のシグナリングの量を減らすために、ローカルモビリティハンドリングを可能にするために、モバイルIPv6およびIPv6ネイバーディスカバリーへの拡張を説明しています。また、モバイルIPv6のハンドオーバー速度も向上します。IPSECを使用して、モバイルノードとモビリティアンカーポイント（MAP）と呼ばれるローカルモビリティ管理エンティティの間のシグナリングを保護します。マップは、モバイルノードに地域のケアアドレス（RCOA）を割り当てるために、[RFC4877]で説明されている[RFC4877]で説明されているIPSEC Peer Authorizationデータベース（PAD）エントリと構成ペイロードも使用します。
8.2.1. RFC 4552, Authentication/Confidentiality for OSPFv3 (S, June 2006)
8.2.1. RFC 4552、OSPFV3の認証/機密性（S、2006年6月）
OSPF is a link-state routing protocol that is designed to be run inside a single Autonomous System. OSPFv2 provided its own authentication mechanisms using the AuType and Authentication protocol header fields but OSPFv3 removed these fields and uses IPsec instead. [RFC4552] describes how to use IPsec ESP and AH in order to protect OSPFv3 signaling between two routers. It also enumerates the IPsec capabilities the routers require in order to support this specification. Finally, it also describes the operation of OSPFv3 with IPsec over virtual links where the other endpoint is not known at configuration time. Since OSPFv3 exchanges multicast packets as well as unicast ones, the use of IKE within OSPFv3 is not appropriate. Therefore, this document mandates the use of manual keys.
OSPFは、単一の自律システム内で実行されるように設計されたリンク状態ルーティングプロトコルです。OSPFV2は、Autypeおよび認証プロトコルヘッダーフィールドを使用して独自の認証メカニズムを提供しましたが、OSPFV3はこれらのフィールドを削除し、代わりにIPSECを使用します。[RFC4552]は、2つのルーター間のOSPFV3シグナル伝達を保護するために、IPSEC ESPとAHを使用する方法について説明しています。また、この仕様をサポートするためにルーターが必要とするIPSEC機能を列挙します。最後に、構成時間で他のエンドポイントが不明な仮想リンクを介したIPSECを使用したOSPFV3の動作についても説明します。OSPFV3はマルチキャストパケットとユニキャストパケットを交換するため、OSPFV3内でのIKEの使用は適切ではありません。したがって、このドキュメントでは、手動キーの使用が義務付けられています。
IP addresses perform two distinct functions: host identifier and locator. This document specifies a protocol that allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses. This enables continuity of communications across IP address (locator) changes. It uses public key identifiers from a new Host Identity (HI) namespace for peer authentication. It uses the HMAC-SHA-1-96 and the AES-CBC algorithms with IPsec ESP and AH for protecting its signaling messages.
IPアドレスは、ホスト識別子とロケーターの2つの異なる関数を実行します。このドキュメントは、同意するホストが共有IP層状態を安全に確立および維持できるようにするプロトコルを指定し、IPアドレスの識別子とロケーターの役割を分離できるようにします。これにより、IPアドレス（ロケーター）の変更を介した通信の連続性が可能になります。ピア認証には、新しいホストID（HI）名前空間からの公開キー識別子を使用します。IPSEC ESPとAHを使用したHMAC-SHA-1-96とAES-CBCアルゴリズムを使用して、シグナル伝達メッセージを保護します。
8.3.2. RFC 5202, Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (E, April 2008)
8.3.2. RFC 5202、ホストIDプロトコル（E、2008年4月）を使用して、セキュリティペイロード（ESP）トランスポートフォーマットを使用して
The HIP base exchange specification [RFC5201] does not describe any transport formats or methods for describing how ESP is used to protect user data to be used during the actual communication. [RFC5202] specifies a set of HIP extensions for creating a pair of ESP Security Associations (SAs) between the hosts during the base exchange. After the HIP association and required ESP SAs have been established between the hosts, the user data communication is protected using ESP. In addition, this document specifies how the ESP Security Parameter Index (SPI) is used to indicate the right host context (host identity) and methods to update an existing ESP Security Association.
HIPベース交換仕様[RFC5201]は、実際の通信中に使用されるユーザーデータを保護するためにESPを使用する方法を説明するための輸送形式または方法を説明していません。[RFC5202]は、基本交換中にホスト間でESPセキュリティ協会（SAS）のペアを作成するための一連の股関節拡張機能を指定します。股関節関連と必要なESP SAがホスト間で確立された後、ユーザーデータ通信はESPを使用して保護されます。さらに、このドキュメントは、ESPセキュリティパラメーターインデックス（SPI）を使用して、正しいホストコンテキスト（ホストID）と既存のESPセキュリティ協会を更新する方法を示す方法を指定します。
When a host uses HIP, the overlying protocol sublayers (e.g., transport layer sockets) and Encapsulating Security Payload (ESP) Security Associations (SAs) are bound to representations of these host identities, and the IP addresses are only used for packet forwarding. [RFC5206] defines a generalized LOCATOR parameter for use in HIP messages that allows a HIP host to notify a peer about alternate addresses at which it is reachable. It also specifies how a host can change its IP address and continue to send packets to its peers without necessarily rekeying.
ホストが股関節を使用すると、上にあるプロトコルサブレイヤー（輸送層ソケットなど）とセキュリティペイロード（ESP）セキュリティ協会（SAS）のカプセル化は、これらのホストIDの表現に拘束され、IPアドレスはパケット転送にのみ使用されます。[RFC5206]は、ヒップホストが到達可能な代替アドレスについてピアに通知できるヒップメッセージで使用する一般化されたロケーターパラメーターを定義します。また、ホストがIPアドレスを変更し、必ずしも再キーをかけずにピアにパケットを送信し続ける方法を指定します。
[RFC5207] discusses the problems associated with HIP communication across network paths that include network address translators and firewalls. It analyzes the impact of NATs and firewalls on the HIP base exchange and the ESP data exchange. It discusses possible changes to HIP that attempt to improve NAT and firewall traversal and proposes a rendezvous point for letting HIP nodes behind a NAT be reachable. It also suggests mechanisms for NATs to be more aware of the HIP messages.
[RFC5207]は、ネットワークアドレスの翻訳者やファイアウォールを含むネットワークパスを越えた股関節通信に関連する問題について説明します。股関節ベース交換とESPデータ交換に対するNATとファイアウォールの影響を分析します。NATとファイアウォールのトラバーサルを改善しようとする股関節の変化の可能性について議論し、NATの後ろに股関節ノードを到達可能にするためのランデブーポイントを提案します。また、NATが股関節メッセージをより意識するメカニズムを示唆しています。
8.4.1. RFC 3554, On the Use of Stream Control Transmission Protocol (SCTP) with IPsec (S, July 2003)
8.4.1. RFC 3554、IPSECを使用したストリーム制御伝送プロトコル（SCTP）の使用（S、2003年7月）
The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connection-less packet network such as IP. [RFC3554] describes functional requirements for IPsec and IKE to be used in securing SCTP traffic. It adds support for SCTP in the form of a new ID type in IKE [RFC2409] and implementation choices in the IPsec processing to account for the multiple source and destination addresses associated with a single SCTP association. This document applies only to IKEv1 and IPsec-v2; it does not apply to IKEv2 AND IPsec-v3.
Stream Control Transmission Protocol（SCTP）は、IPなどの接続のないパケットネットワークの上で動作する信頼できるトランスポートプロトコルです。[RFC3554]は、SCTPトラフィックの保護に使用されるIPSECとIKEの機能要件を説明しています。IKE [RFC2409]の新しいIDタイプの形でSCTPのサポートと、単一のSCTP関連に関連する複数のソースおよび宛先アドレスを考慮して、IPSEC処理の実装選択肢を追加します。このドキュメントは、IKEV1およびIPSEC-V2にのみ適用されます。IKEV2およびIPSEC-V3には適用されません。
ROHC is a framework for header compression, intended to be used in resource-constrained environments. [RFC3095] applies this framework to four protocols, including ESP.
ROHCは、リソースに制約のある環境で使用されることを目的としたヘッダー圧縮のフレームワークです。[RFC3095]は、このフレームワークをESPを含む4つのプロトコルに適用します。
[RFC5225] defines an updated ESP/IP profile for use with ROHC version 2. It analyzes the ESP header and classifies the fields into several classes like static, well-known, irregular, etc., in order to efficiently compress the headers.
[RFC5225]は、ROHCバージョン2で使用する更新されたESP/IPプロファイルを定義します。ESPヘッダーを分析し、ヘッダーを効率的に圧縮するために、静的、よく知られている、不規則なようなようないくつかのクラスに分類します。
[RFC5856] describes a mechanism to compress inner IP headers at the ingress point of IPsec tunnels and to decompress them at the egress point. Since the Robust Header Compression (ROHC) specifications only describe operations on a per-hop basis, this document also specifies extensions to enable ROHC over multiple hops. This document applies only to tunnel mode SAs and does not support transport mode SAs.
[RFC5856]は、IPSECトンネルの入り口で内側のIPヘッダーを圧縮し、出口点でそれらを減圧するメカニズムを説明しています。堅牢なヘッダー圧縮（ROHC）仕様は、ホップごとの操作のみを記述するため、このドキュメントは複数のホップでROHCを有効にする拡張機能も指定しています。このドキュメントは、トンネルモードSASにのみ適用され、輸送モードSASをサポートしていません。
ROHC requires initial configuration at the compressor and decompressor ends. Since ROHC usually operates on a per-hop basis, this configuration information is carried over link-layer protocols such as PPP. Since [RFC5856] operates over multiple hops, a different signaling mechanism is required. [RFC5857] describes how to use IKEv2 in order to dynamically communicate the configuration parameters between the compressor and decompressor.
ROHCには、コンプレッサーと減圧装置の終了時に初期構成が必要です。ROHCは通常、ホップごとに動作しているため、この構成情報はPPPなどのリンク層プロトコルに掲載されます。[RFC5856]は複数のホップで動作するため、異なるシグナル伝達メカニズムが必要です。[RFC5857]は、コンプレッサーと減圧装置間の構成パラメーターを動的に通信するためにIKEV2を使用する方法について説明します。
[RFC5856] describes how to use ROHC with IPsec. This is not possible without extensions to IPsec. [RFC5858] describes the extensions needed to IPsec in order to support ROHC. Specifically, it describes extensions needed to the IPsec SPD, SAD, and IPsec processing including ICV computation and integrity verification.
[RFC5856]は、IPSECでROHCを使用する方法について説明しています。これは、IPSECへの拡張なしでは不可能です。[RFC5858]は、ROHCをサポートするためにIPSECに必要な拡張機能を説明しています。具体的には、ICVの計算と整合性の検証を含むIPSEC SPD、SAD、およびIPSEC処理に必要な拡張機能を説明しています。
8.6.1. RFC 5566, BGP IPsec Tunnel Encapsulation Attribute (S, June 2009)
8.6.1. RFC 5566、BGP IPSECトンネルカプセル化属性（S、2009年6月）
[RFC5566] adds an additional BGP Encapsulation Subsequent Address Family Identifier (SAFI), allowing the use of IPsec and, optionally, IKE to protect BGP tunnels. It defines the use of AH and ESP in tunnel mode and the use of AH and ESP in transport mode to protect IP in IP and MPLS-in-IP tunnels. It also defines how public key fingerprints (hashes) are distributed via BGP and used later to authenticate IKEv2 exchange between the tunnel endpoints.
[RFC5566]は、追加のBGPカプセル化を追加し、その後のアドレスファミリ識別子（SAFI）を追加し、IPSECおよびオプションでは、BGPトンネルを保護するためにIKEを使用できるようにします。トンネルモードでのAHとESPの使用と、IPおよびMPLS-in-IPトンネルでのIPを保護するためのAHとESPの使用を輸送モードで使用します。また、公開キーの指紋（ハッシュ）がBGPを介してどのように分布し、後でトンネルのエンドポイント間でIKEV2交換を認証するために使用される方法を定義します。
The Benchmarking Methodology WG in the IETF is working on documents that relate to benchmarking IPsec [BMWG-1] [BMWG-2].
IETFのベンチマーク方法論WGは、IPSEC [BMWG-1] [BMWG-2]のベンチマークに関連するドキュメントに取り組んでいます。
[BMWG-1] defines a set of tests that can be used to measure and report the performance characteristics of IPsec devices. It extends the methodology defined for benchmarking network interconnecting devices to include IPsec gateways and adds further tests that can be used to measure IPsec performance of end-hosts. The document focuses on establishing a performance testing methodology for IPsec devices that support manual keying and IKEv1, but does not cover IKEv2.
[BMWG-1]は、IPSECデバイスのパフォーマンス特性を測定および報告するために使用できる一連のテストを定義します。ベンチマークネットワークの相互接続デバイスをベンチマークするために定義された方法論を拡張して、IPSECゲートウェイを含め、エンドホストのIPSECパフォーマンスを測定するために使用できるさらにテストを追加します。このドキュメントは、マニュアルキーイングとIKEV1をサポートするが、IKEV2をカバーしていないIPSECデバイスのパフォーマンステスト方法の確立に焦点を当てています。
[BMWG-2] defines the standardized performance testing terminology for IPsec devices that support manual keying and IKEv1. It also describes the benchmark tests that would be used to test the performance of the IPsec devices.
[BMWG-2]は、マニュアルキーイングとIKEV1をサポートするIPSECデバイスの標準化されたパフォーマンステスト用語を定義しています。また、IPSECデバイスのパフォーマンスをテストするために使用されるベンチマークテストについても説明しています。
8.8.1. RFC 2709, Security Model with Tunnel-mode IPsec for NAT domains (I, October 1999)
8.8.1. RFC 2709、NATドメイン用のトンネルモードIPSECを備えたセキュリティモデル（I、1999年10月）
NAT devices provide transparent routing to end-hosts trying to communicate from disparate address realms, by modifying IP and transport headers en route. This makes it difficult for applications to pursue end-to-end application-level security. [RFC2709] describes a security model by which tunnel mode IPsec security can be architected on NAT devices. It defines how NATs administer security policies and SA attributes based on private realm addressing. It also specifies how to operate IKE in such scenarios by specifying an IKE-ALG (Application Level Gateway) that translates policies from private realm addressing into public addressing. Although the model presented here uses terminology from IKEv1, it can be deployed within IKEv1, IKEv2, IPsec-v2, and IPsec-v3. This security model has not been widely adopted
NATデバイスは、IPとトランスポートヘッダーを途中で変更することにより、異なるアドレスレルムから通信しようとするエンドホストへの透明なルーティングを提供します。これにより、アプリケーションがエンドツーエンドのアプリケーションレベルのセキュリティを追求することが困難になります。[RFC2709]は、Tunnel Mode IPSECセキュリティをNATデバイスでアーキテクチャ化できるセキュリティモデルを説明しています。NATSがプライベートレルムアドレス指定に基づいてセキュリティポリシーとSA属性を管理する方法を定義します。また、Private Realmのアドレス指定からパブリックアドレス指定にポリシーを変換するIKE-ALG（アプリケーションレベルゲートウェイ）を指定することにより、このようなシナリオでIKEを操作する方法を指定します。ここで提示されたモデルはIKEV1の用語を使用していますが、IKEV1、IKEV2、IPSEC-V2、およびIPSEC-V3内で展開できます。このセキュリティモデルは広く採用されていません
[RFC3329] describes how a SIP client can select one of the various available SIP security mechanisms. In particular, the method allows secure negotiation to prevent bidding down attacks. It also describes a security mechanism called ipsec-3gpp and its associated parameters (algorithms, protocols, mode, SPIs and ports) as they are used in the 3GPP IP Multimedia Subsystem.
[RFC3329]は、SIPクライアントが利用可能なさまざまなSIPセキュリティメカニズムのいずれかを選択する方法を説明しています。特に、この方法により、安全な交渉が許可され、入札攻撃を防ぐことができます。また、3GPP IPマルチメディアサブシステムで使用されているIPSEC-3GPPと関連するパラメーター（アルゴリズム、プロトコル、モード、スピス、ポート）と呼ばれるセキュリティメカニズムについても説明します。
8.10.1. RFC 5570, Common Architecture Label IPv6 Security Option (CALIPSO) (I, July 2009)
8.10.1. RFC 5570、一般的なアーキテクチャラベルIPv6セキュリティオプション（Calipso）（i、2009年7月）
[RFC5570] describes a mechanism used to encode explicit packet Sensitivity Labels on IPv6 packets in Multi-Level Secure (MLS) networks. The method is implemented using an IPv6 hop-by-hop option. This document uses the IPsec Authentication Header (AH) in order to detect any malicious modification of the Sensitivity Label in a packet.
[RFC5570]は、マルチレベルのセキュア（MLS）ネットワークのIPv6パケット上の明示的なパケット感度ラベルをエンコードするために使用されるメカニズムを説明しています。このメソッドは、IPv6ホップバイホップオプションを使用して実装されます。このドキュメントでは、IPSEC認証ヘッダー（AH）を使用して、パケット内の感度ラベルの悪意のある変更を検出します。
Some protocols protect their traffic through mechanisms other than IPsec, but use IKEv2 as a basis for their key negotiation and key management functionality.
一部のプロトコルは、IPSEC以外のメカニズムを介してトラフィックを保護しますが、IKEV2を主要な交渉と主要な管理機能の基礎として使用します。
9.1.1. RFC 5106, The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method (E, February 2008)
9.1.1. RFC 5106、拡張可能な認証プロトコルインターネットキーエクスチェンジプロトコルバージョン2（EAP-kikev2）メソッド（E、2008年2月）
[RFC5106] specifies an Extensible Authentication Protocol (EAP) method that is based on the Internet Key Exchange version 2 (IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session-key establishment between an EAP peer and an EAP server. It describes the full EAP-IKEv2 message exchange and the composition of the protocol messages.
[RFC5106]は、インターネットキーエクスチェンジバージョン2（IKEV2）プロトコルに基づいた拡張可能な認証プロトコル（EAP）メソッドを指定します。EAP-kikev2は、EAPピアとEAPサーバーの間で相互認証とセッションキーの確立を提供します。完全なEAP-kikev2メッセージ交換とプロトコルメッセージの構成について説明します。
Fibre Channel (FC) is a gigabit-speed network technology used for Storage Area Networking. The Fibre Channel Security Protocols (FC-SP) standard has adapted the IKEv2 protocol [RFC4306] to provide authentication of Fibre Channel entities and setup of security associations. Since IP is transported over Fibre Channel and Fibre Channel is transported over IP, there is the potential for confusion when IKEv2 is used for both IP and FC traffic. [RFC4595] specifies identifiers for IKEv2 over FC in a fashion that ensures that any mistaken usage of IKEv2/FC over IP or IKEv2/IP over FC will result in a negotiation failure due to the absence of an acceptable proposal.
Fiber Channel（FC）は、ストレージエリアネットワーキングに使用されるギガビットスピードネットワークテクノロジーです。ファイバーチャネルセキュリティプロトコル（FC-SP）標準は、IKEV2プロトコル[RFC4306]を適応させ、ファイバーチャネルエンティティの認証とセキュリティ関連のセットアップを提供しました。IPはファイバーチャネルを介して輸送され、ファイバーチャネルはIPで輸送されるため、IKEV2がIPトラフィックとFCトラフィックの両方に使用される場合、混乱の可能性があります。[RFC4595]は、FCを介したIKEV2の識別子を、IPまたはIKEV2/IPを介したIKEV2/FCをFC上で誤って使用することで、許容可能な提案がないため交渉の失敗をもたらすことを保証する方法で指定します。
9.3.1. RFC 4705, GigaBeam High-Speed Radio Link Encryption (I, October 2006)
9.3.1. RFC 4705、Gigabeam高速無線リンク暗号化（I、2006年10月）
[RFC4705] describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio-link products and is intended to serve as a guideline for similar wireless product development efforts to include comparable capabilities. It specifies the algorithms that are used to provide confidentiality and integrity protection of both subscriber and management traffic. It also specifies a custom security protocol that runs between two Gigabeam Radio Control Modules (RCMs).
[RFC4705]は、GigabeamがWifiber（TM）ファミリーのラジオリンク製品の一部として使用する暗号化と主要な管理を説明しており、同様のワイヤレス製品開発努力のガイドラインとして、同等の機能を含めることを目的としています。サブスクライバーと管理トラフィックの両方の機密性と整合性保護を提供するために使用されるアルゴリズムを指定します。また、2つのGigabeam Radio Controlモジュール（RCM）の間で実行されるカスタムセキュリティプロトコルも指定します。
The authors would like to thank Yaron Sheffer, Paul Hoffman, Yoav Nir, Rajeshwar Singh Jenwar, Alfred Hoenes, Al Morton, Gabriel Montenegro, Sean Turner, Julien Laganier, Grey Daley, Scott Moonen, Richard Graveman, Tero Kivinen, Pasi Eronen, Ran Atkinson, David Black, and Tim Polk for reviewing this document and suggesting changes.
著者は、ヤロン・シェファー、ポール・ホフマン、ヨーブ・ニール、ラジェシュワル・シン・ジェンワール、アルフレッド・ホーネス、アル・モートン、ガブリエル・モンテネグロ、ショーン・ターナー、ジュリエン・ラガニエ、グレイ・デイリー、スコット・ムーナン、リチャード・グレイヴェマン、テロ・キビネン、パシ・エロネン、ラン・ラン・キビネンに感謝したいこの文書をレビューし、変更を提案してくれたアトキンソン、デビッドブラック、ティムポーク。
This RFC serves as a review of other documents and introduces no new security considerations itself; however, please see each of the individual documents described herein for security considerations related to each protocol.
このRFCは、他のドキュメントのレビューとして機能し、新しいセキュリティに関する考慮事項自体を導入しません。ただし、各プロトコルに関連するセキュリティ上の考慮事項については、本明細書に記載されている各ドキュメントを参照してください。
[BMWG-1] Kaeo, M. and T. Van Herck, "Methodology for Benchmarking IPsec Devices", Work in Progress, July 2009.
[BMWG-1] Kaeo、M。およびT. Van Herck、「IPSecデバイスのベンチマークの方法論」、2009年7月、進行中の作業。
[BMWG-2] Kaeo, M., Van Herck T., and M. Bustos, "Terminology for Benchmarking IPsec Devices", Work in Progress, July 2009.
[BMWG-2] Kaeo、M.、van Herck T.、およびM. Bustos、「ベンチマークIPSecデバイスの用語」、2009年7月、進行中の作業。
[IKE-MODE-CFG] Dukes, D. and R. Pereira, "The ISAKMP Configuration Method", Work in Progress, September 2001.
[ike-mode-cfg]デュークス、D。およびR.ペレイラ、「ISAKMP構成法」、2001年9月、作業中。
[IKE-XAUTH] Beaulieu, S. and R. Pereira, "Extended Authentication within IKE (XAUTH)", Work in Progress, October 2001.
[Ike-Xauth] Beaulieu、S。およびR. Pereira、「Ike（Xauth）内の拡張認証」、2001年10月、進行中の作業。
[ISAKMP-MODE-CFG] Pereira, R., Anand, S., and B. Patel, "The ISAKKMP Configuration Method", Work in Progress, August 1999.
[isakmp-mode-cfg] Pereira、R.、Anand、S。、およびB. Patel、「ISAKKMP構成法」、1999年8月の作業。
[ISAKMP-XAUTH] Pereira, R. and S. Beaulieu, "Extended Authentication within ISAKMP/Oakley (XAUTH)", Work in Progress, December 1999.
[ISAKMP-XAUTH] Pereira、R。およびS. Beaulieu、「Isakmp/Oakley（Xauth）内の拡張認証」、1999年12月、進行中の作業。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - 改訂3」、BCP 9、RFC 2026、1996年10月。
[RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, December 1998.
[RFC2394] Pereira、R。、「DEFLATEを使用したIPペイロード圧縮」、RFC 2394、1998年12月。
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998.
[RFC2395] Friend、R。およびR. Monsour、「LZSを使用したIPペイロード圧縮」、RFC 2395、1998年12月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[RFC2403] Madson、C。およびR. Glenn、「ESPおよびAH内のHMAC-MD5-96の使用」、RFC 2403、1998年11月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404] Madson、C。およびR. Glenn、「ESPおよびAH内のHMAC-SHA-1-96の使用」、RFC 2404、1998年11月。
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2405] Madson、C。およびN. Doraswamy、「ESP des-CBC暗号アルゴリズムを備えたIV」、RFC 2405、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408] Maughan、D.、Schertler、M.、Schneider、M.、およびJ. Turner、「Internet Security Association and Key Management Protocol（ISAKMP）」、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410] Glenn、R。およびS. Kent、「Null暗号化アルゴリズムとIPSECでの使用」、RFC 2410、1998年11月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411] Thayer、R.、Doraswamy、N。、およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412] Orman、H。、「The Oakley Key Deicination Protocol」、RFC 2412、1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、1998年11月。
[RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures Messages", RFC 2521, March 1999.
[RFC2521] Karn、P。およびW. Simpson、「ICMPセキュリティ障害メッセージ」、RFC 2521、1999年3月。
[RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999.
[RFC2709] Srisuresh、P。、「NATドメイン用のトンネルモードIPSECを備えたセキュリティモデル」、RFC 2709、1999年10月。
[RFC2857] Keromytis, A. and N. Provos, "The Use of HMAC-RIPEMD-160-96 within ESP and AH", RFC 2857, June 2000.
[RFC2857] Keromytis、A。およびN. Provos、「ESPおよびAH内のHMAC-RIPEMD-160-96の使用」、RFC 2857、2000年6月。
[RFC3051] Heath, J. and J. Border, "IP Payload Compression Using ITU-T V.44 Packet Method", RFC 3051, January 2001.
[RFC3051] Heath、J。およびJ. Border、「ITU-T V.44パケットメソッドを使用したIPペイロード圧縮」、RFC 3051、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC3129] Thomas, M., "Requirements for Kerberized Internet Negotiation of Keys", RFC 3129, June 2001.
[RFC3129] Thomas、M。、「Kerberized Internet Negotiation of Keysの要件」、RFC 3129、2001年6月。
[RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[RFC3173] Shacham、A.、Monsour、B.、Pereira、R。、およびM. Thomas、「IPペイロード圧縮プロトコル（IPComp）」、RFC 3173、2001年9月。
[RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003.
[RFC3329] Arkko、J.、Torvinen、V.、Camarillo、G.、Niemi、A。、およびT. Haukka、「セッション開始プロトコル（SIP）のセキュリティメカニズム契約」、RFC 3329、2003年1月。
[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
[RFC3456] Patel、B.、Aboba、B.、Kelly、S。、およびV. Gupta、「Ipsecトンネルモードの動的ホスト構成プロトコル（DHCPV4）構成」、RFC 3456、2003年1月。
[RFC3457] Kelly, S. and S. Ramamoorthi, "Requirements for IPsec Remote Access Scenarios", RFC 3457, January 2003.
[RFC3457] Kelly、S。およびS. Ramamoorthi、「IPSECリモートアクセスシナリオの要件」、RFC 3457、2003年1月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526] Kivinen、T。およびM. Kojo、「インターネットキーエクスチェンジ（IKE）のためのよりモジュラー指数（MODP）Diffie-Hellmanグループ」、RFC 3526、2003年5月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、RFC 3547、2003年7月。
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[RFC3554] Bellovin、S.、Ioannidis、J.、Keromytis、A。、およびR. Stewart、「IPSECを使用したストリーム制御伝送プロトコル（SCTP）の使用」、RFC 3554、2003年7月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3566]フランケル、S。およびH.ハーバート、「AES-XCBC-MAC-96アルゴリズムとIPSECでの使用」、RFC 3566、2003年9月。
[RFC3585] Jason, J., Rafalow, L., and E. Vyncke, "IPsec Configuration Policy Information Model", RFC 3585, August 2003.
[RFC3585] Jason、J.、Rafalow、L。、およびE. Vyncke、「IPSEC構成ポリシー情報モデル」、RFC 3585、2003年8月。
[RFC3586] Blaze, M., Keromytis, A., Richardson, M., and L. Sanchez, "IP Security Policy (IPSP) Requirements", RFC 3586, August 2003.
[RFC3586] Blaze、M.、Keromytis、A.、Richardson、M。、およびL. Sanchez、「IP Security Policy（IPSP）要件」、RFC 3586、2003年8月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]フランケル、S。、グレン、R。、およびS.ケリー、「AES-CBC暗号アルゴリズムとIPSECでのその使用」、RFC 3602、2003年9月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686] Housley、R。、「Advanced Encryption Standard（AES）カウンターモードを使用して、IPSECがセキュリティペイロードをカプセル化する（ESP）」、RFC 3686、2004年1月。
[RFC3706] Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers", RFC 3706, February 2004.
[RFC3706] Huang、G.、Beaulieu、S。、およびD. Rochefort、「死んだインターネットキーエクスチェンジ（IKE）ピアを検出するトラフィックベースの方法」、RFC 3706、2004年2月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B。およびW. Dixon、「Ipsec-Networkアドレス翻訳（NAT）互換性要件」、RFC 3715、2004年3月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T。およびB. Weis、「The Multicast Group Security Architecture」、RFC 3740、2004年3月。
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[RFC3776] Arkko、J.、Devarapalli、V。、およびF. Dupont、「IPSECを使用してモバイルノードとホームエージェント間のモバイルIPv6シグナル伝達を保護する」、RFC 3776、2004年6月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、RFC 3830、2004年8月。
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004.
[RFC3884] Touch、J.、Eggert、L。、およびY. Wang、「動的ルーティングのためのIPSEC輸送モードの使用」、RFC 3884、2004年9月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A。、およびV. Volpe、「IKEにおけるNat-Traversalの交渉」、RFC 3947、2005年1月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、Volpe、V.、Diburro、L。、およびM. Stenberg、「IPSEC ESPパケットのUDPカプセル化」、RFC 3948、2005年1月。
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005.
[RFC4025]リチャードソン、M。、「DNSにIPSECキーイング材料を保存する方法」、RFC 4025、2005年3月。
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005.
[RFC4046] Baugher、M.、Canetti、R.、Dondeti、L。、およびF. Lindholm、「マルチキャストセキュリティ（MSEC）グループキー管理アーキテクチャ」、RFC 4046、2005年4月。
[RFC4093] Adrangi, F., Ed., and H. Levkowetz, Ed., "Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, August 2005.
[RFC4093] Adrangi、F.、ed。、およびH. Levkowetz、ed。、「問題ステートメント：仮想プライベートネットワーク（VPN）ゲートウェイのモバイルIPv4トラバーサル」、RFC 4093、2005年8月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106] Viega、J。およびD. McGrew、「セキュリティペイロードをカプセル化するIPSEC（ESP）でのガロア/カウンターモード（GCM）の使用」、RFC 4106、2005年6月。
[RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version 1 (IKEv1)", RFC 4109, May 2005.
[RFC4109] Hoffman、P。、「インターネットキーエクスチェンジバージョン1（IKEV1）のアルゴリズム」、RFC 4109、2005年5月。
[RFC4196] Lee, H., Yoon, J., Lee, S., and J. Lee, "The SEED Cipher Algorithm and Its Use with IPsec", RFC 4196, October 2005.
[RFC4196] Lee、H.、Yoon、J.、Lee、S。、およびJ. Lee、「シード暗号アルゴリズムとIPSECでの使用」、RFC 4196、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)", RFC 4304, December 2005.
[RFC4304] Kent、S。、「インターネットセキュリティ協会および主要な管理プロトコル（ISAKMP）のIPSECドメイン（DOI）への拡張シーケンス番号（ESN）補遺」、RFC 4304、2005年12月。
[RFC4305] Eastlake 3rd, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[RFC4305] EastLake 3rd、D。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4305、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、RFC 4306、2005年12月。
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[RFC4307]シラー、J。、「インターネットキーエクスチェンジバージョン2（IKEV2）で使用する暗号化アルゴリズム」、RFC 4307、2005年12月。
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, December 2005.
[RFC4308] Hoffman、P。、「IPSEC用の暗号スイート」、RFC 4308、2005年12月。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[RFC4309] Housley、R。、「Advanced Encryption Standard（AES）CCMモードを使用して、IPSECがセキュリティペイロードをカプセル化する（ESP）を使用して」、RFC 4309、2005年12月。
[RFC4312] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher Algorithm and Its Use With IPsec", RFC 4312, December 2005.
[RFC4312] Kato、A.、Moriai、S。、およびM. Kanda、「Camellia cipherアルゴリズムとIPSECでの使用」、RFC 4312、2005年12月。
[RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)", RFC 4322, December 2005.
[RFC4322] Richardson、M。およびD. Redelmeier、「インターネットキーエクスチェンジ（IKE）を使用した日和見暗号化」、RFC 4322、2005年12月。
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006.
[RFC4359] Weis、B。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）のカプセル化内でのRSA/SHA-1シグネチャの使用」、RFC 4359、2006年1月。
[RFC4430] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006.
[RFC4430] Sakane、S.、Kamada、K.、Thomas、M。、およびJ. Vilhuber、「Kerberized Internet negotiation of Keys（Kink）」、RFC 4430、2006年3月。
[RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4434, February 2006.
[RFC4434] Hoffman、P。、「インターネットキーエクスチェンジプロトコル（IKE）のAES-XCBC-PRF-128アルゴリズム」、RFC 4434、2006年2月。
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4478, April 2006.
[RFC4478] NIR、Y。、「インターネットキーエクスチェンジ（IKEV2）プロトコルでの繰り返し認証」、RFC 4478、2006年4月。
[RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 Algorithm and Its Use with IPsec", RFC 4494, June 2006.
[RFC4494] Song、JH。、Poovendran、R。、およびJ. Lee、「AES-CMAC-96アルゴリズムとIPSECでの使用」、RFC 4494、2006年6月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535] Harney、H.、Meth、U.、Colegrove、A。、およびG. Gross、「GSAKMP：Group Secure Association Key Management Protocol」、RFC 4535、2006年6月。
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006.
[RFC4543] McGrew、D。およびJ. Viega、「IPSEC ESPおよびAHでのGaloisメッセージ認証コード（GMAC）の使用」、RFC 4543、2006年5月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552] Gupta、M。およびN. Melam、「OSPFV3の認証/機密性」、RFC 4552、2006年6月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555] Eronen、P。、「IKEV2モビリティおよびマルチホームプロトコル（MOBIKE）」、RFC 4555、2006年6月。
[RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", RFC 4595, July 2006.
[RFC4595] Maino、F。およびD. Black、「Fiber Channel Security Association Management ProtocolでのIKEV2の使用」、RFC 4595、2006年7月。
[RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006.
[RFC4615] Song、J.、Poovendran、R.、Lee、J。、およびT. Iwata、「高度な暗号化標準サイファーベースのメッセージ認証認証」）インターネットキーエクスチェンジプロトコル（IKE）のアルゴリズム "、RFC 4615、2006年8月。
[RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, August 2006.
[RFC4621] Kivinen、T。およびH. Tschofenig、「IKEV2モビリティとマルチホミング（Mobike）プロトコルの設計」、RFC 4621、2006年8月。
[RFC4705] Housley, R. and A. Corry, "GigaBeam High-Speed Radio Link Encryption", RFC 4705, October 2006.
[RFC4705] Housley、R。およびA. Corry、「Gigabeam High Speed Radio Link Encryption」、RFC 4705、2006年10月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
[RFC4718] Eronen、P。およびP. Hoffman、「IKEV2の説明と実装ガイドライン」、RFC 4718、2006年10月。
[RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol", RFC 4739, November 2006.
[RFC4739] Eronen、P。およびJ. Korhonen、「インターネットキーエクスチェンジ（IKEV2）プロトコルの複数の認証交換」、RFC 4739、2006年11月。
[RFC4753] Fu, D. and J. Solinas, "ECP Groups For IKE and IKEv2", RFC 4753, January 2007.
[RFC4753] Fu、D。およびJ. Solinas、「IKEおよびIKEV2のECPグループ」、RFC 4753、2007年1月。
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007.
[RFC4754] Fu、D。およびJ. Solinas、「IkeおよびIKEV2認証楕円曲線デジタル署名アルゴリズム（ECDSA）」、RFC 4754、2007年1月。
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007.
[RFC4806] Myers、M。およびH. Tschofenig、「オンライン証明書ステータスプロトコル（OCSP）IKEV2への拡張」、RFC 4806、2007年2月。
[RFC4807] Baer, M., Charlet, R., Hardaker, W., Story, R., and C. Wang, "IPsec Security Policy Database Configuration MIB", RFC 4807, March 2007.
[RFC4807] Baer、M.、Charlet、R.、Hardaker、W.、Story、R。、およびC. Wang、「IPSECセキュリティポリシーデータベース構成MIB」、RFC 4807、2007年3月。
[RFC4809] Bonatti, C., Ed., Turner, S., Ed., and G. Lebovitz, Ed., "Requirements for an IPsec Certificate Management Profile", RFC 4809, February 2007.
[RFC4809] Bonatti、C.、ed。、Turner、S.、ed。、およびG. Lebovitz、ed。、「IPSEC証明書管理プロファイルの要件」、RFC 4809、2007年2月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835] Manral、V。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4835、2007年4月。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC4868] Kelly、S。およびS. Frankel、「HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512を使用してIPSECを使用して」、RFC 4868、2007年5月。
[RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 4869, May 2007.
[RFC4869] Law、L。and J. Solinas、「IPSECのスイートB暗号スイート」、RFC 4869、2007年5月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877] Devarapalli、V。およびF. Dupont、「IKEV2および改訂されたIPSECアーキテクチャによるモバイルIPv6操作」、RFC 4877、2007年4月。
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007.
[RFC4891] Graveman、R.、Parthasarathy、M.、Savola、P。、およびH. Tschofenig、「IPSECを使用してIPv6-in-IPV4トンネルを保護する」、RFC 4891、2007年5月。
[RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec", RFC 4894, May 2007.
[RFC4894] Hoffman、P。、「インターネットキーエクスチェンジ（IKE）およびIPSECでのハッシュアルゴリズムの使用」、RFC 4894、2007年5月。
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[RFC4945] Korver、B。、「IKEV1/ISAKMP、IKEV2、およびPKIXのインターネットIPセキュリティPKIプロファイル」、RFC 4945、2007年8月。
[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026] Giaretta、G.、Ed。、Kempf、J。、およびV. Devarapalli、ed。、「SplitシナリオでのモバイルIPv6ブートストラップ」、RFC 5026、2007年10月。
[RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", RFC 5106, February 2008.
[RFC5106] Tschofenig、H.、Kroeselberg、D.、Pashalidis、A.、Ohba、Y.、およびF. Bersani、 "拡張可能な認証プロトコルインターネットキー交換プロトコルバージョン2（EAP-kikev2）メソッド、RFC 5106、2008年2月。
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.
[RFC5114] Lepinski、M。およびS. Kent、「IETF標準で使用する追加のDiffie-Hellmanグループ」、RFC 5114、2008年1月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P.、Ed。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5202] Jokela、P.、Moskowitz、R。、およびP. Nikander、「ホストIDプロトコル（HIP）を使用したセキュリティペイロード（ESP）輸送形式を使用して」、RFC 5202、2008年4月。
[RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206] Nikander、P.、Henderson、T.、Ed。、Vogt、C.、およびJ. Arkko、「ホストIDプロトコルを使用したエンドホストモビリティとマルチホミング」、RFC 5206、2008年4月。
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008.
[RFC5207] Stiemerling、M.、Quittek、J。、およびL. Eggert、「Nat and Firewall Traversal Issus of Host Identity Protocol（HIP）Communication」、RFC 5207、2008年4月。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Ed。、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008.
[RFC5225] Pelletier、G。およびK. Sandlund、「堅牢なヘッダー圧縮バージョン2（ROHCV2）：RTP、UDP、IP、ESP、UDP-Liteのプロファイル」、RFC 5225、2008年4月。
[RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across IPsec-Based VPN Gateways", RFC 5265, June 2008.
[RFC5265] Vaarala、S。およびE. Klovning、「IPSECベースのVPNゲートウェイ全体のモバイルIPv4トラバーサル」、RFC 5265、2008年6月。
[RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008.
[RFC5266] Devarapalli、V。およびP. Eronen、「モバイルIPv4およびIKEV2モビリティとマルチホミング（Mobike）を使用した安全な接続とモビリティ」、2008年6月、BCP 136、RFC 5266、RFC 5266。
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008.
[RFC5282] Black、D。およびD. McGrew、「Internet Key Exchangeバージョン2（IKEV2）プロトコルの暗号化されたペイロードを使用した認証された暗号化アルゴリズムを使用して」、RFC 5282、2008年8月。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380] Soliman、H.、Castelluccia、C.、Elmalki、K。、およびL. Bellier、「階層モバイルIPv6（HMIPV6）モビリティ管理」、RFC 5380、2008年10月。
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008.
[RFC5386]ウィリアムズ、N。およびM.リチャードソン、「より良いセキュリティ：IPSECの無認定モード」、RFC 5386、2008年11月。
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
[RFC5374] Weis、B.、Gross、G。、およびD. Ignjatic、「インターネットプロトコルのセキュリティアーキテクチャへのマルチキャスト拡張」、RFC 5374、2008年11月。
[RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)", RFC 5387, November 2008.
[RFC5387] Touch、J.、Black、D。、およびY. Wang、「より良いセキュリティ（BTNS）の問題と適用声明」、RFC 5387、2008年11月。
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, February 2009.
[RFC5406] Bellovin、S。、「IPSECバージョン2の使用を指定するためのガイドライン」、BCP 146、RFC 5406、2009年2月。
[RFC5529] Kato, A., Kanda, M., and S. Kanno, "Modes of Operation for Camellia for Use with IPsec", RFC 5529, April 2009.
[RFC5529] Kato、A.、Kanda、M。、およびS. Kanno、「IPSECで使用するCamelliaの動作モード」、RFC 5529、2009年4月。
[RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel Encapsulation Attribute", RFC 5566, June 2009.
[RFC5566] Berger、L.、White、R。、およびE. Rosen、「BGP IPSECトンネルカプセル化属性」、RFC 5566、2009年6月。
[RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[RFC5568] Koodli、R.、ed。、「Mobile IPv6 Fast Handovers」、RFC 5568、2009年7月。
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, July 2009.
[RFC5570] Stjohns、M.、Atkinson、R。、およびG. Thomas、「Common Architecture Label IPv6 Security Option（Calipso）」、RFC 5570、2009年7月。
[RFC5660] Williams, N., "IPsec Channels: Connection Latching", RFC 5660, October 2009.
[RFC5660]ウィリアムズ、N。、「IPSECチャネル：接続ラッチング」、RFC 5660、2009年10月。
[RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, November 2009.
[RFC5685] Devarapalli、V。およびK. Weniger、「インターネットキー交換プロトコルバージョン2（IKEV2）のリダイレクトメカニズム」、RFC 5685、2009年11月。
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
[RFC5723] Sheffer、Y。およびH. Tschofenig、「Internet Key Exchange Protocol 2（IKEV2）セッション再開」、RFC 5723、2010年1月。
[RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5739, February 2010.
[RFC5739] Eronen、P.、Laganier、J。、およびC. Madson、「インターネットキー交換プロトコルバージョン2（IKEV2）のIPv6構成」、RFC 5739、2010年2月。
[RFC5840] Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility", RFC 5840, April 2010.
[RFC5840] Grewal、K.、Montenegro、G。、およびM. Bhatia、「トラフィックの可視性のためのセキュリティペイロード（ESP）をラップした」、RFC 5840、2010年4月。
[RFC5856] Ertekin, E., Jasani, R., Christou, C., and C. Bormann, "Integration of Robust Header Compression over IPsec Security Associations", RFC 5856, May 2010.
[RFC5856] Ertekin、E.、Jasani、R.、Christou、C。、およびC. Bormann、「IPSECセキュリティ関連に対する堅牢なヘッダー圧縮の統合」、RFC 5856、2010年5月。
[RFC5857] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. Bormann, "IKEv2 Extensions to Support Robust Header Compression over IPsec", RFC 5857, May 2010.
[RFC5857] Ertekin、E.、Christou、C.、Jasani、R.、Kivinen、T。、およびC. Bormann、「IKEV2拡張はIPSEC上の堅牢なヘッダー圧縮をサポートする」、RFC 5857、2010年5月。
[RFC5858] Ertekin, E., Christou, C., and C. Bormann, "IPsec Extensions to Support Robust Header Compression over IPsec", RFC 5858, May 2010.
[RFC5858] Ertekin、E.、Christou、C。、およびC. Bormann、「IPSECの堅牢なヘッダー圧縮をサポートするIPSEC拡張」、RFC 5858、2010年5月。
[RFC5879] Kivinen, T. and D. McDonald, "Heuristics for Detecting ESP-NULL Packets", RFC 5879, May 2010.
[RFC5879] Kivinen、T。およびD. McDonald、「ESP-Nullパケットを検出するためのヒューリスティック」、RFC 5879、2010年5月。
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 2010.
[RFC5903] Fu、D。およびJ. Solinas、「Elliptic Curveグループは、IKEおよびIKEV2のプライム（ECPグループ）を測定します」、RFC 5903、2010年6月。
[RFC5930] Shen, S., Mao, Y., and NSS. Murthy, "Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol", RFC 5930, July 2010.
[RFC5930] Shen、S.、Mao、Y。、およびNSS。Murthy、「インターネットキーエクスチェンジバージョン02（IKEV2）プロトコルを使用した高度な暗号化標準カウンターモード（AES-CTR）の使用」、RFC 5930、2010年7月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン2（IKEV2）」、RFC 5996、2010年9月。
[RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension for EAP-Only Authentication in IKEv2", RFC 5998, September 2010.
[RFC5998] Eronen、P.、Tschofenig、H。、およびY. Sheffer、「IKEV2のEAPのみの認証の拡張」、RFC 5998、2010年9月。
[RFC6027] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, October 2010.
[RFC6027] NIR、Y。、「IPSECクラスター問題ステートメント」、RFC 6027、2010年10月。
Table 1: Algorithm Requirement Levels
表1：アルゴリズムの要件レベル
+--------------------------+----------------------------------------+
| ALGORITHM | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Encryption Algorithms: |
|--------------------- |
| ESP-NULL | N/A N/A MUST MUST |
| | |
| 3DES-CBC | MUST MUST- MUST MUST- |
| | |
| Blowfish/CAST/IDEA/RC5 | optional optional optional optional |
| | |
| AES-CBC 128-bit key | SHOULD SHOULD+ MUST MUST |
| | |
| AES-CBC 192/256-bit key | optional optional optional optional |
| | |
| AES-CTR | undefined optional SHOULD SHOULD |
| | |
| Camellia-CBC | optional optional optional optional |
| | |
| Camellia-CTR | undefined undefined undefined optional |
| | |
| SEED-CBC | undefined undefined optional undefined|
| | |
|Integrity-Protection Algorithms: |
|------------------------------ |
| HMAC-SHA-1 | MUST MUST MUST MUST |
| | |
| AES-XCBC-MAC | undefined optional SHOULD+ SHOULD+ |
| | |
| HMAC-SHA-256/384/512 | optional optional optional optional |
| | |
| AES-GMAC | N/A N/A undefined optional |
| | |
| HMAC-MD5 | MAY optional MAY MAY |
| | |
| AES-CMAC | undefined optional undefined optional |
| | |
| HMAC-RIPEMD | undefined undefined optional undefined|
+--------------------------+----------------------------------------+
Table 1: Algorithm Requirement Levels (continued)
表1：アルゴリズムの要件レベル（続き）
+--------------------------+----------------------------------------+
| ALGORITHM | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Combined Mode Algorithms: |
|------------------------ |
| AES-CCM | N/A optional N/A optional |
| | |
| AES-GCM | N/A optional N/A optional |
| | |
| AES-GMAC | N/A N/A undefined optional |
| | |
| Camellia-CCM | N/A undefined N/A optional |
| | |
|Pseudorandom Functions: |
|----------------------- |
| PRF-HMAC-SHA1 | MUST MUST |
| | |
| PRF-HMAC-SHA-256/384/512 | optional optional |
| | |
| AES-XCBC-PRF | undefined SHOULD+ |
| | |
| AES-CMAC-PRF | undefined optional |
| | |
|Diffie-Hellman Algorithms: |
|------------------------- |
| DH MODP grp 1 | MAY optional |
| | |
| DH MODP grp 2 | MUST MUST- |
| | |
| DH MODP grp 5 | optional optional |
| | |
| DH MODP grp 14 | SHOULD SHOULD+ |
| | |
| DH MODP grp 15-18 | optional optional |
| | |
| DH MODP grp 22-24 | optional optional |
| | |
| DH EC grp 3-4 | MAY undefined |
| | |
| DH EC grp 19-21 | optional optional |
| | |
| DH EC grp 25-26 | optional optional |
+--------------------------+----------------------------------------+
Authors' Addresses
著者のアドレス
Sheila Frankel NIST Bldg. 223 Rm. B366 Gaithersburg, MD 20899
シーラ・フランケル・ニスト・ビルド。223 RM。B366 Gaithersburg、MD 20899
Phone: 1-301-975-3297 EMail: sheila.frankel@nist.gov
電話：1-301-975-3297メール：sheila.frankel@nist.gov
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
Suresh Krishnan Ericsson 8400 Decarie Blvd.QCカナダのマウントロイヤルの町
Phone: 1-514-345-7900 x42871 EMail: suresh.krishnan@ericsson.com
電話：1-514-345-7900 x42871メール：suresh.krishnan@ericsson.com