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）やInternet Key Exchange（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とIKE（Internet Key Exchange）を使用したRFCの数が大幅に増殖しています。元のIPsec WG、その様々なスピンオフ、およびそのプロトコルのトラフィックを保護するためのIPsecおよび/またはIKEを使用する他のWG：これは、これらのRFCは、多くのIETFワーキンググループから生じているという事実によって複雑になります。
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のスナップショットです。これは、IPsecの増生と拡張の動機や状況を説明する背景情報とともに、各RFCの簡単な説明を含んでいます。これは、RFC 2411、前回の廃止「IPセキュリティ文書のロードマップ。」
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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（インターネット鍵交換）が最も一般的に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
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で使用するために、各暗号アルゴリズムの要件レベルを分類しています。これらの要件は、これらのレベルは、2011年2月現在のものです付録Aに要約されています。以降のRFCsは、変更された要求レベルをもたらすことができます。
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のRFCに見られるものを修正再表示します。この文書およびその他の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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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つのグループに分割されています。これは、広く一般的な概念、セキュリティ要件、定義、およびIPsec技術を定義するメカニズムをカバーしてメインアーキテクチャ文書であり、図1に示されています。
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-V3と呼ばれる、RFCの説明については、3.1.1項を参照してください）「新しい」IPsecは、この文書でのIPsec-V2と呼ばれる「古い」IPsecを（廃止;については、セクション3.1.2を参照してくださいRFCの説明）。しかし、IPsecの-v2は、まだ一般的に操作上の使用中に発見されました。修飾されていない用語のIPsecを使用する場合、この文書では、それは、IPsecの両方のバージョンに関連します。 IPsecの-V2によって廃止されたIPsec（のRFC 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
IPsec処理のより詳細な説明、Oユニキャストとマルチキャストの両方、および様々な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.
IPsecの-V2中のO、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
セレクタとしての値とICMPメッセージタイプの範囲を含むOより柔軟SPD（セキュリティポリシーデータベース）セレクタ、
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
AH O [RFC4302]はIPsecの-V2、オプション（MAY）のIPsec-V3中に（必要がある）を実装するために必須です
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認証、必須（MUST）ESP-V2で、ESP-V3に（MAY）オプションであります
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つのバージョンが、現在の実装で見つけることができます。 （一般のIKEv2と呼ばれる）、「新しい」IKEは、（一般のIKEv1と呼ばれる）、「古い」IKEを廃止しました。しかし、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ネゴシエーションが正常に完了すると、ピアは、一方向（インバウンドおよびアウトバウンド）SAの2組を確立しました。 IKEは、常にSAのペアをネゴシエートするので、用語「SA」は、一般SAのペアを指すために使用される（例えば、「IKE SA」または「のIPsec SAは、」現実に一方向SAのペアです）。最初のSA、IKE SAは、IKEトラフィックを保護するために使用されます。第二のSAは、ピアがネゴシエートすることが許可されるピア及び/又は他のデバイスとの間のデータトラフィックにIPsec保護を提供します。これは、IKEv2のRFCで、それがCHILD_SA、子供SA、およびIPsec SAように様々に呼ばれている、のIKEv1の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 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)
EAPベースの認証方法及び非対称認証（即ち、イニシエータとレスポンダは、異なる認証方法を使用することができる）のOサポート
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.
[RFC2407]で定義されIKEv1のフェーズ2つの交換時に使用される値は、[RFC2408：OインターネットSecurity AssociationとKey Managementプロトコル（ISAKMP）（http://www.iana.org/assignments/isakmp-registry）のための "ザ・マジック・ナンバーズ" ]、および多数の他の暗号アルゴリズムのRFC。
o IKEv2 Parameters (http://www.iana.org/assignments/ikev2-parameters): values used in IKEv2 exchanges, defined in [RFC5996] and numerous other cryptographic algorithm RFCs.
IKEv2のパラメータ（http://www.iana.org/assignments/ikev2-parameters）O：[RFC5996]で定義のIKEv2交換に使用される値、及び多数の他の暗号アルゴリズムのRFC。
o Cryptographic Suites for IKEv1, IKEv2, and IPsec (http://www.iana.org/assignments/crypto-suites): names of cryptographic suites in [RFC4308] and [RFC4869].
[RFC4308]での暗号スイートの名前と[RFC4869]：暗号のIKEv1、IKEv2の、およびIPsecのためのスイート（http://www.iana.org/assignments/crypto-suites）O。
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.
カプセル化セキュリティペイロード（ESP）ヘッダーと認証ヘッダー（AH）：IPsecの保護機能は、二つの特別なヘッダによって提供されています。 IPv4では、これらのヘッダーは、プロトコルヘッダの形をとります。 IPv6では、彼らは拡張ヘッダとして分類されています。 IPセキュリティアーキテクチャについて説明1、およびIPsecヘッダのそれぞれについて、1：3つのベースのIPsec文書があります。
3.1.1.1. , Security Architecture for the Internet Protocol (S, November 1998)
3.1.1.1。インターネットプロトコルのために、セキュリティアーキテクチャ（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（セキュリティアソシエーションデータベース）：各ピアのSAリポジトリ。 RFCは、どのようにこのデータベース機能（SAルックアップ、等）、それはSAの処理を容易にするために含まなければならない情報のタイプを記述する。それは、データベースのフォーマットやレイアウトを規定していません。 SAは、トランスポートモードまたはトンネルモード（下記参照）のいずれかで確立することができます。
- 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がto-ゲートウェイゲートウェイまたはホスト・ツー・ゲートウェイトラフィックを保護するために使用することができます。それは、必要に応じてホスト間のトラフィックに使用することができます。 AH SAのこのクラスは、内側（オリジナル）ヘッダと上位層データ、ならびにパケット配信時に予測できない変化しない外側の（トンネル）ヘッダの部分を保護します。 IPヘッダの部分はAHの計算には含まれていないため、AH処理は、ESP処理よりも複雑です。 AHはまた、ネットワークアドレス変換（NAT）の存在下では動作しません。 IPsecの-V3とは異なり、IPsecの-V2分類AH実装するために必須として。
3.1.1.3. , IP Encapsulating Security Payload (ESP) (S, November 1998)
3.1.1.3。 、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]は機密性を提供し、IPカプセル化セキュリティペイロード（ESP）、（暗号化）および/または完全性保護を定義します。それはまた、データ起点認証、アクセス制御、および、必要に応じて、再生および/またはトラフィック解析からの保護を提供します。トランスポートモードESP SAは、上位層データではなく、IPヘッダーを保護します。トンネルモードESP SAは、上位レイヤデータと内部ヘッダではなく、外部ヘッダを保護します。
3.1.2.1. , Security Architecture for the Internet Protocol (S, December 2005)
3.1.2.1。インターネットプロトコルのために、セキュリティアーキテクチャ（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]は[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. , IP Encapsulating Security Payload (ESP) (S, December 2005)
3.1.2.3。 、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.
NATトラバーサルの交渉、拡張シーケンス番号、ESPパケットのUDPカプセル化、日和見暗号化、およびIPsec関連のICMPメッセージ：IKEv1のとIPsec-V2のRFCが確定された後は、いくつかの追加は別の文書で定義されていました。 IPsecトランスポートモードのさらなる使用もまた記載された：IP-で-IPトンネルの手動で設定したIPv6インのIPv4トンネルの保護と保護を。これらの文書は、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）を区別するためのミドルボックスの機能です。二つの解決策が記載されていますのIKEv2およびIPsec-v3および新たな要件を課していない発見的方法への変更を必要とする新しいプロトコルを。取り組まれたもう一つの問題は、高可用性環境でIKEとIPsecを使用しての問題です。
3.2.1. , Negotiation of NAT-Traversal in the IKE (S, January 2005)
3.2.1. 、IKEでのNATトラバーサル（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のにオプションの拡張を定義します。それは交渉ピア間との両方のピアがNATトラバーサルをサポートするかどうかの任意のNATがあるかどうかを検出するのIKEv1を可能にします。また、IKEv1のは、IPsecのSAのESPパケットのUDPカプセル化の使用を交渉するために使用する方法について説明します。 IKEv2のため、この機能は、[RFC5996]に記載されています。
3.2.2. , UDP Encapsulation of IPsec ESP Packets (S, January 2005)
3.2.2. 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またはTCP以外のプロトコルのパケットを破棄するのNATトラバーサルを有効にするには、UDPパケットにおけるESPパケットをカプセル化する方法を定義します。これにより、ESPパケットがNATデバイス自体への変更を必要とせずにNATデバイスを通過できるようになります。 IKEv2のためのIKEv1と[RFC5996]のために[RFC3947]に記載されているように、この溶液の使用は、IKEによって交渉されます。
3.2.3. , 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. インターネットSecurity AssociationとKey Managementプロトコル（ISAKMP）（S、2005年12月）のための解釈のIPsecのドメイン（DOI）に、拡張シーケンス番号（ESN）補遺
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]はIPSec SAのためのESNの使用を交渉するのIKEv1を可能にするのIKEv1にオプションの拡張を記述しています。 IKEv2のため、この機能は、[RFC5996]に記載されています。
3.2.4. , Opportunistic Encryption using the Internet Key Exchange (IKE) (I, December 2005)
3.2.4. インターネット鍵交換（IKE）（I、2005年12月）を使用して、日和見暗号化
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. , Using IPsec to Secure IPv6-in-IPv4 Tunnels (I, May 2007)
3.2.5. 、IPv6のインIPv4トンネル（I、2007年5月）を確保するためにIPsecを使用して
[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]は、手動のIPv6における-IPv4トンネルを構成するためにセキュリティ保護を提供するために、IKEとトランスポートモードのIPsecを使用する方法について説明します。このドキュメントは、新しい拡張機能せず、標準IKEとIPsecを使用しています。これは、自動化された方法で開始されるトンネルには適用されない（例えば、6to4トンネル[RFC3056]）。
3.2.6. , Use of IPsec Transport Mode for Dynamic Routing (I, September 2004)
3.2.6. 動的ルーティング（I、2004年9月）のIPsecトランスポートモードの、使用
[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インIPトンネルを確保するため、トランスポート・モードのIPsecの使用を記載しています。これは、トラフィックが動的ではなく静的にルーティングされたIPsecトンネルを介してすべてのトラフィックをルーティングするよりも、VNの信頼されたルータを介してルーティングすることができます。このRFCは、広く採用されていません。
3.2.7. , Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility (S, April 2010)
3.2.7. トラフィックの可視性のために、包まれたカプセル化セキュリティペイロード（ESP）（S、2010年4月）
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を拡張し、IPsecピア間のこの能力を交渉するためのIKEv2を拡張します。
3.2.8. , Heuristics for Detecting ESP-NULL packets (I, May 2010)
3.2.8. 、ヒューリスティック検出するための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-NULLパケットを区別するための別のアプローチを提供しています。この方法では、IKEやESPに変更を必要としません。それはESP-v2またはESP-V3で使用することができます。
3.3.1. , IPsec-Network Address Translation (NAT) Compatibility Requirements (I, March 2004)
3.3.1. 、IPsecでネットワークアドレス変換（NAT）の互換性の要件（I、2004年3月）
[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. , Guidelines for Specifying the Use of IPsec Version 2 (B, February 2009)
3.3.2. 、ガイドライン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のための共通の故障モードを処理するためのいくつかのコードを定義します。このメッセージによって合図されている不具合は、などのデータグラム、暗号解読および解凍時のエラー、上の信憑性や整合性チェックの失敗を無効または期限切れのSPIが含まれるこれらのメッセージは、自動化されたセッション・キー管理をトリガするか、オペレータに必要性を知らせるために使用することができます手動でSAを再設定します。この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のための好適な鍵管理プロトコルです。これは、ピア認証に使用されます。 SAを、交渉、変更、および削除します。そしてそれらのSA内で使用するために認証済みの鍵材料を交渉します。 IKEv1ので使用される標準的なピアの認証方法は、（事前共有秘密鍵とデジタル証明書）企業のVPNへのリモートユーザ認証を有効にするためのIKEv1の使用に関連するいくつかの欠点を持っていた：それは、従来の認証システムの使用を活用することができませんでした（たとえば、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.
いくつかのインターネットドラフトは、これらの問題に対処するために書かれていた2つのそのような文書は、[IKE-XAUTH]「IKE（XAUTH）内の拡張認証」が含まれる（およびその前身、「ISAKMP /オークリー（XAUTH）内の拡張認証」を[ISAKMP-XAUTH]）そして "ISAKMP設定方法" [IKE-MODE-CFG（及びその前身[ISAKMP-MODE-CFG]）。これらのインターネットドラフトは、これらのソリューションに関連するセキュリティ上の欠陥やその他の問題にRFC状態に進行しませんでした。しかし、現在の多くのIKEv1の実装では、企業のVPNへのリモートユーザーアクセスを容易にするために、これらのソリューションの態様を組み込みます。これらのソリューションは、標準化されていないし、異なる実装が異なるバージョンを実装しました。従って、実装が提案ソリューションに完全に付着したり、1つの実装では、同じ機能を組み込むために請求他人と相互運用することができるという保証はありません。さらに、これらのソリューションは、セキュリティ上の問題を知られています。これらの問題やセキュリティ問題のすべてが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で使用するための、そのようなIETFのIPsec DOIのためのAHとESPのような他のセキュリティアソシエーションに対して認証鍵材料を得るためにISAKMPと一緒にオークリープロトコルのサブセットを実装します。 、歴史的に、IKEv1のは実際には、2つのセキュリティプロトコル、ISAKMPとオークリーを組み合わせることによって作成されたが、（IPsecのDOIと共に）の組み合わせは、一般に、プロトコル、IKEv1のように見てきました。プロトコルの起源は、それを定義する文書の組織内で見ることができます。
4.1.1.2. , Internet Security Association and Key Management Protocol (ISAKMP) (S, November 1998)
4.1.1.2。 、インターネットSecurity AssociationとKey Managementプロトコル（ISAKMP）（S、1998年11月）
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.
この文書では、セキュリティアソシエーション（SA）を確立交渉、変更、および削除するための手順およびパケットフォーマットを定義します。ネットワークスタックのすべての層でセキュリティプロトコルのためのSAのネゴシエーションをサポートすることを意図しています。 ISAKMPは、多くの異なる鍵交換プロトコル、異なるセキュリティ特性を持つそれぞれに作業することができます。
4.1.1.3. , The Internet IP Security Domain of Interpretation for ISAKMP (S, November 1998)
4.1.1.3。 ISAKMPのための解釈のインターネットIPセキュリティドメイン（S、1998年11月）
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. , The OAKLEY Key Determination Protocol (I, November 1998)
4.1.1.4。 、OAKLEYキー決意プロトコル（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人の認証済みの当事者が安全と秘密鍵情報に同意するために使用できる鍵確立プロトコルを記述します。 「モード」と呼ばれる - - オークリープロトコルは、鍵交換のシリーズを説明し、それぞれ（例えば、完全転送キーの秘密、ID保護、および認証）が提供するサービスの詳細を示します。この文書では、設計上の決定とIKEとISAKMPのセキュリティ機能の一部を説明するために追加的な理論や背景を提供します。それはIKEv1の実施のために必要な詳細情報が含まれていません。
4.1.2.1. , Internet Key Exchange (IKEv2) Protocol (S, December 2005)
4.1.2.1。インターネットキー交換（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. , IKEv2 Clarifications and Implementation Guidelines (I, October 2006)
4.1.2.2。 、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. , Internet Key Exchange Protocol Version 2 (IKEv2) (S, September 2010)
4.1.2.3。 、インターネット鍵交換プロトコルバージョン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]は明確化RFC [RFC4718]で元のIKEv2 RFC [RFC4306]を組み合わせ、およびこれら二つの文書の出版以来、コミュニティによって発見され、多くの実装上の問題を解決します。この文書は、元のIPsecワーキンググループの締結後、IPsecME（IPsecのメンテナンスおよび拡張機能）ワーキンググループによって開発されました。自動キー分布は、IPsecの-V3のために必要とされますが、IKEの代替は、その要件を満たすために使用することができます。
4.2.1.1. , Repeated Authentication in Internet Key Exchange (IKEv2) Protocol (E, April 2006)
4.2.1.1。インターネット鍵交換では、繰り返し認証（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応答者）は、権限のないユーザーがリモートホストに物理的にアクセスを獲得した場合の被害を制限する、定期的に再認証をリモートユーザ（IKEイニシエータ）を強制することができますか？この文書では、応答側はIPsecのSAは、指定された期間内にイニシエータ再認証しない限り、取り消されることをイニシエータに通知し、イニシエータに送ることができるという、新しいステータス通知を定義します。このオプションの拡張は、唯一のIKEv2に、ではないのIKEv1に適用されます。
4.2.1.2. , Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol (E, November 2006)
4.2.1.2。インターネットキーエクスチェンジ（IKEv2の）プロトコル（E、2006年11月）で、複数の認証交換
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のは、当事者を認証するためのいくつかのメカニズムをサポートしていますが、各エンドポイントは自身を認証するために一つだけこれらのメカニズムのを使用しています。 [RFC4739]は異なる機構または同様のメカニズムのいずれかを使用して、複数の認証交換の使用を可能にするのIKEv2の拡張を指定します。この拡張は、ユーザのEAP認証に続いて、クライアントホストの証明書ベースの認証を行う、例えば、可能にします。必要な場合、これはまた、複数の管理ドメインでの認証が可能になります。このオプションの拡張は、唯一のIKEv2に、ではないのIKEv1に適用されます。
4.2.1.3. , IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) (S, January 2007)
4.2.1.3。 、IKEおよびIKEv2の認証は、楕円曲線デジタル署名アルゴリズム（ECDSA）（S、2007年1月）を使用して、
[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]は楕円曲線デジタル署名アルゴリズム（ECDSA）はIKEv1のとIKEv2のプロトコル内の認証方法として使用することができる方法。説明しますECDSAは、RSAやDSAなどの他の利用可能なデジタル署名方式に比べて計算効率、小さな署名サイズ、および最小帯域幅を含む多くの利点を提供します。このオプションの拡張はIKEv1のとIKEv2の両方に適用されます。
4.2.1.4. , An Extension for EAP-Only Authentication in IKEv2 (S, September 2010)
4.2.1.4。 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のイニシエータがピア認証のためにEAPを使用することができますが、デジタル署名を使用することによって認証する応答を必要とします。相互認証および鍵合意を提供するEAPメソッドはまた、応答のピア認証を提供するために使用することができるように、[RFC5998]はのIKEv2を拡張します。このオプションの拡張は、唯一のIKEv2に、ではないの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.
形式、内容、および公開鍵証明書（PKCS）の解釈は、IKEおよびIPsec内での相互運用性の問題の原因であることが判明しました。 PKI4IPsecは、これらの問題を軽減するための場所でいくつかの一般的な手順や解釈を設定するための試みでした。
4.2.2.1. , Requirements for an IPsec Certificate Management Profile (I, February 2007)
4.2.2.1。 IPsecの証明書管理のプロフィール、要件（I、2007年2月）
[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の両方に適用されます。
4.2.2.2. , The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX (S, August 2007)
4.2.2.2。 IKEv1の/ ISAKMP、IKEv2の、およびPKIX（S、2007年8月）の、インターネットIPセキュリティPKIプロフィール
[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の両方に適用されます。
4.2.2.3. , Online Certificate Status Protocol (OCSP) Extensions to IKEv2 (S, February 2007)
4.2.2.3。 、IKEv2の（S、2007年2月）にオンライン証明書状態プロトコル（OCSP）の拡張機能
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は、そのようなメカニズムです。 [RFC4806]はIKEv2のに "OCSPコンテンツ" の拡張子を定義します。この文書では、OCSPは、所望のセキュリティポリシー（例えば、ファイアウォールポリシー）されたときに適用可能で直接関連OCSPレスポンダへのアクセスのIKEv2ピアの1つを防止します。このオプションの拡張は、唯一のIKEv2に、ではないのIKEv1に適用されます。
4.2.3.1. , A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers (I, February 2004)
4.2.3.1。検出デッドインターネット鍵交換（IKE）ピア（I、2004年2月）の、トラフィックベースの方法
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".
2つのピアがIKEとIPsecを使用して通信するときに、2つのピア間の接続が予期せずにドロップすることが可能です。彼らの寿命が期限切れになるまでしかし、SAは、まだ「ブラックホール」にトンネリングされたばかりのパケットが得られ、残ることができます。 [RFC3706]は一定の間隔でメッセージを送信することなく、ピア活気を検出するためのアプローチを記載します。このRFCはIKEv1のにオプションの拡張を定義します。デッド・ピア検出（DPD）は、「ライブネス・チェック」または「生存性試験」として、この機能を指すのIKEv2の不可欠な部分です。
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のサポートに必要ないくつかの不足しているコンポーネントを特定しました。これらは、IPsec構成ペイロードを使用してIPv6クライアント構成のためのVPNゲートウェイと以前に確立されたセッションの効率的なクライアントの再開、代替VPNゲートウェイへの効率的なクライアント・リダイレクション、およびサポートを含みます。
4.2.4.1. , IKEv2 Mobility and Multihoming Protocol (MOBIKE) (S, June 2006)
4.2.4.1。 、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のは、IKE SAは、IKEv2のSAを確立する際のプロトコルの実行中に使用されるIPアドレスのペアの間で暗黙的に作成されていることを前提としています。 IPSec関連の文書はIKE SAが作成された後、このペアを変更する規定がなかったです。 [RFC4555]は、ホストが経時複数のIPアドレスおよび/またはIPsecのホスト変更のIPアドレスを有する場合IKEとIPsecセキュリティアソシエーションの効率的な管理を可能にするのIKEv2の拡張を定義します。
4.2.4.2. , Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol (I, August 2006)
4.2.4.2。 、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プロトコル、背景情報については、設計上の決定を記録し、ワーキンググループ内での議論を記録します。
4.2.4.3. , Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) (B, June 2008)
4.2.4.3。モバイルIPv4及びIKEv2のモビリティ及びマルチホーミング（MOBIKE）（B 2008年6月）を使用して、セキュアな接続とモビリティ
[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]は、彼らが信頼できないネットワークにローミングするときに、エンタープライズ・ユーザーにセキュアな接続及び移動性を提供するためのIKEv2（MOBIKE）にモバイルIPv4（MIPv4の）とモビリティ拡張を使用して溶液を記載しています。
4.2.4.4. , Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption (S, January 2010)
4.2.4.4。 、インターネット鍵交換プロトコルバージョン2（IKEv2の）セッション再開（S、2010年1月）
[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ネゴシエーションを繰り返すことなく、迅速な方法で、ゲートウェイとSAを再確立するためにゲートウェイから切断されたリモート・クライアントを可能にします。この機能は、IKEv2のを変更する必要があります。このオプションの拡張は、唯一のIKEv2に、ではないのIKEv1に適用されます。
4.2.4.5. , Re-direct Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) (S, November 2009)
4.2.4.5。インターネット鍵交換プロトコルバージョン2（IKEv2の）（S、2009年11月）のために、再直接のメカニズム
[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のを変更する必要があります。このオプションの拡張は、唯一のIKEv2に、ではないのIKEv1に適用されます。
4.2.4.6. , IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) (E, February 2010)
4.2.4.6。インターネット鍵交換プロトコルバージョン2（IKEv2の）（E、2010年2月）で、IPv6設定
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]は、この制限を削除する可能性があるいくつかのソリューションを提案しています。このオプションの拡張は、唯一のIKEv2に、ではないの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の内で使用するアルゴリズムのために満たされている必要がありますなど一つ以上のIANA値の割り当てと関連するプロトコル内のアルゴリズムを使用する方法について説明RFC、パケットフォーマット、特別な考慮事項については、暗号アルゴリズムを記述する各RFCは、このロードマップはいずれかなければならないべきであり、またはMAY [RFC2119]として、各プロトコルのために、その要求レベルを分類します。 SHOULD +、SHOULD-、又はMUST- [RFC4835]。オプション;未定義;またはN / A（適用しません）。 「任意」の指定は、アルゴリズムは、2つの基本的な要件を満たしているが、その用途は特にそのプロトコルのために推奨されていないことを意味します。 「未定義は、」基本的な要件のいずれかが満たされていないことを意味します。どちらかのアルゴリズムには、関連するIANA番号が存在しないか、それはその特定のプロトコル内で使用される方法を指定する一切RFCはありません。 「N / A」は、アルゴリズムの使用は、文脈に不適切であることを意味する（例えば、常に暗号化を必要とするIKE用NULL暗号化、または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のトラフィック（暗号化および整合性保護アルゴリズム）を保護するために、または材料（ディフィー・ヘルマンまたはDHグループ、擬似ランダム関数またはのPRF）をキーイングを生成するためにも使用されます。このアルゴリズムは、IPsecの内で使用するために推奨されている場合は、IPsecの/子SAのトラフィックを保護するために使用し、IKEはその目的のために、その使用を交渉することが可能です。これらの要件は、表1（付録A）に要約されています。これらのレベルは、2011年2月現在のものです。以降のRFCsは、変更された要求レベルをもたらすことができます。アルゴリズムについては、これは新しいアルゴリズムまたはアップグレードまたは現在のアルゴリズムの要求レベルをダウングレードの導入を意味するかもしれません。
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のSAをネゴシエートするために、これらの値を使用しています。特定のアルゴリズムが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のそれぞれは、その実装に必須の（MUST）、推奨（SHOULD）、（MAY）オプション、および（ならない）非推奨のアルゴリズムを指定するRFCを持っています。 IPsecでv2のは、これはベースプロトコルRFCに含まれています。それは、もともとIKEv1のためのケースだったが、IKEv1のアルゴリズムの要件は[RFC4109]に更新されました。
5.1.1. , Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (S, April 2007)
5.1.1. カプセル化セキュリティペイロード（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にも適用されます。複合モードのアルゴリズムは言及しますが、要求レベルが割り当てられていません。
5.1.2. , Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) (S, December 2005)
5.1.2. インターネット鍵交換バージョン2（IKEv2の）（S、2005年12月）での使用のために、暗号アルゴリズム
[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
[RFC4307]は、自身のトラフィックを保護するためのIKEv2によって使用される暗号化および整合性保護アルゴリズム、IKEv2の内で使用されるDiffie-Hellman（DH）グループ、およびキー、ナンス、およびその他のランダムな値を生成するためのIKEv2によって使用される擬似ランダム関数を指定します。 [RFC4307]はIKEv2の暗号化と完全性保護アルゴリズムの相反する要件が含まれています。相反する要求がある場合には、この文書では、セクションからの要求レベルを取ります
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".
むしろ、セクション3.1.3から3.1.1より、「暗号化ペイロードアルゴリズム」、「IKEv2のタイプ2変換アルゴリズム」、またはセクション3.1.4「IKEv2の1型変換アルゴリズム」。
5.1.3. , Algorithms for Internet Key Exchange version 1 (IKEv1) (S, May 2005)
5.1.3. インターネットキー交換バージョン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で使用される暗号化と完全性保護アルゴリズムを指定します。ディフィー・ヘルマン（DH）のIKEv1内で使用される基;キー、ノンス及び他のランダム値を生成するための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.
暗号アルゴリズムのRFCは、トラフィックに機密性保護を提供し、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].
DESは、[RFC2405]に記載されているように、本来のIKEv1およびESP-V2に必要なアルゴリズムでした。 DESの使用が廃止されているので、このロードマップは、[RFC2405]を含んでいません。
5.2.1. , The NULL Encryption Algorithm and Its Use With IPsec (S, November 1998)
5.2.1. 、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]は（すなわち、暗号化なしで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のためのMAYとしてESP-NULLを分類します。これは、RFC 4307の正誤表の提出で修正されました。
[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）モードで暗号化アルゴリズムを使用する方法について説明します。それは、具体的フグ、CAST-128、トリプル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]
IKEv1の - MUST [RFC4109]のIKEv2 - ESP-V2 MUST- [RFC4307] - MUST [RFC4835] ESP-V3 - MUST- [RFC4835]
Requirement levels for other CBC algorithms (Blowfish, CAST, IDEA, RC5):
他のCBCアルゴリズムのための要件レベル（ふぐ、CAST、IDEA、RC5）：
IKEv1 - optional IKEv2 - optional ESP-v2 - optional ESP-v3 - optional
IKEv1の - オプションのIKEv2 - オプションのESP-V2 - オプションのESP-V3 - オプション
5.2.3. , The AES-CBC Cipher Algorithm and Its Use with IPsec (S, September. 2003)
5.2.3. 、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ビットのキーが必須です。他のサイズはMAYです。 [RFC3602]はIKEv1のとESP-V2で使用するためのIANA値を含みます。単一IANA値はAES-CBCのために定義されているので、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]
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. , Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP) (S, January 2004)
5.2.4. 、高度暗号化標準のIPsecカプセル化セキュリティペイロード（ESP）（S、2004年1月）と（AES）カウンタモードを使用します
[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バイトのキーはMAYです。同じ鍵とナンスとIVの再利用は、データのセキュリティを危険にさらします。このように、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]
IKEv1の - オプション[RFC5930] ESP-V2 - - （NO IANA位）のIKEv2未定義SHOULD [RFC4835] ESP-V3は - [RFC4835] SHOULD
5.2.5. , Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol (I, July 210).
5.2.5. インターネットキー交換バージョン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]はIKEv2のメッセージの暗号化および完全性保護を提供するために、AES-CTRの使用を可能にするために、[RFC3686]を拡張します。
5.2.6. , The Camellia Cipher Algorithm and Its Use with IPsec (S, December 2005)
5.2.6. 、椿暗号アルゴリズムと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
[RFC4312]は、IKEおよびESPトラフィックを暗号化する暗号ブロック連鎖（CBC）モードでカメリアを使用する方法について説明します。椿-CBCは、128ビットのブロックサイズ、暗号化されたデータと共にパケットで送信されるランダムIV、及び128のキーサイズ192とブロック・モード暗号化であり、そして
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.
256ビット。ツバキ-CBCが実装されている場合、128ビットのキーが必須です。他のサイズはMAYです。 [RFC4312]はIKEv1のおよびIPsec-V2で使用するためのIANA値を含みます。単一IANA値は椿-CBCのために定義されているので、IKEv1の交渉は、キーサイズを指定する必要があります。
5.2.7. , Modes of Operation for Camellia for Use with IPsec (S, April 2009)
5.2.7. IPsecの（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]はいくつかの動作の異なるモードに連動してツバキブロック暗号化アルゴリズムの使用を記載しています。これは、ESP内の暗号化アルゴリズムとして暗号ブロック連鎖（CBC）モード及びカウンタ（CTR）モードでの椿の使用を記載しています。また、ESPで結合モードアルゴリズムとしてCBC-MAC（CCM）モードとカウンタのツバキの使用を記載しています。この文書では、椿ESP SAのための材料をキーイング生成するのIKEv2を使用する方法を定義します。それは、IKEv2のSAのトラフィックを保護するためのIKEv2内椿を使用する方法を定義していません。しかし、このRFCは、ブロック・モードの暗号化のIKEv2の一般的な説明と併せて、IKEv2の内の椿-CBCアルゴリズムの使用を許可するのに十分な詳細を提供します。すべての3つのモードは、長さ128ビット、192ビット、または256ビットのキーを使用することができます。 [RFC5529]はのIKEv2およびIPsec-V3で使用するためのIANA値を含みます。 IKEv2の交渉は、キーサイズを指定する必要があるので、単一のIANA値は、各カメリアモード用に定義されています。
Requirement levels for Camellia-CBC:
椿-CBCのための要件レベル：
IKEv1 - optional IKEv2 - optional ESP-v2 - optional ESP-v3 - optional
IKEv1の - オプションのIKEv2 - オプションのESP-V2 - オプションのESP-V3 - オプション
Requirement levels for Camellia-CTR:
椿-CTRのための要件レベル：
IKEv1 - undefined (no IANA #) IKEv2 - undefined (no RFC) ESP-v2 - optional (but no IANA #, so cannot be negotiated by IKE) ESP-v3 - optional
IKEv1の - 未定義（NO IANA位）のIKEv2 - 未定義（NO RFC）ESP-V2 - オプション（ただしIANA位ので、IKEによって交渉することができない）ESP-V3 - オプション
Requirement levels for Camellia-CCM:
椿-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. , The SEED Cipher Algorithm and Its Use with IPsec (S, October 2005)
5.2.8. 、SEED暗号アルゴリズムと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）モードでSEEDを使用する方法について説明します。これは、SEED-ESP SAを交渉するのIKEv1を使用する方法について説明しますが、IKEv1のトラフィックを保護するためにSEEDの使用を定義していません。 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)
IKEv1の - 未定義（NO IANA位）のIKEv2 - 未定義（無IANA番号なし）ESP-V2 - オプションESP-V3 - オプション（ただしIANA位ので、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.
これらのアルゴリズムのいくつかは、それがIPsecで保護されたパケットに含まれている場合に切り捨てられ、固定長ICVを生成します。例えば、標準HMAC-SHA-1（ハッシュメッセージ認証コード）は、ESPまたはAHパケットに対して完全性保護を提供するために使用されたときに96ビットに切り捨てられる160ビットのICVを生成します。個々のRFCの説明は切り捨てられ、これらのアルゴリズムを言及します。これらのアルゴリズムは、IKEv2のSAを保護するために使用されている場合は、それらも切り捨てられます。 IKEv1のために、HMAC-SHA-1、HMAC-MD5は、それぞれ、SHA-1およびMD5ハッシュアルゴリズムを要求することによって交渉されます。 IKEv1のSAを保護するために使用する場合、これらのアルゴリズムは切り捨てられません。 HMAC-SHA-1、HMAC-MD5は、IKEv2のIANAレジストリは切断バージョンと標準的な非切断型バージョンの両方の値が含まれています。したがって、IKEv2のは、アルゴリズムのいずれかのバージョンを交渉する能力を持っています。しかし、唯一の切断バージョンは、IKEv2のSAのとIPsec SAのために使用されます。非切断型は、ファイバチャネルプロトコル[RFC4595]での使用のために予約されています。他のアルゴリズム（AES-XCBC、HMAC-SHA-256/512分の384、AES-CMAC、およびHMAC-RIPEMD）のために、唯一の切断型バージョンは、のIKEv2およびIPsec-V3 SAの両方のために使用することができます。
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".
もう一つのアルゴリズム、AES-GMAC [RFC4543]は、また、完全性保護を提供することができます。 AH-V3内で使用するための完全性保護アルゴリズム、およびESP-V3内での使用のためのヌル暗号化を組み合わせたモードアルゴリズム：それは2つのバージョンがあります。 [RFC4543]は5.4、「複合モードアルゴリズム」に記載されています。
5.3.1. , The Use of HMAC-SHA-1-96 within ESP and AH (S, November 1998)
5.3.1. 、HMAC-SHA-1-96 ESPおよびAH内での使用（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]はHMAC-SHA-1、512ビットのブロックサイズと完全性保護アルゴリズムを記述し、160ビットのキーと完全性値（ICV）を確認してください。 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]
IKEv1の - MUST [RFC4307]のIPsec-V2 - - MUST [RFC4835]のIPsec-V3 - [RFC4109]のIKEv2 MUST [RFC4835] MUST
5.3.2. , The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec (S, September 2003)
5.3.2. 、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]はAES-XCBC-MAC、（古典的なCBC-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]
IKEv1の - 未定義（NO RFC）のIKEv2 - 任意のIPsec-V2 - SHOULD + [RFC4835]のIPsec-V3 - SHOULD + [RFC4835]
5.3.3. , Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec (S, May 2007)
5.3.3. 、IPsecの（S、2007年5月）でHMAC-SHA-384、HMAC-SHA-256を使用し、HMAC-SHA-512
[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. , The Use of HMAC-MD5-96 within ESP and AH (S, November 1998)
5.3.4. 、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]はHMAC-MD5、512ビットのブロックサイズと、128ビットの鍵と完全性保護アルゴリズムを説明し、完全性値（ICV）を確認してください。 IPsecの内で使用するために、ICVは、96ビットに切り捨てられます。それはIKEv1のとIPsec-v2のに必要なアルゴリズムでした。平野MD5の使用が廃止されますが、[RFC4835]は述べて：「弱点はMD5で明白になってきたが、これらはHMACでMD5の使用に影響を与えるべきではありません」。
Requirement levels for HMAC-MD5:
HMAC-MD5のための要件レベル：
IKEv1 - MAY [RFC4109] IKEv2 - optional [RFC4307] IPsec-v2 - MAY [RFC4835] IPsec-v3 - MAY [RFC4835]
IKEv1の - オプション[RFC4307]のIPsec-V2 - - [RFC4835] MAY - [RFC4835]のIPsec-V3月[RFC4109]のIKEv2月
5.3.5. , The AES-CMAC-96 Algorithm and Its Use with IPsec (S, June 2006)
5.3.5. 、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]はAES-CMAC、様々な長さのメッセージのために安全であるCBC-MACの別の変形は、記載されています。これは、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
IKEv1の - 任意のIPsec-V2 - - オプション（ただしIANA位ので、IKEによって交渉することができない）のIPsec-V3 - （NO IANA位）のIKEv2未定義オプション
5.3.6. , The Use of HMAC-RIPEMD-160-96 within ESP and AH (S, June 2000)
5.3.6. 、HMAC-RIPEMD-160-96 ESPおよびAH内での使用（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]はHMAC-RIPEMD、512ビットのブロックサイズと160ビットキーとICVと完全性保護アルゴリズムを記載しています。 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)
IKEv1の - 未定義（NO IANA位）のIKEv2 - 任意のIPsec-V3 - - （なしIANA＃）とのIPsec-V2未定義ないオプション（ただしIANA位ので、IKEによって交渉することができません）
5.3.7. , Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec (I, May 2007)
5.3.7. インターネット鍵交換（IKE）およびIPsec（I、2007年5月）におけるハッシュアルゴリズムの、使用
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]のために推奨されるアルゴリズムは、現在、既知の攻撃を受けないと結論づけています。それにもかかわらず、将来の使用のために[RFC3566]、AES-XCBC-PRF-128 [RFC4434]、およびHMAC-SHA-256、-384、および-512 [RFC4868]実装がサポートAES-XCBC-MAC-96を追加することを示唆しています。それはまたの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のSAで使用する複合モードのアルゴリズムをネゴシエートする方法について説明します。 [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のSAで使用するために複合モードのアルゴリズムを交渉する機能を追加しました。これらの実装は、IKE SAを保護するための複合モードのアルゴリズムを使用する機能が含まれていません。コンバインモードアルゴリズムのためのIANA番号はIKEv1のレジストリに追加されました。
5.4.1. , Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) (S, December 2005)
5.4.1. 、IPsecのカプセル化セキュリティペイロード（ESP）（S、2005年12月）でのAdvanced Encryption Standard（AES）CCMモードを使用しました
[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]は暗号化と整合性ESPトラフィックを保護するために、CBC-MAC（CCM）モード、組み合わせたアルゴリズムとカウンターにAESを使用する方法について説明します。 AES-CCMは、128ビットのブロックサイズとブロック・モード暗号化です。暗号化されたデータと一緒にパケットで送信されるランダムIV。 24ビットのソルト値（1 / SA）。 128、192、および256ビットのキーサイズと64、96と128ビットのICVサイズ。 AES-CCMが実装されている場合、128ビットのキーが必須です。他のサイズはMAYです。 64と128ビットのICVサイズが必須です。 96ビットは、MAYあります。ソルト値は、鍵生成プロセス中にIKEによって生成されます。同じキーを持つIVの再利用は、データのセキュリティを危険にさらします。このように、AES-CCMは、手動キー入力で使用すべきではありません。 [RFC4309]は、IKEは、ESP-V3 SAをネゴシエートするために使用できるIANA値を含みます。 3つのICVの長さは、それぞれ独自のIANA値を持っていますが、IKEネゴシエーションは、キーサイズを指定する必要があります。 [RFC4309]は、テストデータを含みます。 [RFC4309]は、IKEがESP SAで使用するAES-CCMの使用を交渉する方法について説明します。 [RFC5282]はのIKEv2 SAを保護するために、AES-CCMを使用する場合に延びています。
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を参照）。
5.4.2. , The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) (S, June 2005)
5.4.2. IPsecのカプセル化セキュリティペイロード（ESP）（S、2005年6月）におけるガロア/カウンタモード（GCM）の、使用
[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トラフィックを保護するために、ガロア/カウンタ（GCM）モード、組み合わせアルゴリズムにAESを使用する方法について説明します。 AES-GCMは、128ビットのブロックサイズとブロック・モード暗号化です。暗号化されたデータと一緒にパケットで送信されるランダムIV。 32ビットのソルト値（1 / SA）。 128、192、および256ビットのキーサイズ。 64、96、128ビットのICVサイズ。 AES-GCMが実装されている場合、128ビットのキーが必須です。他のサイズはMAYです。 128ビットのICVのサイズは、必要があります。 64および96ビットがMAYです。ソルト値は、鍵生成プロセス中にIKEによって生成されます。同じキーを持つIVの再利用は、データのセキュリティを危険にさらします。このように、AES-GCMは、手動キー入力で使用すべきではありません。 [RFC4106]は、IKEは、ESP-V3 SAをネゴシエートするために使用できる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がESP SAで使用するAES-GCMの使用を交渉する方法について説明します。 [RFC5282]はのIKEv2 SAを保護するために、AES-GCMの使用にこれを延びています。
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を参照）。
5.4.3. , The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH (S, May 2006)
5.4.3. 、IPsecのESPとAH（S、2006年5月）におけるガロアメッセージ認証コード（GMAC）の使用
[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]の変種です。 AH内で使用するための完全性保護アルゴリズム、およびESP内で使用するためのヌル暗号化を組み合わせたモードアルゴリズム：それは2つのバージョンがあります。これは、128、192、または256ビットの鍵を使用することができます。 ICVは常に128ビットで、切り捨てられません。 AES-GMACは、64ビットIVと32ビットの塩（1 / SA）から成る、nonceを使用しています。ソルト値は、鍵生成プロセス中にIKEによって生成されます。同じキーを持つsalt値の再利用は、データのセキュリティを危険にさらします。このように、AES-GMACは、手動キー入力で使用すべきではありません。 AH内で使用するために、それぞれのキーサイズは独自のIANA値を持っているので、IKEは、キーサイズを交渉する必要はありません。 ESP内での使用のために、そこに一つだけIANA値であるため、IKEネゴシエーションは、キーサイズを指定する必要があります。 AES-GMACは、IKEトラフィックが暗号化を必要とするため、独自のSAを保護するためにIKEで使用することはできません。
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. , Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol (S, August 2008)
5.4.4. インターネットキー交換バージョン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]はIKEv2のメッセージの暗号化および完全性保護を提供するために、AES-CCMとAES-GCMの使用を可能にするために、[RFC4309]と[RFC4106]を拡張します。
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は、IKE SAのとIPsecのSAで使用されている秘密鍵を生成する擬似ランダム機能（PRFを）を使用しています。これらの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のは、鍵材料を生成し、IKE SAのための完全性保護を提供するために、この機能のHMAC版を使用しています。したがって、HMACsはないのPRFは、現在のIKEv1で使用することはできません。
Requirement levels for PRF-HMAC-SHA1:
PRF-HMAC-SHA1のための要件レベル：
IKEv1 - MUST [RFC4109] IKEv2 - MUST [RFC4307]
IKEv1の - MUST [RFC4307] - [RFC4109]のIKEv2 MUST
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]
5.5.1. , The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) (S, February 2006)
5.5.1. インターネット鍵交換プロトコル（IKE）（S、2006年2月）のために、AES-XCBC-PRF-128アルゴリズム
[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ビットに切り捨てられず、それが修正される可変長キー、（AES-XCBCのアプリケーションを介してパディングを介して延長または短縮）を受け付け128ビットの鍵に。 [RFC4434]は、テストデータを含みます。
Requirement levels for AES-XCBC-PRF:
AES-XCBC-PRFのための要件レベル：
IKEv1 - undefined (no RFC) IKEv2 - SHOULD+ [RFC4307]
IKEv1の - + SHOULD [RFC4307] - （NO RFC）のIKEv2未定義
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の正誤表の提出で修正されました。
5.5.2. , 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. インターネット鍵交換プロトコル（IKE）（S、2006年8月）のために、高度暗号化標準暗号ベースのメッセージ認証コード-擬似ランダム機能-128（AES-CMAC-PRF-128）アルゴリズム
[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]はAES-XCBCための[RFC4434]で用いたものと同様の方法で、IKEv2の内PRFとしてAES-CMACの使用を可能にするために[RFC4494]を延びています。
Requirement levels for AES-CMAC-PRF:
AES-CMAC-PRFのための要件レベル：
IKEv1 - undefined (no IANA #) IKEv2 - optional
IKEv1の - 未定義（無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）ディフィー・ヘルマン（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-
[RFC4869]は、[RFC4308]で指定したものに、米国国家安全保障局（NSA）の「スイートB」の仕様に基づいて4事前定義されたスイートを、追加します。 IKE / ESPスイート "スイート-B-GCM-128" と「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.
B-GCM-256" は、AES-CBCの使用、AES-GCM、HMAC-SHA-256、またはHMAC-SHA-384、および256ビットまたは384ビットの楕円曲線（EC）DH基が挙げられる。IKE / AHスイート "スイート-B-GMAC-128" と "スイート-B-GMAC-256" は、AES-CBC、AES-GMAC、HMAC-SHA-256、またはHMAC-SHA-384、および256ビットまたは384の使用を含みます[RFC4308]はピア認証方法を指定しませんがEC DH基 - ビット、[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交換が含まれます。この値は、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グループ二つの楕円曲線（EC）グループの定義を含みます。 IKEv2の[RFC5996]は唯一のMODPグループを参照します。これらのグループの要求レベルは次のとおりです。
Requirement levels for DH MODP group 1:
DH MODPグループ1の要求レベル：
IKEv1 - MAY [RFC4109] IKEv2 - optional
IKEv1の - MAY [RFC4109]のIKEv2 - オプション
Requirement levels for DH MODP group 2:
DH MODPグループ2のための要件レベル：
IKEv1 - MUST [RFC4109] IKEv2 - MUST- [RFC4307]
IKEv1の - MUST- [RFC4307] - [RFC4109]のIKEv2 MUST
Requirement levels for EC groups 3-4:
ECグループ3-4のための要件レベル：
IKEv1 - MAY [RFC4109] IKEv2 - undefined (no IANA #)
IKEv1の - 未定義（無IANA番号） - [RFC4109]のIKEv2 MAY
5.7.1. , More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) (S, May 2003)
5.7.1. インターネット鍵交換（IKE）（S、2003年5月）のために、より多くのモジュラー指数（MODP）のDiffie-Hellmanグループ
[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は強くIKEで使用するために推奨される2048ビットのグループです。
Requirement levels for DH MODP group 14:
DH MODPグループ14のための要件レベル：
IKEv1 - SHOULD [RFC4109] IKEv2 - SHOULD+ [RFC4307]
IKEv1の - [RFC4109]のIKEv2必要があります - + SHOULD [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 - オプション
5.7.3. , Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2 (I, June 2010)
5.7.3. 、楕円曲線グループは、モジュロIKEとIKEv2のためのプライム（ECPグループ）（I、2010年6月）
[RFC5903] obsoletes [RFC4753], fixing an inconsistency in the DH shared secret value.
[RFC5903]、[RFC4753]を時代遅れ、DHに矛盾を固定するには、秘密値を共有しました。
5.7.4. , Additional Diffie-Hellman Groups for Use with IETF Standards (I, January 2008)
5.7.4. IETF標準で使用するため、追加のDiffie-Hellmanのグループ（I、2008年1月）
[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プロトコルでの使用を目的としています0.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 SAは、ポイントツーポイントの保護を提供します。 SAは、マルチキャストのための1対多または多対多、ケースのときにIPsecの暗号化アルゴリズムによって提供されるセキュリティは適用されません。マルチキャストセキュリティ（ミリ秒）ワーキンググループは、マルチキャストトラフィックで使用するためにIPsecにIKEの代替や拡張を定義しています。異なるマルチキャストグループの特性と要件が異なるしている：などの送信者の数（1対多または多対多）、メンバーの数（、少数の適度な、非常に大きい）、会員、リアルタイム配信の変動性を、彼らセキュリティ要件は、同様に変化します。ミリ秒で定義された各溶液は、可能なマルチキャストグループの多種多様のサブセットに適用されます。
6.1. , The Multicast Group Security Architecture (I, March 2004)
6.1. 、マルチキャストグループのセキュリティアーキテクチャ（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とは異なります。
6.2. , Multicast Extensions to the Security Architecture for the Internet Protocol (S, November 2008)
6.2. インターネットプロトコルのためのセキュリティアーキテクチャに、マルチキャスト拡張機能（S、2008年11月）
[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]で定義されたセキュリティアーキテクチャを拡張します。マルチキャストトラフィックにIPsec保護を適用するために使用される追加のデータベース - それは、SAS（グループセキュリティアソシエーションのGSA）の新しいクラスを定義します。また、[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]マルチキャストトラフィックを保護するためにSAを確立するために使用することができるようにのIKEv1を拡張します。この文書では、その目的のために使用される追加の交流やペイロードを定義します。
6.4. , Multicast Security (MSEC) Group Key Management Architecture (I, April 2005)
6.4. 、マルチキャストセキュリティ（MSEC）グループ鍵管理アーキテクチャ（I、2005年4月）
[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. , The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) (S, January 2006)
6.5. カプセル化セキュリティペイロード（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がより便利に作ることができる追加機能を明らかにしました。これらは、追加のピアの認証方法（ベター・ザン・ナッシングセキュリティ（BTNS）、キーのKerberos対応インターネット交渉（KINK）、およびIPSECKEY）を容易にするために、IPsecポリシーメカニズム、のIPsecのMIB、ペイロード圧縮（IPCompの）、拡張のサポート、および追加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. , IP Security Policy (IPSP) Requirements (S, August 2003)
7.1.1. 、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. , IPsec Configuration Policy Information Model (S, August 2003)
7.1.2. 、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ポリシーの内容と意味論に関する合意を促進するように設計されたIPセキュリティ（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.
長年にわたり、いくつかのMIB関連のインターネットドラフトは、IPsecとIKEのために提案されたが、一つだけは、RFCの状態に進行しました。
7.2.1. , IPsec Security Policy Database Configuration MIB (S, March 2007)
7.2.1. 、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データグラムの圧縮を可能にします。これらのアルゴリズムの三つは、次のとおり、[RFC2394]をDEFLATE LZS [RFC2395]、およびLZJHアルゴリズムに基づいているITU-T V.44パケット方式[RFC3051]。
7.3.1. , IP Payload Compression Protocol (IPComp) (S, September 2001)
7.3.1. 、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.
IPsecベースの暗号化は、IPデータグラムに適用した場合、IPペイロード圧縮は特に便利です。 IPデータグラムを暗号化すると無効下位プロトコル層での圧縮をレンダリングし、データが自然の中でランダムになります。 IKEは、IPsecのと一緒に圧縮を交渉するために使用されている場合、圧縮は暗号化の前に行うことができます。 [RFC3173]はIPCAを交渉するペイロード圧縮プロトコルのIPCompパケット構造のIPCompアソシエーション（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の実装の広範囲への主要な障害の一つは、ピア認証に使用することができ、既存の資格情報の欠如です。ベター・ザン・ナッシングセキュリティ（BTNS）は、自己署名証明書またはに接続されていない「裸」の公開鍵（公開鍵などの資格情報を使用して、IKEが認証されていない（匿名）のIPsec SAをネゴシエートできるようにすることで、この問題を回避しようとする試みでありますピア認証のための公開鍵証明書）。これは、SAによって保護され、後続のトラフィックは同じピアで行われることを保証し、受動攻撃から通信を保護します。これらのSAは、それ自身のピア認証を実行し、より高いレベルのアプリケーションプロトコルに暗号結合することができます。
[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のアーキテクチャを変更しません。
7.4.2. , Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec (S, November 2008)
7.4.2. ベター・ザン・ナッシング・セキュリティ：IPsecの（S、2008年11月）の非認証モード
[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]はIPsecのカプセル化セキュリティペイロード（ESP）およびIPsecの認証ヘッダー（AH）で使用するために認証されていないセキュリティアソシエーション（SA）を設定するのIKEv2を使用する方法を指定します。この文書では、ワイヤ上のビットを変更する必要はなく、ピア認証データベース（PAD）とセキュリティポリシーデータベース（SPD）に拡張子を指定しません。
7.4.3. , Problem and Applicability Statement for Better-Than-Nothing Security (BTNS) (I, November 2008)
7.4.3. ベター・ザン・ナッシングセキュリティ（BTNS）（I、2008年11月）のために、問題と適用ステートメント
[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]は、認証情報及びその関連IDを展開する必要が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.
キーのKerberos対応インターネット交渉（KINK）は、IPsecピア認証用のIKEに代わるものを提供しようとする試みです。これは、IPsec SAを確立するために、代わりにIKEの、Kerberosを使用しています。すでにKerberosのキーの集中管理システムを導入する企業にとって、IPsecは、追加のピア資格情報を必要とせずに実装することができます。一部のベンダーは、KINKの使用に代わるものとして、IKEv1のでKerberosを使用するための独自の拡張機能を実装しています。これらの拡張機能と同様に、KINKプロトコルは、IKEv1のにではなく、IKEv2のにのみ適用されます。
7.5.1. , Requirements for Kerberized Internet Negotiation of Keys (I, June 2001)
7.5.1. キーのKerberos対応インターネット交渉のため、要件（I、2001年6月）
[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. , Kerberized Internet Negotiation of Keys (KINK) (S, March 2006)
7.5.2. キーの、Kerberos対応のインターネット交渉（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のセキュアリモートアクセス（IPSRA）は、IKEはIKEv1のを変更せずに、ユーザーのデバイスだけでなく、ユーザーだけでなく、を認証することができ、「道路戦士」にIPsec保護を拡張する試みでした。ワーキンググループは、異なるIPSecリモートアクセスシナリオの一般的な要件を定義しました。試みはIKE内のピア認証に使用することができ、一時的または短命のユーザーの資格情報を作成するために、従来の認証メカニズムを使用するIKEのようなプロトコルを定義しました。このプロトコルは、標準的な公開鍵プロトコルよりも厄介であることが証明され、放棄されました。これは、ユーザー認証のためのEAPの使用を組み込んだのIKEv2の開発につながりました。
7.6.1. , Requirements for IPsec Remote Access Scenarios (I, January 2003)
7.6.1. IPsecリモートアクセスシナリオのため、要件（I、2003年1月）
[RFC3457] explores and enumerates the requirements of various IPsec remote access scenarios, without suggesting particular solutions for them.
[RFC3457]は彼らのために特定の解決策を示唆することなく、様々なIPSecリモートアクセスシナリオの要件を検討し、列挙する。
7.6.2. , Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode (S, January 2003)
7.6.2. IPsecトンネルモード（S、2003年1月）の、動的ホスト構成プロトコル（DHCPv4の）構成
[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. , A method for storing IPsec keying material in DNS (S, February 2005)
7.7.1. 、DNS（S 2005年2月）にIPSec鍵材料を格納するための方法
[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を使用してください。
8.1.1. , Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways (I, August 2005)
8.1.1. 、問題文：仮想プライベートネットワーク（VPN）ゲートウェイのモバイルIPv4トラバーサル（I、2005年8月）
[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技術の一つです。これは、企業やオペレータ環境でのIPsecと一緒に実行されているモバイルIPv4のための実用的な展開シナリオを識別し、説明しています。また、IPsecベースのVPNゲートウェイ間でのシームレスなマルチベンダーのIPv4モビリティをサポートするためのソリューション提案を評価するためのフレームワークのガイドラインのセットを指定します。
8.1.2. , Mobile IPv4 Traversal across IPsec-Based VPN Gateways (S, June 2008)
8.1.2. IPSecベースのVPNゲートウェイ（S、2008年6月）全体で、モバイルIPv4トラバーサル
[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再交渉を最小化するためのメカニズムを提案しています。
8.1.3. , Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents (S, June 2004)
8.1.3. 、モバイルノードとホームエージェント間のモバイルIPv6シグナリングを保護するためにIPsecを使用して（S、2004年6月）
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シグナリングメッセージを保護するために使用することができ、セキュリティアソシエーションデータベースのエントリの例を示しています。また、自動的にSAを確立するために、手動でキー付きのIPsecセキュリティアソシエーションまたはIKEv1のいずれかを設定する方法について説明します。モバイルIPv6は、IPsec処理でホームアドレス宛先オプションとルーティングヘッダを考慮が必要です。また、IPsecとIKEセキュリティアソシエーションアドレスは、モバイルIPv6シグナリングメッセージによって更新することができます。
8.1.4. , Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture (S, April 2007)
8.1.4. IKEv2のと改訂のIPsecアーキテクチャ（S、2007年4月）で、モバイル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のためにSAを設定するためにIKEv2のの使用を記載しています。
8.1.5. , Mobile IPv6 Bootstrapping in Split Scenario (S, October 2007)
8.1.5. スプリットシナリオ（S、2007年10月）で、モバイルIPv6ブートストラップ
[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交換と何これを行うためにCFG_REQUESTメッセージ中に存在する必要が属性に設定ペイロードを通じてそのホームアドレスとホームプレフィックスを要求できる方法を定義します。また、ホームエージェントは、IKEv2の交換のために使用される資格情報を許可することができる方法を指定します。
[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]は、任意のモビリティ関連シグナリングの参加を必要とせずにホストにモビリティサービスを提供するために使用されるネットワーク・ベースのモビリティ管理プロトコルを記載しています。これは、モバイルアクセスゲートウェイ（MAG）およびローカル・モビリティ・アンカー（LMA）と呼ばれる2つのネットワークエンティティ間のシグナリングメッセージを移動性を保護するためにIPsecを使用しています。また、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を使用しています。また、SPDエントリとIKEv2のが必要なSAを設定するために使用されたパッドのエントリについて説明します。
8.1.8. , Hierarchical Mobile IPv6 (HMIPv6) Mobility Management (S, October 2008)
8.1.8. 、階層化モバイル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のハンドオーバ速度を向上させることができます。これは、モビリティ・アンカー・ポイント（MAP）と呼ばれるモバイルノードとローカル・モビリティ管理エンティティ間のシグナリングを保護するためにIPsecを使用します。 MAPは、移動ノードの地域気付アドレス（RCoAを）を割り当てるためのIPsecピア認証データベース（PAD）エントリと[RFC4877]に記載された構成ペイロードを使用します。
8.2.1. , Authentication/Confidentiality for OSPFv3 (S, June 2006)
8.2.1. 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アドレス（ロケータ）変化間通信の継続を可能にします。これは、ピア認証のための新しいホストアイデンティティ（HI）のネームスペースから公開鍵識別子を使用しています。これはHMAC-SHA-1-96およびそのシグナリングメッセージを保護するためにIPsec ESPおよびAHとAES-CBCアルゴリズムを使用します。
8.3.2. , Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (E, April 2008)
8.3.2. 、ホスト識別プロトコル（HIP）（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セキュリティアソシエーション（SA）のペアを作成するためのHIP拡張のセットを指定します。ホストとの間で確立されてきたESP SAを必要HIPアソシエーション後、ユーザデータ通信は、ESPを使用して保護されています。また、この文書では、ESPセキュリティパラメータインデックス（SPI）は、既存のESPセキュリティアソシエーションを更新するために、右のホストコンテキスト（ホストID）及び方法を示すために使用される方法を指定します。
8.3.3. , End-Host Mobility and Multihoming with the Host Identity (E, April 2008)
8.3.3. ホストアイデンティティ（E、2008年4月）で、エンドホストモビリティとマルチホーミング
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.
ホストは、HIPを使用する場合、上層のプロトコル副層（例えば、トランスポート層ソケット）およびカプセル化セキュリティペイロード（ESP）セキュリティアソシエーション（SA）は、これらのホストアイデンティティの表現に結合され、IPアドレスのみパケット転送のために使用されます。 [RFC5206]はHIPホストは、それが到達された代替アドレスに関するピアに通知することを可能にするHIPメッセージで使用するための一般LOCATORパラメータを定義します。また、ホストは、そのIPアドレスを変更し、必ずしも再入力することなく、そのピアにパケットを送信し続けることができる方法を指定します。
8.3.4. , NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) (I, April 2008)
8.3.4. ホスト識別プロトコル（HIP）の、NATやファイアウォール越えの問題（I、2008年4月）
[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]は、ネットワークアドレス変換およびファイアウォールを含むネットワーク経路を横切るHIP通信に関連する問題を論じています。これは、HIP基本交換とESPのデータ交換でのNATやファイアウォールの影響を分析します。それは、NATやファイアウォールトラバーサルを改善しようとHIPへの変化の可能性を説明し、NATの背後にあるHIPノードは到達可能せるためのランデブーポイントを提案しています。 NATのは、HIPメッセージをより意識することもメカニズムを示唆しています。
8.4.1. , On the Use of Stream Control Transmission Protocol (SCTP) with IPsec (S, July 2003)
8.4.1. 、IPsecの（S、2003年7月）とストリーム制御伝送プロトコル（SCTP）の利用について
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.
ストリーム制御伝送プロトコル（SCTP）がIPなどのコネクションレスのパケットネットワーク上で動作する信頼性の高いトランスポートプロトコルです。 [RFC3554]はIPsecとIKE SCTPトラフィックを固定で使用するための機能要件を記述する。これは、単一のSCTPアソシエーションに関連付けられた複数の送信元アドレスと宛先アドレスを考慮するためにIPsec処理におけるIKE [RFC2409]及び実装の選択に新しいIDのタイプの形でSCTPのサポートを追加します。この文書では、唯一のIKEv1およびIPsec-V2に適用されます。それは、IKEv2のおよびIPsec-V3には適用されません。
8.5.1. , RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed (S, July 2001)
8.5.1. 、ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、ESP、および非圧縮（S、2001年7月）
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つのプロトコル、このフレームワークを適用します。
8.5.2. , RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008)
8.5.2. 、ロバストヘッダ圧縮バージョン2（ROHCv2）：RTP、UDP、IP、ESP、およびUDP-Liteのプロファイル（S、2008年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ヘッダを解析し、効率的にヘッダを圧縮するために、静的な、よく知られた、不規則な、等のようないくつかのクラスにフィールドを分類します。
8.5.3. , Integration of Robust Header Compression over IPsec Security Associations (I, May 2010)
8.5.3. IPsecセキュリティアソシエーションを超えるロバストヘッダ圧縮の、統合（I、2010年5月）
[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を有効にするには、拡張子を指定します。この文書では、トンネルモードSAにのみ適用され、トランスポートモードSAをサポートしていません。
8.5.4. , IKEv2 Extensions to Support Robust Header Compression over IPsec (S, May 2010)
8.5.4. 、IKEv2の拡張機能のIPsec（S、2010年5月）の上にロバストヘッダ圧縮をサポートします
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の使用方法について説明します。
8.5.5. , IPsec Extensions to Support Robust Header Compression over IPsec (S, May 2010)
8.5.5. 、IPsec拡張機能のIPsec（S、2010年5月）の上にロバストヘッダ圧縮をサポートします
[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. , BGP IPsec Tunnel Encapsulation Attribute (S, June 2009)
8.6.1. 、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]はIPsecと、必要に応じて、IKEの使用はBGPトンネルを保護することができ、追加のBGPカプセル化次のアドレスファミリ識別子（SAFI）を追加します。これは、IPとMPLSインIPトンネル内のIPを保護するためにトンネルモードとトランスポートモードでAHとESPの使用に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をサポートするIPSecデバイスのためのパフォーマンステストの方法論を確立するに焦点を当てているが、IKEv2のをカバーしていません。
[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. , Security Model with Tunnel-mode IPsec for NAT domains (I, October 1999)
8.8.1. 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]はトンネル・モードのIPsecセキュリティがNATデバイスで構築されることが可能なセキュリティモデルを記述する。それは、NATのアドレス指定のプライベート領域に基づいてセキュリティポリシーとSAの属性を管理する方法を定義します。また、アドレス指定のパブリックに取り組む民間分野からポリシーを翻訳IKE-ALG（アプリケーションレベルゲートウェイ）を指定することにより、このようなシナリオでIKEを操作する方法を指定します。ここで紹介するモデルはIKEv1のから専門用語を使用していますが、それはIKEv1の、IKEv2の、IPsecの-V2、およびIPsec-V3内に配備することができます。このセキュリティモデルは、広く採用されていません
8.9.1. , Security Mechanism Agreement for the Session Initiation Protocol (SIP) (S, January 2003)
8.9.1. セッション開始プロトコル（SIP）（S、2003年1月）のために、セキュリティメカニズム合意
[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とその関連パラメータ（アルゴリズム、プロトコル、モード、のSPIおよびポート）と呼ばれるセキュリティメカニズムを記述する。
8.10.1. , Common Architecture Label IPv6 Security Option (CALIPSO) (I, July 2009)
8.10.1. 、共通のアーキテクチャラベル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. , The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method (E, February 2008)
9.1.1. 、拡張認証プロトコル - インターネット鍵交換プロトコルバージョン2（EAP-IKEv2の）方法（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-のIKEv2は、EAPピアとEAPサーバとの間の相互認証およびセッション鍵の確立を提供します。これは、完全なEAP-のIKEv2メッセージ交換とプロトコルメッセージの組成物を記載しています。
9.2.1. , Use of IKEv2 in the Fibre Channel Security Association Management Protocol (I, July 2006)
9.2.1. ファイバチャネルセキュリティアソシエーション管理プロトコル（I、2006年7月）でのIKEv2の、使用
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.
ファイバチャネル（FC）は、ストレージエリアネットワークで使用されるギガビット高速ネットワーク技術です。ファイバチャネルセキュリティプロトコル（FC-SP）標準は、ファイバー・チャネル・エンティティとセキュリティアソシエーションの設定の認証を提供するためのIKEv2プロトコル[RFC4306]を適応しています。 IPは、ファイバチャネルおよびファイバチャネル上で転送されるので、IPの上に搬送され、IKEv2のは、IPとFCトラフィックの両方に使用されて混乱する可能性があります。 [RFC4595]はFCオーバーIPまたはIKEv2の/ IP上のIKEv2 / FCのいずれか誤った使い方が原因許容される提案の不在にネゴシエーション失敗をもたらすであろうことを保証する方法でFC上のIKEv2の識別子を指定します。
9.3.1. , GigaBeam High-Speed Radio Link Encryption (I, October 2006)
9.3.1. 、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]は、無線リンクの製品のWiFiber（TM）ファミリの一部としてGigaBeamで使用される暗号化と鍵管理について説明し、同等の機能を含むように同様の無線製品開発の努力のためのガイドラインとして機能することを目的としています。これは、両方の加入者と管理トラフィックの機密性と完全性保護を提供するために使用されているアルゴリズムを指定します。また、2つのGigabeamラジオコントロールモジュール（の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.
著者は、ヤロンシェファー、ポール・ホフマン、ヨアフニール、RajeshwarシンJenwar、アルフレッドHoenes、アル・モートン、ガブリエルモンテネグロ、ショーン・ターナー、ジュリアンLaganier、グレーデイリー、スコットMoonen、リチャードGraveman、TERO Kivinen、パシEronen、蘭に感謝したいと思いますアトキンソン、デビッド・ブラック、およびティムポーク、このドキュメントを再検討し、変更を示唆ため。
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.ヴァン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.、ヴァンHerck T.、およびM.ブストス、 "ベンチマークの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]ボーリュー、S.及びR.ペレイラ、 "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]ペレイラ、R.、アナンド、S.、およびB.パテル、 "ISAKKMP構成方法"、進歩、1999年8月ワーク。
[ISAKMP-XAUTH] Pereira, R. and S. Beaulieu, "Extended Authentication within ISAKMP/Oakley (XAUTH)", Work in Progress, December 1999.
[ISAKMP-XAUTH]ペレイラ、R.およびS.ボーリュー、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, December 1998.
[RFC2394]ペレイラ、R.、 "DEFLATEを使用するIPペイロード圧縮"、RFC 2394、1998年12月。
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998.
[RFC2395]フレンド、R.とR. Monsour、 "IPペイロード圧縮使い方LZS"、RFC 2395、1998年12月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、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.グレン、 "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.グレン、 "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、 "明示的なIVとESP DES-CBC暗号アルゴリズム"、RFC 2405、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
"ISAKMPのための解釈のインターネットIPセキュリティー領域" [RFC2407]パイパー、D.、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]モーガン、D.、Schertler、M.、シュナイダー、M.、およびJ.ターナー、 "インターネットセキュリティ協会と鍵管理プロトコル（ISAKMP）"、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（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]グレン、R.とS.ケント、 "NULL暗号化アルゴリズムとIPsecでの使用"、RFC 2410、1998年11月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411]セイヤー、R.、Doraswamy、N.、およびR.グレン、 "IPセキュリティドキュメントロードマップ"、RFC 2411、1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]オーマン、H.、 "OAKLEYキー決意プロトコル"、RFC 2412、1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451]ペレイラ、R.とR.アダムス、 "ESP CBCモード暗号アルゴリズム"、RFC 2451、1998年11月。
[RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures Messages", RFC 2521, March 1999.
[RFC2521]カーン、P.とW.シンプソン、 "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.プロボス氏、 "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]ヒース、J.とJ.ボーダー、 "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]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[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]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC3129] Thomas, M., "Requirements for Kerberized Internet Negotiation of Keys", RFC 3129, June 2001.
[RFC3129]トーマス、M.、 "キーのKerberos対応インターネット交渉のための要件"、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.、ペレイラ、R。、およびM.トーマス、 "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.、カマリロ、G.、ニエミ、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]パテル、B.、Aboba、B.、ケリー、S.、およびV.グプタ、 "IPsecのトンネルモードの動的ホスト構成プロトコル（DHCPv4の）設定"、RFC 3456、2003年1月。
[RFC3457] Kelly, S. and S. Ramamoorthi, "Requirements for IPsec Remote Access Scenarios", RFC 3457, January 2003.
[RFC3457]ケリー、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.古城、 "インターネット鍵交換のためのより多くのモジュラー指数（MODP）のDiffie-Hellmanグループ（IKE）"、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.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、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.
"IPsecでストリーム制御伝送プロトコル（SCTP）の使用に" [RFC3554] Bellovin氏、S.、Ioannidis、J.、Keromytis、A.、およびR.スチュワート、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]ジェイソン、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]ブレイズ、M.、Keromytis、A.、リチャードソン、M.、およびL.サンチェス、 "IPセキュリティポリシー（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.、RFC 3686 "IPsecのカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）カウンタモードの使用" を、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]黄、G.、ボーリュー、S.、およびD.ロシュフォール、 "検出デッドインターネット鍵交換（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.ディクソン、 "IPsecでネットワークアドレス変換（NAT）の互換性の要件"、RFC 3715、2004年3月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T.とB.ウィス、 "マルチキャストグループのセキュリティアーキテクチャ"、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.デュポン、 "モバイルノードとホームエージェント間のモバイルIPv6シグナリングを保護するためにIPsecを使用する"、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.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、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]タッチ、J.、エッゲルト、L.、およびY.王、 "ダイナミックルーティングのための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.ボルペ、 "IKEにおけるNATトラバーサルのネゴシエーション"、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.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "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.、カネッティ、R.、Dondeti、L.、およびF.リンドホルム、 "マルチキャストセキュリティ（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.、エド、およびH. Levkowetz、エド、 "問題文：仮想プライベートネットワーク（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.マグリュー、 "IPsecのカプセル化セキュリティペイロード（ESP）におけるガロア/カウンタモード（GCM）の使用"、RFC 4106、2005年6月。
[RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version 1 (IKEv1)", RFC 4109, May 2005.
[RFC4109]ホフマン、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]リー、H.、ユン、J.、リー、S.、およびJ.リー、 "SEED暗号アルゴリズムおよびIPSecでの使用"、RFC 4196、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（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]ケント、S.、 "拡張シーケンス番号（ESN）インターネットSecurity AssociationとKey Managementプロトコル（ISAKMP）のための解釈のIPsecのドメイン（DOI）の補遺"、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]イーストレーク第3、D.、RFC 4305、2005年12月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、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]ホフマン、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.、RFC 4309、2005年12月 "IPsecのカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）CCMモードを使用しました"。
[RFC4312] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher Algorithm and Its Use With IPsec", RFC 4312, December 2005.
[RFC4312]加藤、A.、Moriai、S.、およびM.神田、 "椿暗号アルゴリズムとIPsecでの使用"、RFC 4312、2005年12月。
[RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)", RFC 4322, December 2005.
[RFC4322]リチャードソン、M.とD. Redelmeier、 "IKE（Internet Key Exchange）を使用して日和見暗号化"、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]ヴァイス、B.、RFC 4359、2006年1月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）内のRSA / SHA-1署名の使用"。
[RFC4430] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006.
[RFC4430]坂根、S.、鎌田、K.、トーマス、M.、およびJ. Vilhuber、 "キーのケルベロスインターネットネゴシエーション（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]ホフマン、P.、 "インターネット鍵交換プロトコルのためのAES-XCBC-PRF-128アルゴリズム（IKE）"、RFC 4434、2006年2月。
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4478, April 2006.
[RFC4478]ニール、Y.、RFC 4478、2006年4月 "インターネットキーエクスチェンジ（IKEv2の）プロトコルで繰り返さ認証"。
[RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 Algorithm and Its Use with IPsec", RFC 4494, June 2006.
[RFC4494]歌、JH。、Poovendran、R.、およびJ.リー、 "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]はハーニー、H.、メタ、U.、Colegrove、A.、およびG.グロスは、：RFC 4535、2006年6月、 "GSAKMPグループは、協会の鍵管理プロトコルをセキュア"。
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006.
[RFC4543]マグリュー、D.とJ. Viega、 "IPsecのESPとAHでガロアメッセージ認証コード（GMAC）の使用"、RFC 4543、2006年5月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552]グプタ、M.およびN.メラム、 "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]メイノー、F.とD.黒、「ファイバチャネルセキュリティアソシエーション管理プロトコルでの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]ソング、J.、Poovendran、R.、リー、J.、およびT.岩田、「高度暗号化標準暗号ベースのメッセージ認証コード、擬似ランダム関数-128（AES-CMAC-PRF-128インターネット鍵交換プロトコル（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、RFC 4621、2006年8月 "のIKEv2モビリティとマルチホーミング（MOBIKE）プロトコルの設計"。
[RFC4705] Housley, R. and A. Corry, "GigaBeam High-Speed Radio Link Encryption", RFC 4705, October 2006.
[RFC4705] Housley氏、R.とA.コリー、 "GigaBeam高速無線リンク暗号化"、RFC 4705、2006年10月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
[RFC4718] Eronen、P.およびP.ホフマン、 "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]フー、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]フー、D.およびJ. Solinas、 "楕円曲線デジタル署名アルゴリズム（ECDSA）を使用してIKE及びIKEv2の認証"、RFC 4754、2007年1月。
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007.
[RFC4806]マイヤーズ、M.およびH. Tschofenig、 "IKEv2のにオンライン証明書状態プロトコル（OCSP）の拡張"、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]ベア、M.、シャレー、R.、Hardaker、W.、ストーリー、R.、およびC.王、 "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.、エド。、ターナー、S.、エド。、およびG. Lebovitz、エド。、RFC 4809、2007年2月、 "IPsecの証明書管理プロファイルの要件"。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835] Manral、V.、RFC 4835、2007年4月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC4868]ケリー、S.、およびS.フランケル、 "HMAC-SHA-256を使用して、HMAC-SHA-384、およびIPSecとHMAC-SHA-512"、RFC 4868、2007年5月。
[RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 4869, May 2007.
[RFC4869]法、L.および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.デュポン、 "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.、パルタサラティ、M.、Savola、P.、およびH. Tschofenig、RFC 4891、2007年5月の "IPv6インIPv4トンネルを保護するためにIPsecを使用します"。
[RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec", RFC 4894, May 2007.
[RFC4894]ホフマン、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]コーバー、B.、RFC 4945、2007年8月 "のIKEv1 / ISAKMP、IKEv2の、およびPKIXのインターネットIPセキュリティPKIプロファイル"。
[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026] Giaretta、G.、エド。、ケンプ、J.、およびV. Devarapalli、エド。、 "分割シナリオにおけるモバイル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.、オオバ、Y.、およびF. Bersani、 "拡張認証プロトコル、インターネット鍵交換プロトコルバージョン2（EAP-IKEv2の）方法"、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.ケント、 "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]モスコウィッツ、R.、Nikander、P.、Jokela、P.、エド。、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、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.、モスコウィッツ、R.、およびP. Nikander、RFC 5202、2008年4月 "ホスト識別プロトコル（HIP）とカプセル化セキュリティペイロード（ESP）トランスポートフォーマットを使用します"。
[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.、ヘンダーソン、T.、エド。、フォークト、C.、およびJ. Arkko、 "エンドホストモビリティとマルチホーミングをホストアイデンティティプロトコルで"、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.エッゲルト、 "NATおよびホスト識別プロトコル（HIP）コミュニケーションのファイアウォール越えの問題"、RFC 5207、2008年4月。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
【Ramphsi 5213] gundavelli、S。、ら、Leunji、K.、Devarapalliは、VEの、Chaudhuriの、K.、およびb。パティル、 "プロキシ・モバイル・20 6"、rphak 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]ペルティエ、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.
"IPSecベースのVPNゲートウェイを横切るモバイルIPv4トラバーサル" [RFC5265] Vaarala、S.及びE. Klovning、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）を使用して接続およびモビリティセキュア"、BCP 136、RFC 5266、2008年6月。
[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]ブラック、D.とD.マグリュー、RFC 5282、2008年8月「インターネット鍵交換バージョン2（IKEv2の）プロトコルの暗号化されたペイロードと認証暗号化アルゴリズムを使用します」。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380]ソリマン、H.、カステルッシア、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]ヴァイス、B.、グロス、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]タッチ、J.、ブラック、D.、およびY.王、RFC 5387、2008年11月 "ベター・ザン・ナッシングセキュリティ（BTNS）のための問題と適用に関する声明"。
[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]加藤、A.、神田、M.、およびS.菅野、 "IPsecので使用するためのツバキのための動作種別"、RFC 5529、2009年4月。
[RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel Encapsulation Attribute", RFC 5566, June 2009.
[RFC5566]バーガー、L.、ホワイト、R.、およびE.ローゼン、 "BGP IPsecトンネルカプセル化属性"、RFC 5566、2009年6月。
[RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[RFC5568] Koodli、R.、エド。、 "モバイルIPv6高速ハンドオーバ"、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.、アトキンソン、R.、およびG.トーマス、 "共通のアーキテクチャラベルIPv6のセキュリティオプション（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、2009年11月、RFC 5685 "インターネット鍵交換プロトコルバージョン2（IKEv2の）ためのメカニズムをリダイレクト"。
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
[RFC5723]シェファー、Y.およびH. Tschofenig、 "インターネット鍵交換プロトコルバージョン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でのIPv6設定（IKEv2の）"、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.、モンテネグロ、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.ボルマン、RFC 5856、2010年5月、 "IPsecセキュリティアソシエーションを超えるロバストヘッダ圧縮の統合"。
[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.ボルマンは、RFC 5857、2010年5月の "IKEv2の拡張機能は、IPsec経由ロバストヘッダ圧縮をサポートします"。
[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.ボルマンは、RFC 5858、2010年5月 "IPsec拡張機能は、IPsec経由ロバストヘッダ圧縮をサポートします"。
[RFC5879] Kivinen, T. and D. McDonald, "Heuristics for Detecting ESP-NULL Packets", RFC 5879, May 2010.
[RFC5879] Kivinen、T.およびD.マクドナルド、RFC 5879、2010年5月 "を検出ESP-NULLパケットのためのヒューリスティクス"。
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 2010.
[RFC5903]フー、D.およびJ. Solinas、 "楕円曲線グループ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]シェン、S.、マオ、Y.、およびNSS。 、RFC 5930、2010年7月 "インターネット鍵交換バージョン02（IKEv2の）プロトコルでのAdvanced Encryption Standardカウンタモード（AES-CTR）を使用する" マーシー、。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン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.シェファー、 "IKEv2の中にEAP-のみの認証のための拡張"、RFC 5998、2010年9月。
[RFC6027] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, October 2010.
[RFC6027]ニール、Y.、 "IPsecのクラスタの問題に関する声明"、RFC 6027、2010年10月。
Appendix A. Summary of Algorithm Requirement Levels
アルゴリズムの要件レベルの付録A.概要
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
シーラ・フランケルNISTビル。 223 Rmの。 B366ゲーサーズバーグ、MD 20899
Phone: 1-301-975-3297 EMail: sheila.frankel@nist.gov
電話：1-301-975-3297 Eメール：sheila.frankel@nist.gov
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
スレシュクリシュナンエリクソン8400 Decarie大通りマウントロイヤル、QCカナダの町
Phone: 1-514-345-7900 x42871 EMail: suresh.krishnan@ericsson.com
電話：1-514-345-7900 x42871メール：suresh.krishnan@ericsson.com