[要約] 要約：RFC 7815は、IKEv2イニシエータの実装に関する最小限の要件を定義しています。 目的：IKEv2イニシエータの実装者に対して、必要な機能と動作の最小セットを提供し、セキュアな通信の確立を支援することです。
Internet Engineering Task Force (IETF) T. Kivinen
Request for Comments: 7815 INSIDE Secure
Category: Informational March 2016
ISSN: 2070-1721
Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation
最小限のインターネットキー交換バージョン2（IKEv2）イニシエーターの実装
Abstract
概要
This document describes a minimal initiator version of the Internet Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations that can be done. The protocol described here is interoperable with a full IKEv2 implementation using shared secret authentication (IKEv2 does not require the use of certificate authentication). This minimal initiator implementation can only talk to a full IKEv2 implementation acting as the responder; thus, two minimal initiator implementations cannot talk to each other.
このドキュメントでは、制約付きノード用のInternet Key Exchangeバージョン2（IKEv2）プロトコルの最小開始バージョンについて説明します。 IKEv2は、相互認証を実行し、セキュリティアソシエーション（SA）を確立および維持するために使用されるIPsecのコンポーネントです。 IKEv2には、最小限の実装では不要ないくつかのオプション機能が含まれています。このドキュメントでは、最小限の実装から何が必要かを説明し、実行可能なさまざまな最適化についても説明します。ここで説明するプロトコルは、共有秘密認証を使用する完全なIKEv2実装と相互運用できます（IKEv2では証明書認証を使用する必要はありません）。この最小限のイニシエーター実装は、レスポンダーとして機能する完全なIKEv2実装とのみ通信できます。したがって、2つの最小イニシエーター実装は互いに通信できません。
This document does not update or modify RFC 7296 but provides a more compact description of the minimal version of the protocol. If this document and RFC 7296 conflict, then RFC 7296 is the authoritative description.
このドキュメントはRFC 7296を更新または変更しませんが、プロトコルの最小バージョンのより簡潔な説明を提供します。このドキュメントとRFC 7296が矛盾する場合は、RFC 7296が信頼できる説明です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7815.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7815で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . 5
2.2. Other Exchanges . . . . . . . . . . . . . . . . . . . . . 12
2.3. Generating Keying Material . . . . . . . . . . . . . . . 12
3. Conformance Requirements . . . . . . . . . . . . . . . . . . 13
4. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Header and Payload Formats . . . . . . . . . . . . . 17
A.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 17
A.2. Generic Payload Header . . . . . . . . . . . . . . . . . 19
A.3. Security Association Payload . . . . . . . . . . . . . . 21
A.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 23
A.3.2. Transform Substructure . . . . . . . . . . . . . . . 24
A.3.3. Valid Transform Types by Protocol . . . . . . . . . . 26
A.3.4. Transform Attributes . . . . . . . . . . . . . . . . 26
A.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 27
A.5. Identification Payloads . . . . . . . . . . . . . . . . . 27
A.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 29
A.7. Certificate Request Payload . . . . . . . . . . . . . . . 30
A.8. Authentication Payload . . . . . . . . . . . . . . . . . 31
A.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 31
A.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 32
A.10.1. Notify Message Types . . . . . . . . . . . . . . . . 33
A.11. Traffic Selector Payload . . . . . . . . . . . . . . . . 34
A.11.1. Traffic Selector . . . . . . . . . . . . . . . . . . 36
A.12. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Useful Optional Features . . . . . . . . . . . . . . 39
B.1. IKE SA Delete Notification . . . . . . . . . . . . . . . 39
B.2. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 40
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41
The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources. This document describes a minimal IKEv2 implementation designed for use on such constrained nodes that is interoperable with "Internet Key Exchange Protocol Version 2 (IKEv2)" [RFC7296].
インターネットプロトコルスイートは、電力、メモリ、および処理リソースに厳しい制約がある小さなデバイスでますます使用されています。このドキュメントでは、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」[RFC7296]と相互運用可能な、このような制約のあるノードで使用するために設計された最小限のIKEv2実装について説明します。
A minimal IKEv2 implementation only supports the initiator end of the protocol. It only supports the initial IKE_SA_INIT and IKE_AUTH exchanges and does not initiate any other exchanges. It also replies with an empty (or error) message to all incoming requests.
最小限のIKEv2実装は、プロトコルの開始側のみをサポートします。最初のIKE_SA_INITおよびIKE_AUTH交換のみをサポートし、他の交換は開始しません。また、すべての着信要求に対して空（またはエラー）メッセージで応答します。
This means that most of the optional features of IKEv2 are left out: NAT traversal, IKE SA rekey, Child SA rekey, multiple Child SAs, deleting Child / IKE SAs, Configuration payloads, Extensible Authentication Protocol (EAP) authentication, COOKIEs, etc.
つまり、NATトラバーサル、IKE SAキー再生成、子SAキー再生成、複数の子SAの削除、子/ IKE SAの削除、構成ペイロード、拡張認証プロトコル（EAP）認証、COOKIEなど、IKEv2のほとんどのオプション機能が省略されます。
Some optimizations can be done because of the limited set of supported features, and this text should not be considered for generic IKEv2 implementations (for example, Message IDs can be done as specified because minimal implementation is only sending out an IKE_SA_INIT and IKE_AUTH request and not any other request).
サポートされている機能のセットが限られているため、一部の最適化を行うことができます。このテキストは、一般的なIKEv2実装では考慮しないでください（たとえば、最小限の実装ではIKE_SA_INITおよびIKE_AUTHリクエストのみを送信し、その他のリクエスト）。
This document is intended to be standalone, meaning everything needed to implement IKEv2 is copied here except the description of the cryptographic algorithms. The IKEv2 specification has lots of background information and rationale that has been omitted from this document.
このドキュメントはスタンドアロンであることを意図しています。つまり、暗号化アルゴリズムの説明を除いて、IKEv2を実装するために必要なすべてがここにコピーされます。 IKEv2仕様には、このドキュメントから省略された多くの背景情報と根拠があります。
Numerous additional numeric values from IANA registries have been omitted from this document; only those which are of interest for a minimal implementation are listed.
IANAレジストリからの多数の追加の数値は、このドキュメントから省略されています。最小限の実装に関心のあるものだけがリストされています。
The main body of this document describes how to use the shared secret authentication in IKEv2, as it is easiest to implement. In some cases, that is not enough, and Appendix B.2 describes how to use raw public keys instead of shared secret authentication.
このドキュメントの本文では、実装が最も簡単なIKEv2で共有秘密認証を使用する方法について説明します。場合によっては、それでは不十分であり、付録B.2では、共有秘密認証の代わりに生の公開鍵を使用する方法を説明しています。
For more information, check the full IKEv2 specification in [RFC7296] and [IKEV2IANA].
詳細については、[RFC7296]および[IKEV2IANA]の完全なIKEv2仕様を確認してください。
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]. The term "Constrained Node" is defined in "Terminology for Constrained-Node Networks" [RFC7228].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。 「制約付きノード」という用語は、「制約付きノードネットワークの用語」[RFC7228]で定義されています。
One use case for this kind of minimal implementation is in small devices doing machine-to-machine communication. In such environments, the node initiating connections can be very small, and the other end of the communication channel is some kind of larger device.
この種の最小限の実装の1つの使用例は、マシン間通信を行う小さなデバイスです。このような環境では、接続を開始するノードは非常に小さくなり、通信チャネルのもう一方の端はある種の大きなデバイスになります。
An example of the small initiating node could be a remote garage door opener device, i.e., a device having buttons that open and close a garage door and that connects to the home area network server over a wireless link.
小さな開始ノードの例は、リモートガレージドア開閉装置、つまり、ガレージドアを開閉するボタンを備え、無線リンクを介してホームエリアネットワークサーバーに接続する装置です。
Another example of such a device is some kind of sensor device, for example, a room temperature sensor, which sends periodic temperature data to some centralized node.
そのようなデバイスの別の例は、定期的な温度データを集中管理されたノードに送信する、ある種のセンサーデバイス（たとえば、室温センサー）です。
Those devices usually sleep for a long time and only wake up periodically or because of user interaction. The data transfer is always initiated from that sleeping node when they wake up; after they send packets, there might be ACKs or other packets coming back before they go back to sleep. If some data needs to be transferred from a server node to the small device, it can be implemented by polling, i.e., the small node periodically polls for the server to see if it, for example, has some configuration changes or similar. While the device is sleeping, it will not maintain the IKEv2 SA. That is, it will always create the IKEv2 SA again when it wakes up. This means there is no need to do liveness checks for the server, as after the device wakes up again, the minimal implementation will start from the beginning again.
これらのデバイスは通常、長時間スリープ状態になり、定期的に、またはユーザーの操作によってのみウェイクアップします。データ転送は、スリープ解除したノードが起動したときに常に開始されます。パケットを送信した後、スリープ状態に戻る前にACKまたは他のパケットが戻ってくる可能性があります。一部のデータをサーバーノードから小さなデバイスに転送する必要がある場合は、ポーリングによって実装できます。つまり、小さなノードは定期的にサーバーをポーリングして、サーバーに構成の変更などがあるかどうかを確認します。デバイスがスリープしている間、IKEv2 SAは維持されません。つまり、ウェイクアップすると、IKEv2 SAが常に作成されます。つまり、デバイスが再びウェイクアップした後、最小限の実装が最初から再開されるため、サーバーの活性チェックを行う必要はありません。
All IKEv2 communications consist of pairs of messages: a request and a response. The pair is called an "exchange" and is sometimes called a "request/response pair". Every request requires a response.
すべてのIKEv2通信は、メッセージのペア（要求と応答）で構成されています。このペアは「交換」と呼ばれ、「要求/応答ペア」と呼ばれることもあります。すべてのリクエストには応答が必要です。
For every pair of IKEv2 messages, the initiator is responsible for retransmission in the event of a timeout. The responder MUST never retransmit a response unless it receives a retransmission of the request.
IKEv2メッセージのすべてのペアについて、タイムアウトの発生時にイニシエーターが再送信を担当します。応答側は、要求の再送信を受信しない限り、応答を再送信してはなりません（MUST）。
IKEv2 is a reliable protocol: the initiator MUST retransmit a request until it either receives a corresponding response or deems the IKE SA to have failed. A retransmission from the initiator MUST be bitwise identical to the original request. Retransmission times MUST increase exponentially.
IKEv2は信頼できるプロトコルです。対応する応答を受信するか、IKE SAが失敗したと見なすまで、イニシエーターは要求を再送信する必要があります。イニシエーターからの再送信は、元の要求とビットごとに同一である必要があります。再送信時間は指数関数的に増加する必要があります。
IKEv2 is run over UDP port 500. All IKEv2 implementations MUST be able to send, receive, and process IKEv2 messages that are up to 1280 octets long. An implementation MUST accept incoming requests even if the source port is not 500 and MUST respond to the address and port from which the request was received.
IKEv2はUDPポート500で実行されます。すべてのIKEv2実装は、最大1280オクテット長のIKEv2メッセージを送信、受信、および処理できる必要があります。ソースポートが500でなくても、実装は着信要求を受け入れなければならず、要求の受信元のアドレスとポートに応答しなければなりません（MUST）。
The minimal implementation of IKEv2 only uses the first two exchanges, called IKE_SA_INIT and IKE_AUTH. These are used to create the IKE SA and the first Child SA. In addition to those messages, a minimal IKEv2 implementation needs to understand the CREATE_CHILD_SA request enough to generate a CREATE_CHILD_SA response containing the NO_ADDITIONAL_SAS error notify. It needs to understand the INFORMATIONAL request enough to generate an empty INFORMATIONAL response to it. There is no requirement to be able to respond to any other requests.
IKEv2の最小限の実装では、IKE_SA_INITおよびIKE_AUTHと呼ばれる最初の2つの交換のみを使用します。これらは、IKE SAと最初の子SAを作成するために使用されます。これらのメッセージに加えて、最小限のIKEv2実装は、NO_ADDITIONAL_SASエラー通知を含むCREATE_CHILD_SA応答を生成するのに十分なCREATE_CHILD_SA要求を理解する必要があります。それは、それに対する空の情報応答を生成するのに十分な情報要求を理解する必要があります。他の要求に応答できる必要はありません。
All messages following the IKE_SA_INIT exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the IKE_SA_INIT exchange.
IKE_SA_INIT交換に続くすべてのメッセージは、IKE_SA_INIT交換でネゴシエートされた暗号化アルゴリズムとキーを使用して暗号的に保護されます。
Every IKEv2 message contains a Message ID as part of its fixed header. This Message ID is used to match up requests and responses and to identify retransmissions of messages.
すべてのIKEv2メッセージには、固定ヘッダーの一部としてメッセージIDが含まれています。このメッセージIDは、要求と応答を照合し、メッセージの再送信を識別するために使用されます。
Minimal implementations only need to support the role of initiator, so it typically only sends an IKE_SA_INIT request that, when answered, is followed by an IKE_AUTH. As those messages have fixed Message IDs (0 and 1), it does not need to keep track of its own Message IDs for outgoing requests after that.
最小限の実装では、イニシエーターの役割のみをサポートする必要があるため、通常、IKE_SA_INIT要求のみを送信し、応答すると、IKE_AUTHが後に続きます。これらのメッセージには固定メッセージID（0および1）があるため、その後の発信要求の独自のメッセージIDを追跡する必要はありません。
Minimal implementations can also optimize Message ID handling of the incoming requests, as they do not need to protect incoming requests against replays. This is possible because minimal implementations will only return error or empty notification replies to incoming requests. This means that any of those incoming requests do not have any effect on the minimal implementation, thus processing them again does not cause any harm. Because of this, a minimal implementation can always answer a request coming in, with the same Message ID than what the request had, and then forget the request/response pair immediately. This means there is no need to keep track of Message IDs of the incoming requests.
最小限の実装では、着信要求をリプレイから保護する必要がないため、着信要求のメッセージID処理を最適化することもできます。最小限の実装では、着信要求に対してエラーまたは空の通知応答のみが返されるため、これは可能です。これは、これらの着信要求のいずれも最小限の実装に影響を与えないことを意味します。したがって、それらを再度処理しても害はありません。このため、最小限の実装では、常に、入ってくるリクエストに、リクエストと同じメッセージIDで応答し、リクエストとレスポンスのペアをすぐに忘れることができます。つまり、着信要求のメッセージIDを追跡する必要はありません。
In the following descriptions, the payloads contained in the message are indicated by the names listed below.
以下の説明では、メッセージに含まれるペイロードは、以下の名前で示されています。
Notation Payload
-----------------------------------------
AUTH Authentication
CERTREQ Certificate Request
D Delete
HDR IKE header (not a payload)
IDi Identification - Initiator
IDr Identification - Responder
KE Key Exchange
Ni, Nr Nonce
N Notify
SA Security Association
SK Encrypted and Authenticated
TSi Traffic Selector - Initiator
TSr Traffic Selector - Responder
The initial exchanges are as follows:
最初の交換は次のとおりです。
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=0, IKE_SA_INIT,
Flags: Initiator, Message ID=0),
SAi1, KEi, Ni -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT,
Flags: Response, Message ID=0),
SAr1, KEr, Nr, [CERTREQ]
HDR contains the Security Parameter Indexes (SPIs), version numbers, and flags of various sorts. Each endpoint chooses one of the two SPIs and MUST choose them so as to be unique identifiers of an IKE SA. An SPI value of zero is special: it indicates that the remote SPI value is not yet known by the sender.
HDRには、セキュリティパラメータインデックス（SPI）、バージョン番号、さまざまな種類のフラグが含まれています。各エンドポイントは2つのSPIの1つを選択し、IKE SAの一意の識別子になるようにそれらを選択する必要があります。ゼロのSPI値は特別です。これは、リモートSPI値が送信者にまだ知られていないことを示します。
Incoming IKEv2 packets are mapped to an IKE SA using only the packet's SPI, not using (for example) the source IP address of the packet.
着信IKEv2パケットは、（たとえば）パケットの送信元IPアドレスを使用せずに、パケットのSPIのみを使用してIKE SAにマップされます。
The SAi1 payload states the cryptographic algorithms the initiator supports for the IKE SA. The KEi and KEr payloads contain Diffie-Hellman values, and Ni and Nr are the nonces. The SAr1 contains the chosen cryptographic suite from the initiator's offered choices. A minimal implementation using shared secrets will ignore the CERTREQ payload.
SAi1ペイロードは、イニシエーターがIKE SAに対してサポートする暗号化アルゴリズムを示します。 KEiおよびKErペイロードにはDiffie-Hellman値が含まれ、NiおよびNrはノンスです。 SAr1には、イニシエーターが提供する選択肢から選択された暗号スイートが含まれています。共有シークレットを使用した最小限の実装では、CERTREQペイロードは無視されます。
Minimal implementation will most likely support exactly one set of cryptographic algorithms, meaning the SAi1 payload will be static. It needs to check that the SAr1 received matches the proposal it sent.
最小限の実装では、おそらく1セットの暗号化アルゴリズムがサポートされます。つまり、SAi1ペイロードは静的になります。受信したSAr1が、送信した提案と一致することを確認する必要があります。
At this point in the negotiation, each party can generate SKEYSEED, from which all keys are derived for that IKE SA.
ネゴシエーションのこの時点で、各パーティはSKEYSEEDを生成でき、そこからすべてのキーがそのIKE SA用に導出されます。
SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
prf+ (K,S) = T1 | T2 | T3 | T4 | ...
prf +（K、C）= T1 | T2 | Tz |午後| ...
where: T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) ...
ここで：T1 = prf（K、S | 0x01）T2 = prf（K、T1 | S | 0x02）T3 = prf（K、T2 | S | 0x03）T4 = prf（K、T3 | S | 0x04）.. 。
(indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr are taken in order from the generated bits of the prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman exchange. g^ir is represented as a string of octets in big endian order padded with zeros if necessary to make it the length of the modulus. Ni and Nr are the nonces, stripped of any headers.
（数量SK_d、SK_ai、SK_ar、SK_ei、SK_er、SK_pi、およびSK_prは、prf +の生成されたビットから順番に取得されることを示します）。 g ^ irは、一時的なDiffie-Hellman交換からの共有秘密です。 g ^ irは、モジュラスの長さとするために必要に応じてゼロが埋め込まれたビッグエンディアン順のオクテットの文字列として表されます。 NiとNrはノンスであり、ヘッダーは削除されています。
The SK_d is used for deriving new keys for the Child SAs. The SK_ai and SK_ar are used as a key to the integrity protection algorithm for authenticating the component messages of subsequent exchanges. The SK_ei and SK_er are used for encrypting (and of course decrypting) all subsequent exchanges. The SK_pi and SK_pr are used when generating an AUTH payload. The lengths of SK_d, SK_pi, and SK_pr MUST be the preferred key length of the Pseudorandom Function (PRF) agreed upon.
SK_dは、子SAの新しいキーを導出するために使用されます。 SK_aiおよびSK_arは、後続の交換のコンポーネントメッセージを認証するための完全性保護アルゴリズムのキーとして使用されます。 SK_eiとSK_erは、後続のすべての交換の暗号化（およびもちろん復号化）に使用されます。 SK_piおよびSK_prは、AUTHペイロードの生成時に使用されます。 SK_d、SK_pi、およびSK_prの長さは、合意された疑似ランダム関数（PRF）の優先キーの長さである必要があります。
A separate SK_e and SK_a is computed for each direction. The keys used to protect messages from the original initiator are SK_ai and SK_ei. The keys used to protect messages in the other direction are SK_ar and SK_er. The notation SK { ... } indicates that these payloads are encrypted and integrity protected using that direction's SK_e and SK_a.
方向ごとに個別のSK_eおよびSK_aが計算されます。元のイニシエーターからメッセージを保護するために使用されるキーは、SK_aiおよびSK_eiです。逆方向のメッセージを保護するために使用されるキーは、SK_arおよびSK_erです。 SK {...}という表記は、これらのペイロードがその方向のSK_eおよびSK_aを使用して暗号化され、整合性が保護されていることを示します。
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1),
SK {IDi, AUTH, SAi2, TSi, TSr,
N(INITIAL_CONTACT)} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1),
SK {IDr, AUTH, SAr2, TSi, TSr}
The initiator asserts its identity with the IDi payload, proves knowledge of the secret corresponding to IDi, and integrity protects the contents of the first message using the AUTH payload. The responder asserts its identity with the IDr payload, authenticates its identity, and protects the integrity of the second message with the AUTH payload.
イニシエーターはIDiペイロードでそのIDをアサートし、IDiに対応する秘密の知識を証明し、整合性はAUTHペイロードを使用して最初のメッセージの内容を保護します。レスポンダはIDrペイロードを使用してIDをアサートし、IDを認証し、AUTHペイロードを使用して2番目のメッセージの整合性を保護します。
As minimal implementation usually has only one host where it connects, that means it has only one shared secret. This means it does not need to care about the IDr payload that much. If the other end sends an AUTH payload that the initiator can verify using the shared secret it has, then it knows the other end is the peer it was configured to talk to.
最小限の実装では通常、接続先のホストは1つだけであるため、共有シークレットは1つしかありません。これは、IDrペイロードをそれほど気にする必要がないことを意味します。相手側がAUTHペイロードを送信した場合、イニシエーターは所有している共有シークレットを使用して検証できるので、相手側が通信するように構成されたピアであることがわかります。
In the IKE_AUTH request, the initiator sends the SA offer(s) in the SAi2 payload and the proposed Traffic Selectors (TSs) for the Child SA in the TSi and TSr payloads. The responder replies with the accepted offer in an SAr2 payload and with the selected Traffic Selectors. The selected Traffic Selectors may be a subset of what the initiator proposed.
IKE_AUTH要求では、イニシエーターはSAi2ペイロードでSAオファーを送信し、TSiペイロードとTSrペイロードで子SAに提案されたトラフィックセレクター（TS）を送信します。レスポンダは、SAr2ペイロードで受け入れられたオファーと、選択されたトラフィックセレクタで応答します。選択されたトラフィックセレクターは、イニシエーターが提案したもののサブセットである場合があります。
In the minimal implementation, both SA payloads and TS payloads are going to be mostly static. The SA payload will have the SPI value used in the Encapsulating Security Payload (ESP), but the algorithms are most likely going to be the one and only supported set. The TS payloads on the initiator end will most likely say from any to any, i.e., full wildcard ranges, or from the local IP to the remote IP. In the wildcard case, the responder quite often narrows the range down to the one IP address pair. Using a single IP address pair as the Traffic Selectors when sending the IKE_AUTH request will simplify processing as the responder will either accept the IP address pair or return an error. If wildcard ranges are used, there is a possibility that the responder will narrow the Traffic Selector range to range that is not acceptable by the initiator.
最小限の実装では、SAペイロードとTSペイロードの両方がほとんど静的になります。 SAペイロードには、カプセル化セキュリティペイロード（ESP）で使用されるSPI値が含まれますが、アルゴリズムは、サポートされる唯一の唯一のセットとなる可能性があります。イニシエーター側のTSペイロードは、ほとんどすべてのワイルドカード範囲、つまりローカルIPからリモートIPへのすべてのワイルドカードを指します。ワイルドカードの場合、レスポンダーはしばしば1つのIPアドレスのペアに範囲を絞り込みます。 IKE_AUTH要求を送信するときにトラフィックセレクターとして単一のIPアドレスペアを使用すると、レスポンダがIPアドレスペアを受け入れるか、エラーを返すため、処理が簡単になります。ワイルドカードの範囲が使用されている場合、レスポンダがトラフィックセレクタの範囲を、イニシエータが受け入れられない範囲に狭める可能性があります。
The IKE_AUTH (and IKE_SA_INIT) response may contain multiple status notification payloads that can be ignored by minimal implementations.
IKE_AUTH（およびIKE_SA_INIT）応答には、最小限の実装では無視できる複数のステータス通知ペイロードが含まれている場合があります。
There can also be Vendor ID, Certificate, Certificate Request, or Configuration payloads, but any payload unknown to minimal implementations can simply be skipped over (response messages cannot have critical unsupported payloads).
ベンダーID、証明書、証明書要求、または構成のペイロードも存在しますが、最小限の実装では不明なペイロードは単にスキップできます（応答メッセージにサポートされていない重要なペイロードを含めることはできません）。
The exchange above includes N(INITIAL_CONTACT) notification in the request as that is quite commonly sent by a minimal implementation. It indicates to the other end that the initiator does not have any other IKE SAs between it and the responder, and if there is any left from previous runs, those can be deleted by the responder. As minimal implementations delete IKE SAs without sending IKE SA delete requests, this will help the responder to clean up leftover state.
上記の交換では、リクエストにN（INITIAL_CONTACT）通知が含まれています。これは、最小限の実装で送信されることが非常に多いためです。イニシエータには、それとレスポンダの間に他のIKE SAがないことを相手側に示します。以前の実行から残っているものがある場合、それらはレスポンダによって削除できます。最小限の実装では、IKE SA削除要求を送信せずにIKE SAを削除するため、レスポンダーが残りの状態をクリーンアップするのに役立ちます。
When using shared secret authentication, the peers are authenticated by having each calculating a Message Authentication Code (MAC) over a block of data:
共有シークレット認証を使用する場合、ピアは、データブロックに対してメッセージ認証コード（MAC）をそれぞれ計算することによって認証されます。
For the initiator:
AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
<InitiatorSignedOctets>)
For the responder:
AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
<ResponderSignedOctets>)
The string "Key Pad for IKEv2" is 17 ASCII characters without null termination. The implementation can precalculate the inner prf and only store the output of it. This is possible because a minimal IKEv2 implementation usually only supports one PRF.
文字列「IKEv2のキーパッド」は、ヌルで終了しない17個のASCII文字です。実装では、内部prfを事前に計算し、その出力のみを保存できます。最小限のIKEv2実装は通常、1つのPRFのみをサポートするため、これは可能です。
In the following calculations, IDi' and IDr' are the entire ID payloads excluding the fixed header, and the Ni and Nr are only the values, not the payloads containing it. Note that neither the nonce Ni/Nr nor the value prf(SK_pr, IDr')/prf(SK_pi, IDi') are transmitted.
次の計算では、IDi 'とIDr'は固定ヘッダーを除くIDペイロード全体であり、NiとNrは値のみであり、それを含むペイロードではありません。ノンスNi / Nrも値prf（SK_pr、IDr '）/ prf（SK_pi、IDi'）も送信されないことに注意してください。
The initiator signs the first message (IKE_SA_INIT request), starting with the first octet of the first SPI in the header and ending with the last octet of the last payload in that first message. Appended to this (for purposes of computing the signature) are the responder's nonce Nr and the value prf(SK_pi, IDi').
イニシエーターは、ヘッダーの最初のSPIの最初のオクテットで始まり、最初のメッセージの最後のペイロードの最後のオクテットで終わる最初のメッセージ（IKE_SA_INIT要求）に署名します。これに（署名を計算する目的で）追加されるのは、レスポンダーのノンスNrと値prf（SK_pi、IDi '）です。
For the responder, the octets to be signed start with the first octet of the first SPI in the header of the second message (IKE_SA_INIT response) and end with the last octet of the last payload in that second message. Appended to this are the initiator's nonce Ni and the value prf(SK_pr, IDr').
レスポンダの場合、署名されるオクテットは、2番目のメッセージのヘッダーの最初のSPIの最初のオクテット（IKE_SA_INIT応答）で始まり、2番目のメッセージの最後のペイロードの最後のオクテットで終わります。これに追加されるのは、イニシエーターのノンスNiと値prf（SK_pr、IDr '）です。
The initiator's signed octets can be described as:
イニシエーターの署名付きオクテットは、次のように説明できます。
InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage1 = RealIKEHDR | RestOfMessage1 NonceRPayload = PayloadHeader | NonceRData InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload RestOfInitIDPayload = IDType | RESERVED | InitIDData MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI RealIKEHDR = SPIi | SPIr | 。 。 。 |長さRealMessage1 = RealIKEHDR | RestOfMessage1 NonceRPayload = PayloadHeader | NonceRData InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload RestOfInitIDPayload = IDType |予約済み| InitIDData MACedIDForI = prf（SK_pi、RestOfInitIDPayload）
The responder's signed octets can be described as:
レスポンダの署名付きオクテットは、次のように説明できます。
ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage2 = RealIKEHDR | RestOfMessage2 NonceIPayload = PayloadHeader | NonceIData ResponderIDPayload = PayloadHeader | RestOfRespIDPayload RestOfRespIDPayload = IDType | RESERVED | RespIDData MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR RealIKEHDR = SPIi | SPIr | 。 。 。 |長さRealMessage2 = RealIKEHDR | RestOfMessage2 NonceIPayload = PayloadHeader | NonceIData ResponderIDPayload = PayloadHeader | RestOfRespIDPayload RestOfRespIDPayload = IDType |予約済み| RespIDData MACedIDForR = prf（SK_pr、RestOfRespIDPayload）
Note that all of the payloads inside the RestOfMessageX are included under the signature, including any payload types not listed in this document.
RestOfMessageX内のすべてのペイロードは、このドキュメントにリストされていないペイロードタイプを含め、署名の下に含まれていることに注意してください。
The initiator might also get an unauthenticated response back that has a notification payload with an error code inside. As that error code will be unauthenticated and may be faked, there is no need to do anything for those. A minimal implementation can simply ignore those errors and retransmit its request until it times out, and if that happens, then the IKE SA (and Child SA) creation failed.
イニシエーターは、内部にエラーコードを含む通知ペイロードを持つ未認証の応答を返すこともあります。そのエラーコードは認証されておらず、偽造されている可能性があるため、それらに対して何もする必要はありません。最小限の実装では、これらのエラーを無視して、タイムアウトになるまでリクエストを再送信できます。その場合、IKE SA（および子SA）の作成は失敗します。
The responder might also reply with an IKE_AUTH response packet that does not contain the payloads needed to set up a Child SA (SAr2, TSi, and TSr) but instead contain AUTH payload and an error. Minimal implementation that does not support the CREATE_CHILD_SA exchange cannot recover from this scenario. It can delete the IKE SA and start over from the beginning (which might fail again if this is a configuration error, or it might succeed if this was temporal failure).
レスポンダは、子SA（SAr2、TSi、およびTSr）のセットアップに必要なペイロードを含まず、代わりにAUTHペイロードとエラーを含むIKE_AUTH応答パケットで応答する場合もあります。 CREATE_CHILD_SA交換をサポートしない最小限の実装では、このシナリオから回復できません。 IKE SAを削除して、最初からやり直すことができます（これが構成エラーの場合は失敗する可能性があり、一時的な障害の場合は成功する可能性があります）。
Minimal implementations MUST be able to reply to INFORMATIONAL requests by sending back an empty INFORMATIONAL response:
最小限の実装は、空のINFORMATIONAL応答を送り返すことにより、INFORMATIONAL要求に応答できなければなりません（MUST）。
Minimal implementation Other end
-------------------------------------------------------------------
<-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: none, Message ID=m),
SK {...}
HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Initiator | Response,
Message ID=m),
SK {} -->
Minimal implementations MUST be able to reply to incoming CREATE_CHILD_SA requests. A typical implementation will reject the CREATE_CHILD_SA exchanges by sending a NO_ADDITIONAL_SAS error notify back:
最小限の実装は、着信するCREATE_CHILD_SA要求に応答できる必要があります。典型的な実装は、NO_ADDITIONAL_SASエラー通知を送り返すことにより、CREATE_CHILD_SA交換を拒否します。
Minimal implementation Other end
-------------------------------------------------------------------
<-- HDR(SPIi=xxx, SPIy=yyy, CREATE_CHILD_SA,
Flags: none, Message ID=m),
SK {...}
HDR(SPIi=xxx, SPIr=yyy, CREATE_CHILD_SA,
Flags: Initiator | Response, Message ID=m),
SK {N(NO_ADDITIONAL_SAS)} -->
Note that INFORMATIONAL and CREATE_CHILD_SA requests might contain unsupported critical payloads, in which case a compliant implementation MUST ignore the request and send a response message back that has the UNSUPPORTED_CRITICAL_PAYLOAD notification. That notification payload data contains a 1-octet payload type of the unsupported critical payload.
INFORMATIONALおよびCREATE_CHILD_SAリクエストには、サポートされていない重要なペイロードが含まれている可能性があることに注意してください。その通知ペイロードデータには、サポートされていないクリティカルペイロードの1オクテットペイロードタイプが含まれています。
The keying material for the Child SA created by the IKE_AUTH exchange is generated as follows:
IKE_AUTH交換によって作成された子SAのキー情報は、次のように生成されます。
KEYMAT = prf+(SK_d, Ni | Nr)
KEYMAT = prf +（SK_d、Ni | Nr）
Where Ni and Nr are the nonces from the IKE_SA_INIT exchange.
ここで、NiとNrはIKE_SA_INIT交換からのノンスです。
A single CHILD_SA negotiation may result in multiple Security Associations. ESP and Authentication Header (AH) SAs exist in pairs (one in each direction), so two SAs are created in a single Child SA negotiation for them. The keying material for each Child SA MUST be taken from the expanded KEYMAT using the following rules:
1つのCHILD_SAネゴシエーションにより、複数のセキュリティアソシエーションが発生する場合があります。 ESPと認証ヘッダー（AH）SAはペアで（各方向に1つずつ）存在するため、2つのSAが1つの子SAネゴシエーションで作成されます。各子SAのキー情報は、次のルールを使用して、拡張されたKEYMATから取得する必要があります。
o All keys for SAs carrying data from the initiator to the responder are taken before SAs going from the responder to the initiator.
o イニシエーターからレスポンダーにデータを運ぶSAのすべてのキーは、SAがレスポンダーからイニシエーターに行く前に取得されます。
o If an IPsec protocol requires multiple keys, the order in which they are taken from the SA's keying material needs to be described in the protocol's specification. For ESP and AH, [IPSECARCH] defines the order, namely: the encryption key (if any) MUST be taken from the first bits, and the integrity key (if any) MUST be taken from the remaining bits.
o IPsecプロトコルが複数のキーを必要とする場合、SAのキー情報からキーを取得する順序をプロトコルの仕様に記述する必要があります。 ESPおよびAHの場合、[IPSECARCH]は順序を定義します。つまり、暗号化キー（存在する場合）は最初のビットから取得する必要があり、整合性キー（存在する場合）は残りのビットから取得する必要があります。
Each cryptographic algorithm takes a fixed number of bits of keying material specified as part of the algorithm or negotiated in SA payloads.
各暗号化アルゴリズムは、アルゴリズムの一部として指定された、またはSAペイロードでネゴシエートされたキーイングマテリアルの固定ビット数を取ります。
For an implementation to be called conforming to the RFC 7296 specification, it MUST be possible to configure it to accept the following:
RFC 7296仕様に準拠して呼び出される実装では、以下を受け入れるように構成を設定できる必要があります。
o Public Key Infrastructure using X.509 (PKIX) Certificates containing and signed by RSA keys of size 1024 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or ID_DER_ASN1_DN.
o X.509（PKIX）証明書を使用する公開鍵インフラストラクチャ。サイズが1024または2048ビットのRSA鍵を含み、RSA鍵で署名されます。渡されるIDは、ID_KEY_ID、ID_FQDN、ID_RFC822_ADDR、またはID_DER_ASN1_DNのいずれかです。
o Shared key authentication where the ID passed is any of ID_KEY_ID, ID_FQDN, or ID_RFC822_ADDR.
o 渡されるIDの共有キー認証は、ID_KEY_ID、ID_FQDN、またはID_RFC822_ADDRのいずれかです。
o Authentication where the responder is authenticated using PKIX Certificates, and the initiator is authenticated using shared key authentication.
o レスポンダがPKIX証明書を使用して認証され、イニシエータが共有キー認証を使用して認証される認証。
This document only supports the second bullet; it does not support PKIX Certificates at all. As full RFC 7296 responders must also support that shared key authentication, this allows a minimal implementation to be able to interoperate with all implementations that are compliant with RFC 7296.
このドキュメントは2番目の箇条書きのみをサポートしています。 PKIX証明書はまったくサポートされていません。完全なRFC 7296レスポンダはその共有キー認証もサポートする必要があるため、最小限の実装でRFC 7296に準拠するすべての実装と相互運用できるようになります。
PKIX Certificates are left out from the minimal implementation as those would add quite a lot of complexity to the implementation. The actual code changes needed in the IKEv2 protocol are small, but the certificate validation code would be more complex than the whole minimal IKEv2 implementation itself. If public-key-based authentication is needed for scalability reasons, then raw public keys would probably be the best compromise (see Appendix B.2).
PKIX証明書は、実装をかなり複雑にするため、最小限の実装から除外されています。 IKEv2プロトコルで必要な実際のコード変更はわずかですが、証明書検証コードは、最小限のIKEv2実装自体全体よりも複雑になります。スケーラビリティの理由で公開鍵ベースの認証が必要な場合、生の公開鍵がおそらく最良の妥協案です（付録B.2を参照）。
This document describes a minimal implementation written by the author of this document. The minimal implementation supported the base IKE_SA_INIT and IKE_AUTH exchanges and successfully interoperated with a full IKEv2 server. This minimal implementation was presented in the Interconnecting Smart Objects with Internet Workshop in Prague in March 2011 [Kiv11]. This implementation was written as proof of concept in perl.
このドキュメントでは、このドキュメントの作成者が作成した最小限の実装について説明します。最小限の実装は、基本的なIKE_SA_INITおよびIKE_AUTH交換をサポートし、完全なIKEv2サーバーと正常に相互運用しました。この最小限の実装は、2011年3月にプラハで開催されたインターネットワークショップによるスマートオブジェクトの相互接続[Kiv11]で発表されました。この実装は、perlの概念実証として書かれました。
There was another proof-of-concept implementation written in python, which also interoperated with a full IKEv2 server.
完全なIKEv2サーバーと相互運用する、Pythonで記述された別の概念実証実装がありました。
Both implementations were written just for demonstration purposes and included fixed configuration built into the code, and both also implemented ESP, ICMP, and IP layers to the level that was needed to send and receive one ICMP echo packet. Both implementations were about 1000 lines of code excluding cryptographic libraries but including ESP, ICMP, and IP layers.
どちらの実装も、デモンストレーションのみを目的として作成され、コードに組み込まれた固定構成を含み、1つのICMPエコーパケットの送受信に必要なレベルまでESP、ICMP、およびIPレイヤーも実装しました。どちらの実装も、暗号ライブラリを除いてESP、ICMP、およびIP層を含む約1000行のコードでした。
As this implements the same protocol as RFC 7296, this means all security considerations from it also apply to this document.
これはRFC 7296と同じプロトコルを実装するため、これからのすべてのセキュリティの考慮事項がこのドキュメントにも適用されることを意味します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<http://www.rfc-editor.org/info/rfc7296>。
[EAI] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <http://www.rfc-editor.org/info/rfc6532>.
[EAI] Yang、A.、Steele、S。、およびN. Freed、「Internationalized Email Headers」、RFC 6532、DOI 10.17487 / RFC6532、2012年2月、<http://www.rfc-editor.org/info/ rfc6532>。
[IDNA] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[IDNA] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<http://www.rfc-editor.org/info/ rfc5890>。
[IKEV2IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org/assignments/ikev2-parameters>.
[IKEV2IANA] IANA、「Internet Key Exchange Version 2（IKEv2）Parameters」、<http://www.iana.org/assignments/ikev2-parameters>。
[IPSEARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[IPSEARCH] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[Kiv11] Kivinen, T., "Interconnecting Smart Objects with Internet Workshop 2011-03025; IKEv2 and Smart Objects", March 2011, <https://www.iab.org/wp-content/IAB-uploads/2011/04/ Kivinen.pdf>.
[Kiv11] Kivinen、T。、「Interconnecting Smart Objects with Internet Workshop 2011-03025; IKEv2 and Smart Objects」、2011年3月、<https://www.iab.org/wp-content/IAB-uploads/2011/04 / Kivinen.pdf>。
[MODES] National Institute of Standards and Technology, U.S. Department of Commerce, "Recommendation for Block Cipher Modes of Operation", SP 800-38A, 2001.
[モード]国立標準技術研究所、米国商務省、「ブロック暗号モードの運用に関する推奨事項」、SP 800-38A、2001年。
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.
[PKCS1] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 2.1」、RFC 3447、DOI 10.17487 / RFC3447、2003年2月、<http：//www.rfc -editor.org/info/rfc3447>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<http://www.rfc-editor.org/info/rfc5322>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、DOI 10.17487 / RFC7228、May 2014、<http://www.rfc-editor.org / info / rfc7228>。
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, <http://www.rfc-editor.org/info/rfc7619>.
[RFC7619] Smyslov、V。およびP. Wouters、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）のNULL認証方式」、RFC 7619、DOI 10.17487 / RFC7619、2015年8月、<http：//www.rfc- editor.org/info/rfc7619>。
[RFC7670] Kivinen, T., Wouters, P., and H. Tschofenig, "Generic Raw Public-Key Support for IKEv2", RFC 7670, DOI 10.17487/RFC7670, January 2016, <http://www.rfc-editor.org/info/rfc7670>.
[RFC7670] Kivinen、T.、Wouters、P。、およびH. Tschofenig、「Generic Raw Public-Key Support for IKEv2」、RFC 7670、DOI 10.17487 / RFC7670、2016年1月、<http：//www.rfc-editor .org / info / rfc7670>。
This appendix describes actual packet payload formats. This is required to make the document self-contained. The descriptions are mostly copied from RFC 7296, and more information can be found from there.
この付録では、実際のパケットペイロード形式について説明します。これは、ドキュメントを自己完結型にするために必要です。説明はほとんどRFC 7296からコピーされたものであり、そこから詳細情報を見つけることができます。
Various payloads contain RESERVED fields, and those MUST be sent as zero and MUST be ignored on receipt.
さまざまなペイロードにはRESERVEDフィールドが含まれており、それらはゼロとして送信する必要があり、受信時に無視する必要があります。
All multi-octet fields representing integers are laid out in big endian order (also known as "most significant byte first" or "network byte order").
整数を表すすべてのマルチオクテットフィールドは、ビッグエンディアン順（「最上位バイトファースト」または「ネットワークバイトオーダー」とも呼ばれます）でレイアウトされます。
Each IKEv2 message begins with the IKE header, denoted HDR in this document. Following the header are one or more IKE payloads each identified by a Next Payload field in the preceding payload. Payloads are identified in the order in which they appear in an IKE message by looking in the Next Payload field in the IKE header and, subsequently, according to the Next Payload field in the IKE payload itself until a Next Payload field of zero indicates that no payloads follow. If a payload of type "Encrypted" is found, that payload is decrypted and its contents parsed as additional payloads. An Encrypted payload MUST be the last payload in a packet, and an Encrypted payload MUST NOT contain another Encrypted payload.
各IKEv2メッセージは、このドキュメントではHDRと表記されているIKEヘッダーで始まります。ヘッダーの後には、1つ以上のIKEペイロードが続き、それぞれが前のペイロードのNext Payloadフィールドで識別されます。ペイロードは、IKEヘッダーのNext Payloadフィールドを調べ、その後、IKEペイロード自体のNext Payloadフィールドに従って、ゼロのNext Payloadフィールドがゼロであることを示すまで、IKEメッセージに表示される順序で識別されます。ペイロードが続きます。タイプ「暗号化」のペイロードが見つかった場合、そのペイロードは復号化され、そのコンテンツは追加のペイロードとして解析されます。暗号化されたペイロードはパケットの最後のペイロードでなければならず、暗号化されたペイロードは別の暗号化されたペイロードを含んではいけません（MUST NOT）。
The format of the IKE header is shown in Figure 1.
IKEヘッダーのフォーマットを図1に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE SA Initiator's SPI |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE SA Responder's SPI |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | MjVer | MnVer | Exchange Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IKE Header Format
図1：IKEヘッダーの形式
o Initiator's SPI (8 octets) - A value chosen by the initiator to identify a unique IKE Security Association. This value MUST NOT be zero.
o イニシエーターのSPI（8オクテット）-一意のIKEセキュリティアソシエーションを識別するためにイニシエーターによって選択された値。この値はゼロであってはなりません。
o Responder's SPI (8 octets) - A value chosen by the responder to identify a unique IKE Security Association. This value MUST be zero in the first message of an IKE initial exchange.
o レスポンダのSPI（8オクテット）-一意のIKE Security Associationを識別するためにレスポンダによって選択された値。この値は、IKE初期交換の最初のメッセージでゼロでなければなりません。
o Next Payload (1 octet) - Indicates the type of payload that immediately follows the header. The format and value of each payload are defined below.
o 次のペイロード（1オクテット）-ヘッダーの直後に続くペイロードのタイプを示します。各ペイロードのフォーマットと値は以下に定義されています。
o Major Version (4 bits) - Indicates the major version of the IKE protocol in use. Implementations based on this version of IKE MUST set the major version to 2 and MUST drop the messages with a higher major version number.
o メジャーバージョン（4ビット）-使用中のIKEプロトコルのメジャーバージョンを示します。このバージョンのIKEに基づく実装では、メジャーバージョンを2に設定する必要があり、より高いメジャーバージョン番号を持つメッセージをドロップする必要があります。
o Minor Version (4 bits) - Indicates the minor version of the IKE protocol in use. Implementations based on this version of IKE MUST set the minor version to zero. They MUST ignore the minor version number of received messages.
o マイナーバージョン（4ビット）-使用中のIKEプロトコルのマイナーバージョンを示します。このバージョンのIKEに基づく実装では、マイナーバージョンをゼロに設定する必要があります。受信したメッセージのマイナーバージョン番号を無視する必要があります。
o Exchange Type (1 octet) - Indicates the type of exchange being used. This constrains the payloads sent in each message in an exchange.
o 交換タイプ（1オクテット）-使用されている交換のタイプを示します。これにより、交換で各メッセージで送信されるペイロードが制限されます。
Exchange Type Value
----------------------------------
IKE_SA_INIT 34
IKE_AUTH 35
CREATE_CHILD_SA 36
INFORMATIONAL 37
o Flags (1 octet) - Indicates specific options that are set for the message. Presence of options is indicated by the appropriate bit in the flags field being set. The bits are as follows:
o フラグ（1オクテット）-メッセージに設定されている特定のオプションを示します。オプションの存在は、設定されているフラグフィールドの適切なビットによって示されます。ビットは次のとおりです。
+-+-+-+-+-+-+-+-+
|X|X|R|V|I|X|X|X|
+-+-+-+-+-+-+-+-+
In the description below, a bit being 'set' means its value is '1', while 'cleared' means its value is '0'. 'X' bits MUST be cleared when sending and MUST be ignored on receipt.
以下の説明では、「セット」されているビットはその値が「1」であることを意味し、「クリア」はその値が「0」であることを意味します。 「X」ビットは送信時にクリアする必要があり、受信時には無視する必要があります。
* R (Response) - This bit indicates that this message is a response to a message containing the same Message ID. This bit MUST be cleared in all request messages and MUST be set in all responses. An IKEv2 endpoint MUST NOT generate a response to a message that is marked as being a response.
* R（応答）-このビットは、このメッセージが同じメッセージIDを含むメッセージへの応答であることを示します。このビットは、すべての要求メッセージでクリアする必要があり、すべての応答で設定する必要があります。 IKEv2エンドポイントは、応答としてマークされているメッセージへの応答を生成してはなりません（MUST NOT）。
* V (Version) - This bit indicates that the transmitter is capable of speaking a higher major version number of the protocol than the one indicated in the Major Version field. Implementations of IKEv2 MUST clear this bit when sending and MUST ignore it in incoming messages.
* V（バージョン）-このビットは、トランスミッタが、メジャーバージョンフィールドに示されているものよりも高いプロトコルのメジャーバージョン番号を読み込めることを示します。 IKEv2の実装では、送信時にこのビットをクリアする必要があり、受信メッセージでは無視する必要があります。
* I (Initiator) - This bit MUST be set in messages sent by the original initiator of the IKE SA and MUST be cleared in messages sent by the original responder. It is used by the recipient to determine which 8 octets of the SPI were generated by the recipient. This bit changes to reflect who initiated the last rekey of the IKE SA.
* I（イニシエーター）-このビットは、IKE SAの元のイニシエーターが送信したメッセージで設定する必要があり、元のレスポンダーが送信したメッセージでクリアする必要があります。これは、受信者が生成したSPIの8オクテットを決定するために使用されます。このビットは、IKE SAの最後のキー再生成を誰が開始したかを反映するように変更されます。
o Message ID (4 octets, unsigned integer) - Message identifier used to control retransmission of lost packets and matching of requests and responses. It is essential to the security of the protocol because it is used to prevent message replay attacks.
o メッセージID（4オクテット、符号なし整数）-失われたパケットの再送信および要求と応答のマッチングを制御するために使用されるメッセージID。メッセージ再生攻撃を防ぐために使用されるため、プロトコルのセキュリティに不可欠です。
o Length (4 octets, unsigned integer) - Length of the total message (header + payloads) in octets.
o 長さ（4オクテット、符号なし整数）-オクテット単位の合計メッセージ（ヘッダー+ペイロード）の長さ。
Each IKE payload begins with a generic payload header, as shown in Figure 2. Figures for each payload below will include the generic payload header, but for brevity, the description of each field will be omitted.
図2に示すように、各IKEペイロードは一般的なペイロードヘッダーで始まります。以下の各ペイロードの図には一般的なペイロードヘッダーが含まれていますが、簡潔にするために、各フィールドの説明は省略されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Generic Payload Header
図2：汎用ペイロードヘッダー
The Generic Payload Header fields are defined as follows:
Generic Payload Headerフィールドは次のように定義されています。
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be zero. This field provides a "chaining" capability whereby additional payloads can be added to a message by appending each one to the end of the message and setting the Next Payload field of the preceding payload to indicate the new payload's type. An Encrypted payload, which must always be the last payload of a message, is an exception. It contains data structures in the format of additional payloads. In the header of an Encrypted payload, the Next Payload field is set to the payload type of the first contained payload (instead of zero); conversely, the Next Payload field of the last contained payload is set to zero). The payload type values needed for minimal implementations are listed here.
o 次のペイロード（1オクテット）-メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドはゼロになります。このフィールドは「チェーン」機能を提供します。これにより、メッセージの末尾にペイロードを追加し、前のペイロードのNext Payloadフィールドを設定して新しいペイロードのタイプを示すことにより、ペイロードをメッセージに追加できます。常にメッセージの最後のペイロードでなければならない暗号化されたペイロードは例外です。追加のペイロードの形式でデータ構造が含まれています。暗号化されたペイロードのヘッダーでは、Next Payloadフィールドは最初に含まれているペイロードのペイロードタイプに設定されます（ゼロではありません）。逆に、最後に含まれたペイロードのNext Payloadフィールドはゼロに設定されます）。最小限の実装に必要なペイロードタイプの値を以下に示します。
Next Payload Type Notation Value
--------------------------------------------------
No Next Payload 0
Security Association SA 33
Key Exchange KE 34
Identification - Initiator IDi 35
Identification - Responder IDr 36
Certificate CERT 37
Certificate Request CERTREQ 38
Authentication AUTH 39
Nonce Ni, Nr 40
Notify N 41
Delete D 42
Traffic Selector - Initiator TSi 44
Traffic Selector - Responder TSr 45
Encrypted and Authenticated SK 46
o Critical (1 bit) - MUST be set to zero if the sender wants the recipient to skip this payload if it does not understand the payload type code in the Next Payload field of the previous payload. MUST be set to 1 if the sender wants the recipient to reject this entire message if it does not understand the payload type. MUST be ignored by the recipient if the recipient understands the payload type code. MUST be set to zero for payload types defined in this document. Note that the critical bit applies to the current payload rather than the "next" payload whose type code appears in the first octet.
o クリティカル（1ビット）-送信者が前のペイロードのNext Payloadフィールドのペイロードタイプコードを理解できない場合、受信者がこのペイロードをスキップすることを希望する場合は、ゼロに設定する必要があります。ペイロードタイプを理解していない場合に、送信者が受信者にこのメッセージ全体を拒否することを要求する場合は、1に設定する必要があります。受信者がペイロードタイプコードを理解している場合、受信者は無視する必要があります。このドキュメントで定義されているペイロードタイプについては、ゼロに設定する必要があります。クリティカルビットは、タイプコードが最初のオクテットに現れる「次の」ペイロードではなく、現在のペイロードに適用されることに注意してください。
o Payload Length (2 octets, unsigned integer) - Length in octets of the current payload, including the generic payload header.
o ペイロード長（2オクテット、符号なし整数）-汎用ペイロードヘッダーを含む現在のペイロードの長さ（オクテット）。
The Security Association payload, denoted SA in this document, is used to negotiate attributes of a Security Association.
このドキュメントではSAと示されているセキュリティアソシエーションペイロードは、セキュリティアソシエーションの属性をネゴシエートするために使用されます。
An SA payload consists of one or more proposals. Each proposal includes one protocol. Each protocol contains one or more transforms -- each specifying a cryptographic algorithm. Each transform contains zero or more attributes (attributes are needed only if the Transform ID does not completely specify the cryptographic algorithm; currently, the only attribute is the Key Length attribute for variable-length ciphers, meaning there is exactly zero or one attribute).
SAペイロードは、1つ以上の提案で構成されています。各提案には1つのプロトコルが含まれています。各プロトコルには、1つ以上の変換が含まれています。それぞれが暗号アルゴリズムを指定しています。各変換には、0個以上の属性が含まれます（属性は、変換IDが暗号アルゴリズムを完全に指定していない場合にのみ必要です。現在、唯一の属性は可変長暗号のキー長属性です。つまり、属性は0個または1個のみです）。
The responder MUST choose a single suite, which may be any subset of the SA proposal following the rules below.
レスポンダは単一のスイートを選択する必要があります。これは、以下のルールに従うSA提案の任意のサブセットである場合があります。
Each proposal contains one protocol. If a proposal is accepted, the SA response MUST contain the same protocol. Each IPsec protocol proposal contains one or more transforms. Each transform contains a Transform Type. The accepted cryptographic suite MUST contain exactly one transform of each type included in the proposal. For example: if an ESP proposal includes transforms ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six combinations are acceptable.
各提案には1つのプロトコルが含まれています。プロポーザルが受け入れられる場合、SA応答には同じプロトコルが含まれている必要があります。各IPsecプロトコルの提案には、1つ以上の変換が含まれています。各変換には、変換タイプが含まれています。承認された暗号スイートには、提案に含まれる各タイプの変換を1つだけ含める必要があります。例：ESPプロポーザルにトランスフォームENCR_3DES、ENCR_AES w / keysize 128、ENCR_AES w / keysize 256、AUTH_HMAC_MD5、およびAUTH_HMAC_SHAが含まれている場合、承認されたスイートにはENCR_トランスフォームの1つとAUTH_トランスフォームの1つが含まれている必要があります。したがって、6つの組み合わせが許容されます。
Minimal implementation can create very simple SA proposal, i.e., include one proposal, which contains exactly one transform for each Transform Type. It is important to only include one Diffie-Hellman group in the proposal, so there is no need to do INVALID_KE_PAYLOAD processing in responses.
最小限の実装で、非常に単純なSAプロポーザルを作成できます。つまり、1つのプロポーザルを含めることができます。これには、各トランスフォームタイプに対して1つのトランスフォームが含まれます。プロポーザルにはDiffie-Hellmanグループを1つだけ含めることが重要です。そのため、応答でINVALID_KE_PAYLOAD処理を行う必要はありません。
When parsing an SA, an implementation MUST check that the total Payload Length is consistent with the payload's internal lengths and counts. Proposals, Transforms, and Attributes each have their own variable-length encodings. They are nested such that the Payload Length of an SA includes the combined contents of the SA, Proposal, Transform, and Attribute information. The length of a Proposal includes the lengths of all Transforms and Attributes it contains. The length of a Transform includes the lengths of all Attributes it contains.
SAを解析するとき、実装は、ペイロードの長さの合計がペイロードの内部の長さと数と一致していることを確認する必要があります。プロポーザル、変換、および属性には、それぞれ独自の可変長エンコーディングがあります。それらは、SAのペイロード長にSA、提案、変換、および属性情報の結合された内容が含まれるようにネストされます。プロポーザルの長さには、プロポーザルに含まれるすべての変換と属性の長さが含まれます。トランスフォームの長さには、トランスフォームに含まれるすべての属性の長さが含まれます。
Each Proposal/Protocol structure is followed by one or more transform structures. The number of different transforms is generally determined by the Protocol. AH generally has two transforms: Extended Sequence Numbers (ESNs) and an integrity check algorithm.
各Proposal / Protocol構造の後には、1つ以上の変換構造が続きます。異なる変換の数は、一般的にプロトコルによって決定されます。 AHには通常、拡張シーケンス番号（ESN）と整合性チェックアルゴリズムの2つの変換があります。
ESP generally has three: ESN, an encryption algorithm, and an integrity check algorithm. IKEv2 generally has four transforms: a Diffie-Hellman group, an integrity check algorithm, a PRF algorithm, and an encryption algorithm. For each Protocol, the set of permissible transforms is assigned Transform ID numbers, which appear in the header of each transform.
ESPには通常、ESN、暗号化アルゴリズム、および整合性チェックアルゴリズムの3つがあります。 IKEv2には通常、4つの変換があります。Diffie-Hellmanグループ、整合性チェックアルゴリズム、PRFアルゴリズム、および暗号化アルゴリズムです。プロトコルごとに、許可されるトランスフォームのセットにトランスフォームID番号が割り当てられ、各トランスフォームのヘッダーに表示されます。
If there are multiple transforms with the same Transform Type, the proposal is an OR of those transforms. If there are multiple transforms with different Transform Types, the proposal is an AND of the different groups.
同じ変換タイプの変換が複数ある場合、提案はそれらの変換のORです。変換タイプが異なる複数の変換がある場合、提案はさまざまなグループのANDです。
A given transform MAY have one or more Attributes. Attributes are necessary when the transform can be used in more than one way, as when an encryption algorithm has a variable key size. The transform would specify the algorithm, and the attribute would specify the key size. To propose alternate values for an attribute (for example, multiple key sizes for the AES encryption algorithm), an implementation MUST include multiple transforms with the same Transform Type each with a single Attribute.
特定の変換には、1つ以上の属性が含まれる場合があります。暗号化アルゴリズムのキーサイズが可変である場合など、変換を複数の方法で使用できる場合は、属性が必要です。トランスフォームはアルゴリズムを指定し、属性はキーのサイズを指定します。属性の代替値（たとえば、AES暗号化アルゴリズムの複数のキーサイズ）を提案するには、実装に、それぞれ単一の属性を持つ同じ変換タイプの複数の変換を含める必要があります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Proposals> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Security Association Payload
図3：セキュリティアソシエーションのペイロード
o Proposals (variable) - One or more proposal substructures.
o プロポーザル（変数）-1つ以上のプロポーザルのサブ構造。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 2 | RESERVED | Proposal Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proposal Num | Protocol ID | SPI Size |Num Transforms|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Transforms> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Proposal Substructure
図4：プロポーザルの下部構造
o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the last Proposal Substructure in the SA.
o 0（最後）または2（もっと）（1オクテット）-これがSAの最後の提案サブ構造かどうかを指定します。
o Proposal Length (2 octets, unsigned integer) - Length of this proposal, including all transforms and attributes that follow.
o プロポーザルの長さ（2オクテット、符号なし整数）-このプロポーザルの長さ（後続のすべての変換と属性を含む）。
o Proposal Num (1 octet) - When a proposal is made, the first proposal in an SA payload MUST be 1, and subsequent proposals MUST be one more than the previous proposal. When a proposal is accepted, the proposal number in the SA payload MUST match the number on the proposal sent that was accepted.
o 提案番号（1オクテット）-提案が行われるとき、SAペイロードの最初の提案は1でなければならず（MUST）、後続の提案は前の提案より1つ多い必要があります。プロポーザルが受け入れられるとき、SAペイロードのプロポーザル番号は、受け入れられた送信済みプロポーザルの番号と一致する必要があります。
o Protocol ID (1 octet) - Specifies the IPsec protocol identifier for the current negotiation.
o プロトコルID（1オクテット）-現在のネゴシエーションのIPsecプロトコル識別子を指定します。
Protocol Protocol ID
-----------------------------------
IKE 1
AH 2
ESP 3
o SPI Size (1 octet) - For an initial IKE SA negotiation, this field MUST be zero; the SPI is obtained from the outer header. During subsequent negotiations, it is equal to the size, in octets, of the SPI of the corresponding protocol (8 for IKE and 4 for ESP and AH).
o SPIサイズ（1オクテット）-最初のIKE SAネゴシエーションの場合、このフィールドはゼロでなければなりません。 SPIは外部ヘッダーから取得されます。以降のネゴシエーション中は、対応するプロトコルのSPIのサイズ（オクテット単位）と同じです（IKEの場合は8、ESPとAHの場合は4）。
o Num Transforms (1 octet) - Specifies the number of transforms in this proposal.
o トランスフォームの数（1オクテット）-この提案のトランスフォームの数を指定します。
o SPI (variable) - The sending entity's SPI. When the SPI Size field is zero, this field is not present in the Security Association payload.
o SPI（変数）-送信エンティティのSPI。 SPIサイズフィールドがゼロの場合、このフィールドはセキュリティアソシエーションペイロードに存在しません。
o Transforms (variable) - One or more transform substructures.
o 変換（変数）-1つ以上の変換サブ構造。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 3 | RESERVED | Transform Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transform Type | RESERVED | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Transform Attributes ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Transform Substructure
図5：部分構造の変換
o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the last Transform Substructure in the Proposal.
o 0（最後）または3（もっと）（1オクテット）-これがプロポーザルの最後の変換サブ構造かどうかを指定します。
o Transform Length - The length (in octets) of the Transform Substructure including Header and Attributes.
o 変換の長さ-ヘッダーと属性を含む変換サブ構造の長さ（オクテット単位）。
o Transform Type (1 octet) - The type of transform being specified in this transform. Different protocols support different Transform Types. For some protocols, some of the transforms may be optional. If a transform is optional and the initiator wishes to propose that the transform be omitted, no transform of the given type is included in the proposal. If the initiator wishes to make use of the transform optional to the responder, it includes a transform substructure with Transform ID = 0 as one of the options.
o 変換タイプ（1オクテット）-この変換で指定されている変換のタイプ。異なるプロトコルは、異なる変換タイプをサポートします。一部のプロトコルでは、一部の変換はオプションです。変換がオプションであり、開始者が変換の省略を提案したい場合、指定されたタイプの変換は提案に含まれません。イニシエーターがトランスフォーマーをレスポンダーに対してオプションとして使用したい場合、オプションの1つとしてトランスフォームID = 0のトランスフォームサブストラクチャが含まれます。
o Transform ID (2 octets) - The specific instance of the Transform Type being proposed.
o 変換ID（2オクテット）-提案されている変換タイプの特定のインスタンス。
The relevant Transform Type values are listed below. For more information see [RFC7296].
関連する変換タイプの値を以下に示します。詳細については、[RFC7296]を参照してください。
Description Trans. Used In
Type
------------------------------------------------------------------
Encryption Algorithm (ENCR) 1 IKE and ESP
Pseudorandom Function (PRF) 2 IKE
Integrity Algorithm (INTEG) 3 IKE, AH, optional in ESP
Diffie-Hellman group (D-H) 4 IKE, optional in AH & ESP
Extended Sequence Numbers (ESN) 5 AH and ESP
For Transform Type 1 (Encryption Algorithm), the relevant Transform IDs are listed below.
変換タイプ1（暗号化アルゴリズム）の場合、関連する変換IDを以下にリストします。
Name Number
---------------------------
ENCR_AES_CBC 12
ENCR_AES-CCM_8 14
For Transform Type 2 (Pseudorandom Function), the relevant Transform IDs are listed below.
変換タイプ2（疑似ランダム関数）の場合、関連する変換IDを以下にリストします。
Name Number
----------------------------------
PRF_HMAC_SHA1 2
For Transform Type 3 (Integrity Algorithm), the relevant Transform IDs are listed below.
変換タイプ3（整合性アルゴリズム）の場合、関連する変換IDを以下にリストします。
Name Number
---------------------------
AUTH_HMAC_SHA1_96 2
AUTH_AES_XCBC_96 5
For Transform Type 4 (Diffie-Hellman group), the relevant Transform IDs are listed below.
変換タイプ4（Diffie-Hellmanグループ）の場合、関連する変換IDを以下にリストします。
Name Number
-------------------------
1536-bit MODP 5
2048-bit MODP 14
For Transform Type 5 (Extended Sequence Numbers), the relevant
Transform IDs are listed below.
Name Number
--------------------------------------------
No Extended Sequence Numbers 0
Extended Sequence Numbers 1
Note that an initiator who supports ESNs will usually include two ESN transforms, with values "0" and "1", in its proposals. A proposal containing a single ESN transform with value "1" means that using normal (non-extended) sequence numbers is not acceptable.
ESNをサポートするイニシエーターは通常、その提案に値「0」と「1」の2つのESN変換を含めます。値が「1」の単一のESN変換を含む提案は、通常の（拡張されていない）シーケンス番号の使用が受け入れられないことを意味します。
The number and type of transforms that accompany an SA payload are dependent on the protocol in the SA itself. An SA payload proposing the establishment of an SA has the following mandatory and optional Transform Types. A compliant implementation MUST understand all mandatory and optional types for each protocol it supports (though it need not accept proposals with unacceptable suites). A proposal MAY omit the optional types if the only value for them it will accept is NONE.
SAペイロードに伴う変換の数とタイプは、SA自体のプロトコルに依存します。 SAの確立を提案するSAペイロードには、次の必須およびオプションの変換タイプがあります。準拠した実装は、サポートする各プロトコルのすべての必須およびオプションのタイプを理解する必要があります（ただし、受け入れられないスイートの提案を受け入れる必要はありません）。それらが受け入れる唯一の値がNONEである場合、提案はオプションの型を省略してもよい（MAY）。
Protocol Mandatory Types Optional Types
---------------------------------------------------
IKE ENCR, PRF, INTEG, D-H
ESP ENCR, ESN INTEG, D-H
AH INTEG, ESN D-H
Transform Type 1 (Encryption Algorithm) transforms might include one transform attribute: Key Length.
変換タイプ1（暗号化アルゴリズム）変換には、1つの変換属性（キー長）が含まれる場合があります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Attribute Type | Attribute Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Data Attributes
図6：データ属性
o Attribute Type (15 bits) - Unique identifier for each type of attribute (see below).
o 属性タイプ（15ビット）-属性のタイプごとの一意の識別子（以下を参照）。
o Attribute Value - Value of the attribute associated with the attribute type.
o 属性値-属性タイプに関連付けられた属性の値。
Attribute Type Value
----------------------------
Key Length (in bits) 14
The Key Length attribute specifies the key length in bits (MUST use network byte order) for certain transforms as follows:
キーの長さ属性は、次のように特定の変換のキーの長さをビットで指定します（ネットワークバイトオーダーを使用する必要があります）。
o The Key Length attribute MUST NOT be used with transforms that use a fixed-length key.
o キーの長さ属性は、固定長キーを使用する変換では使用しないでください。
o Some transforms specify that the Key Length attribute MUST be always included. For example, ENCR_AES_CBC.
o 一部の変換では、キーの長さ属性を常に含める必要があることを指定しています。たとえば、ENCR_AES_CBC。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Group Num | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Exchange Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Key Exchange Payload Format
図7：鍵交換ペイロードの形式
A Key Exchange payload is constructed by copying one's Diffie-Hellman public value into the "Key Exchange Data" portion of the payload. The length of the Diffie-Hellman public value for modular exponentiation groups (MODPs) MUST be equal to the length of the prime modulus over which the exponentiation was performed, prepending zero bits to the value if necessary.
キー交換ペイロードは、Diffie-Hellmanパブリック値をペイロードの「キー交換データ」部分にコピーすることによって構築されます。モジュラー指数グループ（MODP）のDiffie-Hellmanパブリック値の長さは、指数が実行されたプライムモジュラスの長さと等しくなければなりません（必要に応じて、値の前にゼロビットを付加します）。
The Diffie-Hellman Group Num identifies the Diffie-Hellman group in which the Key Exchange Data was computed. This Diffie-Hellman Group Num MUST match a Diffie-Hellman group specified in a proposal in the SA payload that is sent in the same message.
Diffie-Hellman Group Numは、キー交換データが計算されたDiffie-Hellmanグループを識別します。このDiffie-Hellmanグループ番号は、同じメッセージで送信されるSAペイロードの提案で指定されたDiffie-Hellmanグループと一致する必要があります。
The Identification payloads, denoted IDi and IDr in this document, allow peers to assert an identity to one another. When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header of IKEv2 packets or anything in the TSi/TSr payloads. The contents of IDi/IDr are used purely to fetch the policy and authentication data related to the other party. In minimal implementation, it might be easiest to always use KEY_ID type. This allows the ID payload to be static. Using an IP address has problems in environments where IP addresses are dynamically allocated.
このドキュメントではIDiおよびIDrと示されている識別ペイロードにより、ピアは相互にIDをアサートできます。 IDi / IDrペイロードでID_IPV4_ADDR / ID_IPV6_ADDR IDタイプを使用する場合、IKEv2では、IKEv2パケットのIPヘッダー内のアドレスやTSi / TSrペイロード内のアドレスと一致するためにこのアドレスは必要ありません。 IDi / IDrのコンテンツは、相手に関連するポリシーと認証データを取得するためだけに使用されます。最小限の実装では、常にKEY_IDタイプを使用するのが最も簡単です。これにより、IDペイロードを静的にすることができます。 IPアドレスが動的に割り当てられる環境では、IPアドレスを使用すると問題が発生します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Identification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Identification Payload Format
図8：識別ペイロードの形式
o ID Type (1 octet) - Specifies the type of Identification being used.
o IDタイプ（1オクテット）-使用されるIDのタイプを指定します。
o Identification Data (variable length) - Value, as indicated by the Identification Type. The length of the Identification Data is computed from the size in the ID payload header.
o 識別データ（可変長）-識別タイプで示される値。識別データの長さは、IDペイロードヘッダーのサイズから計算されます。
The following table lists the assigned semantics for the Identification Type field.
次の表に、[識別タイプ]フィールドに割り当てられているセマンティクスを示します。
ID Type Value
-------------------------------------------------------------------
ID_IPV4_ADDR 1
A single four (4) octet IPv4 address.
ID_FQDN 2 A fully qualified domain name string. An example of an ID_FQDN is "example.com". The string MUST NOT contain any terminators (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; for an "internationalized domain name", the syntax is as defined in [IDNA], for example, "xn--tmonesimerkki-bfbb.example.net".
ID_FQDN 2完全修飾ドメイン名文字列。 ID_FQDNの例は「example.com」です。文字列には、ターミネータを含めることはできません（例：NULL、CRなど）。 ID_FQDNのすべての文字はASCIIです。 「国際化ドメイン名」の場合、構文は[IDNA]で定義されているとおりです（例：「xn--tmonesimerkki-bfbb.example.net」）。
ID_RFC822_ADDR 3 A fully qualified RFC 822 email address string based [RFC5322]. An example of an ID_RFC822_ADDR is "jsmith@example.com". The string MUST NOT contain any terminators. Because of [EAI], implementations would be wise to treat this field as UTF-8-encoded text, not as pure ASCII.
ID_RFC822_ADDR 3完全修飾RFC 822電子メールアドレス文字列ベース[RFC5322]。 ID_RFC822_ADDRの例は「jsmith@example.com」です。文字列にはターミネータを含めてはいけません。 [EAI]があるため、実装ではこのフィールドを純粋なASCIIではなくUTF-8でエンコードされたテキストとして扱うのが賢明です。
ID_IPV6_ADDR 5 A single sixteen (16) octet IPv6 address.
ID_IPV6_ADDR 5単一の16オクテットIPv6アドレス。
ID_KEY_ID 11 An opaque octet stream that may be used to pass vendor-specific information necessary to do certain proprietary types of identification. Minimal implementation might use this type to send out a serial number or similar device-specific unique static Identification Data for the device.
ID_KEY_ID 11特定の独自タイプの識別を行うために必要なベンダー固有の情報を渡すために使用できる不透明なオクテットストリーム。最小限の実装では、このタイプを使用して、デバイスのシリアル番号または同様のデバイス固有の一意の静的識別データを送信できます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | |
+-+-+-+-+-+-+-+-+ |
~ Certificate Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Certificate Payload Format
図9：証明書のペイロード形式
o Certificate Encoding (1 octet) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field.
o Certificate Encoding（1 octet）-このフィールドは、Certificate Dataフィールドに含まれる証明書または証明書関連の情報のタイプを示します。
Certificate Encoding Value
----------------------------------------------------
X.509 Certificate - Signature 4
Raw Public Key 15
o Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Encoding field.
o 証明書データ（可変長）-証明書データの実際のエンコード。証明書のタイプは、Certificate Encodingフィールドで示されます。
The syntax of the types above are:
上記のタイプの構文は次のとおりです。
o "X.509 Certificate - Signature" contains a DER-encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. Note that with this encoding, if a chain of certificates needs to be sent, multiple CERT payloads are used, only the first of which holds the public key used to validate the sender's AUTH payload.
o 「X.509証明書-署名」には、DERでエンコードされたX.509証明書が含まれ、その公開鍵は送信者のAUTHペイロードを検証するために使用されます。このエンコードでは、証明書のチェーンを送信する必要がある場合、複数のCERTペイロードが使用されます。最初のペイロードのみが送信者のAUTHペイロードの検証に使用される公開鍵を保持します。
o "Raw Public Key" contains a raw public key. In essence, the Certificate Payload contains the SubjectPublicKeyInfo part of the PKIX Certificate (see Section 4.1.2.7 of [RFC5280]). This is a quite simple ASN.1 object that contains mostly static parts before the actual public key values. See [RFC7670] for more information.
o 「生の公開鍵」には、生の公開鍵が含まれています。本質的に、証明書ペイロードには、PKIX証明書のSubjectPublicKeyInfo部分が含まれています（[RFC5280]のセクション4.1.2.7を参照）。これは非常に単純なASN.1オブジェクトで、実際の公開鍵の値の前にほとんど静的な部分が含まれています。詳細については、[RFC7670]を参照してください。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | |
+-+-+-+-+-+-+-+-+ |
~ Certification Authority (CA) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Certificate Request Payload Format
図10：証明書リクエストのペイロード形式
o Certificate Encoding (1 octet) - Contains an encoding of the type or format of certificate requested.
o 証明書のエンコーディング（1オクテット）-要求された証明書のタイプまたは形式のエンコーディングが含まれています。
o Certification Authority (variable length) - Contains an encoding of an acceptable certification authority for the type of certificate requested.
o 証明機関（可変長）-要求された種類の証明書の受け入れ可能な証明機関のエンコーディングが含まれています。
The Certificate Encoding field has the same values as those defined by the certificate payload. The Certification Authority field contains an indicator of trusted authorities for this certificate type. The Certification Authority value is a concatenated list of SHA-1 hashes of the public keys of trusted Certification Authorities. Each is encoded as the SHA-1 hash of the Subject Public Key Info element (see Section 4.1.2.7 of [RFC5280]) from each Trust Anchor certificate. The 20-octet hashes are concatenated and included with no other formatting.
Certificate Encodingフィールドの値は、証明書のペイロードで定義されているものと同じです。 [証明機関]フィールドには、この証明書タイプの信頼できる機関のインジケーターが含まれています。証明機関の値は、信頼できる証明機関の公開キーのSHA-1ハッシュの連結リストです。それぞれは、各Trust Anchor証明書からのサブジェクト公開鍵情報要素（[RFC5280]のセクション4.1.2.7を参照）のSHA-1ハッシュとしてエンコードされます。 20オクテットのハッシュは連結され、他のフォーマットは含まれません。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Method | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Authentication Payload Format
図11：認証ペイロードの形式
o Auth Method (1 octet) - Specifies the method of authentication used.
o Auth Method（1 octet）-使用する認証方法を指定します。
Mechanism Value
-----------------------------------------------------------------
RSA Digital Signature 1
Using an RSA private key with an RSASSA-PKCS1-v1_5 signature
scheme specified in [PKCS1]; see Section 2.15 of [RFC7296] for
details.
Shared Key Message Integrity Code 2 Computed as specified earlier using the shared key associated with the identity in the ID payload and the negotiated PRF.
共有キーメッセージ整合性コード2 IDペイロードおよびネゴシエートされたPRFのIDに関連付けられた共有キーを使用して、以前に指定されたように計算されます。
o Authentication Data (variable length) - see Section 2.1.
o 認証データ（可変長）-セクション2.1を参照してください。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Nonce Payload Format
図12：ノンスペイロードのフォーマット
o Nonce Data (variable length) - Contains the random data generated by the transmitting entity.
o ノンスデータ（可変長）-送信エンティティによって生成されたランダムデータが含まれます。
The size of the Nonce Data MUST be between 16 and 256 octets, inclusive. Nonce values MUST NOT be reused.
ノンスデータのサイズは、16〜256オクテットである必要があります。 nonce値は再利用してはいけません。
The Notify payload, denoted N in this document, is used to transmit informational data, such as error conditions and state transitions, to an IKE peer. A Notify payload may appear in a response message (usually specifying why a request was rejected), in an INFORMATIONAL exchange (to report an error not in an IKE request), or in any other message to indicate sender capabilities or to modify the meaning of the request.
このドキュメントではNと示されている通知ペイロードは、エラー条件や状態遷移などの情報データをIKEピアに送信するために使用されます。 Notifyペイロードは、応答メッセージ（通常は要求が拒否された理由を指定）、INFORMATIONAL交換（IKE要求にないエラーを報告する）、または送信者の機能を示すか、またはその意味を変更するその他のメッセージに表示されます。リクエスト。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Notify Payload Format
図13：通知ペイロード形式
o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt.
o プロトコルID（1オクテット）-この通知がSPIフィールドにSPIが指定されている既存のSAに関係する場合、このフィールドはそのSAのタイプを示します。 SPIフィールドが空の場合、このフィールドはゼロとして送信する必要があり、受信時に無視する必要があります。
o SPI Size (1 octet) - Length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE SA, the SPI Size MUST be zero and the SPI field must be empty.
o SPIサイズ（1オクテット）-IPsecプロトコルIDで定義されたSPIのオクテット単位の長さ、またはSPIが適用されない場合はゼロ。 IKE SAに関する通知の場合、SPIサイズはゼロでなければならず、SPIフィールドは空でなければなりません。
o Notify Message Type (2 octets) - Specifies the type of notification message.
o 通知メッセージタイプ（2オクテット）-通知メッセージのタイプを指定します。
o SPI (variable length) - Security Parameter Index.
o SPI（可変長）-セキュリティパラメータインデックス。
o Notification Data (variable length) - Status or error data transmitted in addition to the Notify Message Type. Values for this field are type specific.
o 通知データ（可変長）-通知メッセージタイプに加えて送信されるステータスまたはエラーデータ。このフィールドの値はタイプ固有です。
Notification information can be error messages specifying why an SA could not be established. It can also be status data that a process managing an SA database wishes to communicate with a peer process.
通知情報は、SAを確立できなかった理由を指定するエラーメッセージの場合があります。また、SAデータベースを管理するプロセスがピアプロセスと通信したいステータスデータでもかまいません。
Types in the range 0 - 16383 are intended for reporting errors. An implementation receiving a Notify payload with one of these types that it does not recognize in a response MUST assume that the corresponding request has failed entirely. Unrecognized error types in a request and status types in a request or response MUST be ignored, and they should be logged.
0から16383の範囲のタイプは、エラーの報告を目的としています。応答で認識されないこれらのタイプのいずれかでNotifyペイロードを受信する実装は、対応する要求が完全に失敗したと想定する必要があります。リクエスト内の認識されないエラータイプおよびリクエストまたはレスポンス内のステータスタイプは無視する必要があり、ログに記録する必要があります。
Notify payloads with status types MAY be added to any message and MUST be ignored if not recognized. They are intended to indicate capabilities and, as part of SA negotiation, are used to negotiate non-cryptographic parameters.
ステータスタイプの通知ペイロードはメッセージに追加される場合があり、認識されない場合は無視する必要があります。これらは機能を示すことを目的としており、SAネゴシエーションの一部として、非暗号化パラメーターのネゴシエーションに使用されます。
NOTIFY messages: error types Value
-------------------------------------------------------------------
UNSUPPORTED_CRITICAL_PAYLOAD 1
Indicates that the 1-octet payload type included in the
Notification Data field is unknown.
INVALID_SYNTAX 7 Indicates the IKE message that was received was invalid because some type, length, or value was out of range or because the request was rejected for policy reasons. To avoid a Denial-of-Service (DoS) attack using forged messages, this status may only be returned for and in an encrypted packet if the Message ID and cryptographic checksum were valid. To avoid leaking information to someone probing a node, this status MUST be sent in response to any error not covered by one of the other status types. To aid debugging, more detailed error information should be written to a console or log.
INVALID_SYNTAX 7一部のタイプ、長さ、または値が範囲外だったため、または要求がポリシー上の理由で拒否されたために、受信したIKEメッセージが無効であったことを示します。偽造されたメッセージを使用したサービス拒否（DoS）攻撃を回避するために、このステータスは、メッセージIDと暗号化チェックサムが有効な場合にのみ、暗号化されたパケットに対して返されます。ノードを調査している誰かに情報を漏らさないようにするために、このステータスは、他のステータスタイプのいずれかでカバーされていないエラーへの応答として送信する必要があります。デバッグを支援するには、より詳細なエラー情報をコンソールまたはログに書き込む必要があります。
NO_PROPOSAL_CHOSEN 14 None of the proposed crypto suites was acceptable. This can be sent in any case where the offered proposals are not acceptable for the responder.
NO_PROPOSAL_CHOSEN 14提案された暗号スイートはどれも受け入れられませんでした。これは、提供された提案がレスポンダーに受け入れられない場合に送信できます。
NO_ADDITIONAL_SAS 35 Specifies that the node is unwilling to accept any more Child SAs.
NO_ADDITIONAL_SAS 35ノードがこれ以上の子SAを受け入れたくないことを指定します。
NOTIFY messages: status types Value
-------------------------------------------------------------------
INITIAL_CONTACT 16384
Asserts that this IKE SA is the only IKE SA currently active
between the authenticated identities.
Traffic Selector (TS) payloads allow endpoints to communicate some of the information from their Security Policy Database (SPD) to their peers. TS payloads specify the selection criteria for packets that will be forwarded over the newly set up SA.
トラフィックセレクター（TS）ペイロードにより、エンドポイントはセキュリティポリシーデータベース（SPD）からピアに情報の一部を通信できます。 TSペイロードは、新しくセットアップされたSAを介して転送されるパケットの選択基準を指定します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of TSs | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Traffic Selectors> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Traffic Selectors Payload Format
図14：トラフィックセレクターのペイロード形式
o Number of TSs (1 octet) - Number of Traffic Selectors being provided.
o TSの数（1オクテット）-提供されているトラフィックセレクターの数。
o Traffic Selectors (variable length) - One or more individual Traffic Selectors.
o トラフィックセレクター（可変長）-1つ以上の個別のトラフィックセレクター。
The length of the Traffic Selector payload includes the TS header and all the Traffic Selectors.
トラフィックセレクターペイロードの長さには、TSヘッダーとすべてのトラフィックセレクターが含まれます。
There is no requirement that TSi and TSr contain the same number of individual Traffic Selectors. Thus, they are interpreted as follows: a packet matches a given TSi/TSr if it matches at least one of the individual selectors in TSi and at least one of the individual selectors in TSr.
TSiとTSrに同じ数の個別のトラフィックセレクターが含まれている必要はありません。したがって、それらは次のように解釈されます。パケットがTSiの個々のセレクタの少なくとも1つとTSrの個々のセレクタの少なくとも1つに一致する場合、パケットは特定のTSi / TSrに一致します。
Two TS payloads appear in each of the messages in the exchange that creates a Child SA pair. Each TS payload contains one or more Traffic Selectors. Each Traffic Selector consists of an address range (IPv4 or IPv6), a port range, and an IP protocol ID.
子SAペアを作成する交換の各メッセージに2つのTSペイロードが表示されます。各TSペイロードには、1つ以上のトラフィックセレクターが含まれます。各トラフィックセレクターは、アドレス範囲（IPv4またはIPv6）、ポート範囲、およびIPプロトコルIDで構成されます。
The first of the two TS payloads is known as TSi (Traffic Selector - initiator). The second is known as TSr (Traffic Selector - responder). TSi specifies the source address of traffic forwarded from (or the destination address of traffic forwarded to) the initiator of the Child SA pair. TSr specifies the destination address of the traffic forwarded to (or the source address of the traffic forwarded from) the responder of the Child SA pair.
2つのTSペイロードの最初はTSi（Traffic Selector-発信側）として知られています。 2番目はTSr（Traffic Selector-レスポンダー）として知られています。 TSiは、子SAペアのイニシエーターから転送されたトラフィックのソースアドレス（または転送されたトラフィックの宛先アドレス）を指定します。 TSrは、子SAペアのレスポンダーに転送されるトラフィックの宛先アドレス（または転送されるトラフィックの送信元アドレス）を指定します。
IKEv2 allows the responder to choose a subset of the traffic proposed by the initiator.
IKEv2により、レスポンダはイニシエータによって提案されたトラフィックのサブセットを選択できます。
When the responder chooses a subset of the traffic proposed by the initiator, it narrows the Traffic Selectors to some subset of the initiator's proposal (provided the set does not become the null set). If the type of Traffic Selector proposed is unknown, the responder ignores that Traffic Selector, so that the unknown type is not returned in the narrowed set.
レスポンダは、イニシエータによって提案されたトラフィックのサブセットを選択すると、トラフィックセレクタをイニシエータの提案のサブセットに絞り込みます（セットがnullセットにならない場合）。提案されたトラフィックセレクタのタイプが不明な場合、レスポンダはそのトラフィックセレクタを無視するため、不明なタイプは絞り込まれたセットで返されません。
To enable the responder to choose the appropriate range, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first Traffic Selector in each TSi and TSr a very specific Traffic Selector including the addresses in the packet triggering the request. If the initiator creates the Child SA pair not in response to an arriving packet, but rather, say, upon startup, then there may be no specific addresses the initiator prefers for the initial tunnel over any other. In that case, the first values in TSi and TSr can be ranges rather than specific values.
応答側が適切な範囲を選択できるようにするには、イニシエーターがデータパケットのためにSAを要求した場合、イニシエーターは、各TSiとTSrの最初のトラフィックセレクターとして、リクエスト。イニシエーターが、到着したパケットに応答してではなく、たとえば、起動時に子SAペアを作成する場合、イニシエーターが他のものよりも最初のトンネルに優先する特定のアドレスがない可能性があります。その場合、TSiとTSrの最初の値は特定の値ではなく範囲にすることができます。
As minimal implementations might only support one SA, the Traffic Selectors will usually be from the initiator's IP address to the responder's IP address (i.e., no port or protocol selectors and only one range).
最小限の実装では1つのSAしかサポートされない可能性があるため、トラフィックセレクターは通常、イニシエーターのIPアドレスからレスポンダーのIPアドレス（つまり、ポートまたはプロトコルセレクターがなく、1つの範囲のみ）になります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Type |IP Protocol ID | Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Port | End Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Starting Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Ending Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Traffic Selector
図15：トラフィックセレクター
o TS Type (1 octet) - Specifies the type of Traffic Selector.
o TSタイプ（1オクテット）-トラフィックセレクターのタイプを指定します。
o IP protocol ID (1 octet) - Value specifying an associated IP protocol ID (such as UDP, TCP, and ICMP). A value of zero means that the protocol ID is not relevant to this Traffic Selector -- the SA can carry all protocols.
o IPプロトコルID（1オクテット）-関連するIPプロトコルID（UDP、TCP、ICMPなど）を指定する値。値0は、プロトコルIDがこのトラフィックセレクターに関連していないことを意味します。SAはすべてのプロトコルを伝送できます。
o Selector Length - Specifies the length of this Traffic Selector substructure including the header.
o セレクターの長さ-ヘッダーを含むこのトラフィックセレクターの部分構造の長さを指定します。
o Start Port (2 octets, unsigned integer) - Value specifying the smallest port number allowed by this Traffic Selector. For protocols for which port is undefined (including protocol 0), or if all ports are allowed, this field MUST be zero.
o 開始ポート（2オクテット、符号なし整数）-このトラフィックセレクターで許可されている最小のポート番号を指定する値。ポートが未定義のプロトコル（プロトコル0を含む）の場合、またはすべてのポートが許可されている場合、このフィールドはゼロでなければなりません（MUST）。
o End Port (2 octets, unsigned integer) - Value specifying the largest port number allowed by this Traffic Selector. For protocols for which port is undefined (including protocol 0), or if all ports are allowed, this field MUST be 65535.
o エンドポート（2オクテット、符号なし整数）-このトラフィックセレクターで許可される最大ポート番号を指定する値。ポートが未定義のプロトコル（プロトコル0を含む）の場合、またはすべてのポートが許可されている場合、このフィールドは65535でなければなりません。
o Starting Address - The smallest address included in this Traffic Selector (length determined by TS Type).
o 開始アドレス-このトラフィックセレクターに含まれる最小のアドレス（長さはTSタイプによって決定されます）。
o Ending Address - The largest address included in this Traffic Selector (length determined by TS Type).
o 終了アドレス-このトラフィックセレクタに含まれる最大のアドレス（長さはTSタイプによって決定されます）。
The following table lists values for the Traffic Selector Type field and the corresponding Address Selector Data.
次の表に、Traffic Selector Typeフィールドの値と、対応するAddress Selector Dataを示します。
TS Type Value
-------------------------------------------------------------------
TS_IPV4_ADDR_RANGE 7
A range of IPv4 addresses, represented by two 4-octet
values. The first value is the beginning IPv4 address
(inclusive), and the second value is the ending IPv4 address
(inclusive). All addresses falling between the two specified
addresses are considered to be within the list.
TS_IPV6_ADDR_RANGE 8 A range of IPv6 addresses, represented by two 16-octet values. The first value is the beginning IPv6 address (inclusive), and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list.
TS_IPV6_ADDR_RANGE 8 2つの16オクテット値で表されるIPv6アドレスの範囲。最初の値は開始IPv6アドレス（両端を含む）、2番目の値は終了IPv6アドレス（両端を含む）です。指定された2つのアドレスの間にあるすべてのアドレスは、リスト内にあると見なされます。
The Encrypted payload, denoted as SK{...} in this document, contains other payloads in encrypted form.
このドキュメントではSK {...}として示される暗号化されたペイロードには、暗号化された形式で他のペイロードが含まれています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| (length is block size for the encryption algorithm) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encrypted IKE Payloads ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Encrypted Payload Format
図16：暗号化されたペイロード形式
o Next Payload - The payload type of the first embedded payload. Note that this is an exception in the standard header format, since the Encrypted payload is the last payload in the message; therefore, the Next Payload field would normally be zero. But because the content of this payload is embedded payloads and there was no natural place to put the type of the first one, that type is placed here.
o 次のペイロード-最初の埋め込みペイロードのペイロードタイプ。暗号化されたペイロードはメッセージの最後のペイロードであるため、これは標準ヘッダー形式の例外であることに注意してください。したがって、通常、次のペイロードフィールドはゼロになります。ただし、このペイロードのコンテンツは埋め込みペイロードであり、最初のタイプを配置する自然な場所がないため、そのタイプがここに配置されます。
o Payload Length - Includes the lengths of the header, initialization vector (IV), Encrypted IKE payloads, Padding, Pad Length, and Integrity Checksum Data.
o ペイロードの長さ-ヘッダー、初期化ベクトル（IV）、暗号化されたIKEペイロード、パディング、パッドの長さ、および整合性チェックサムデータの長さを含みます。
o Initialization Vector - For Cipher Block Chaining (CBC) mode ciphers, the length of the initialization vector (IV) is equal to the block length of the underlying encryption algorithm. Senders MUST select a new unpredictable IV for every message; recipients MUST accept any value. The reader is encouraged to consult [MODES] for advice on IV generation. In particular, using the final ciphertext block of the previous message is not considered unpredictable. For modes other than CBC, the IV format and processing is specified in the document specifying the encryption algorithm and mode.
o 初期化ベクトル-暗号ブロック連鎖（CBC）モード暗号の場合、初期化ベクトル（IV）の長さは、基礎となる暗号化アルゴリズムのブロック長と同じです。送信者は、すべてのメッセージに対して新しい予測不可能なIVを選択する必要があります。受信者は任意の値を受け入れる必要があります。 IV生成についてのアドバイスは、[モード]を参照することをお勧めします。特に、前のメッセージの最後の暗号文ブロックを使用することは予測不可能とは見なされません。 CBC以外のモードの場合、IV形式と処理は、暗号化アルゴリズムとモードを指定するドキュメントで指定されています。
o IKE payloads are as specified earlier in this section. This field is encrypted with the negotiated cipher.
o IKEペイロードは、このセクションで前述したとおりです。このフィールドは、ネゴシエートされた暗号で暗号化されています。
o Padding MAY contain any value chosen by the sender and MUST have a length that makes the combination of the payloads, the Padding, and the Pad Length to be a multiple of the encryption block size. This field is encrypted with the negotiated cipher.
o パディングには、送信者が選択した任意の値を含めることができ（MAY）、ペイロード、パディング、およびパッド長の組み合わせを暗号化ブロックサイズの倍数にする長さを持つ必要があります。このフィールドは、ネゴシエートされた暗号で暗号化されています。
o Pad Length is the length of the Padding field. The sender SHOULD set the Pad Length to the minimum value that makes the combination of the payloads, the Padding, and the Pad Length a multiple of the block size, but the recipient MUST accept any length that results in proper alignment. This field is encrypted with the negotiated cipher.
o Pad Lengthは、Paddingフィールドの長さです。送信者は、ペイロード、パディング、およびパッド長の組み合わせをブロックサイズの倍数にする最小値にパッド長を設定する必要があります（SHOULD）が、受信者は適切な配置になる任意の長さを受け入れる必要があります。このフィールドは、ネゴシエートされた暗号で暗号化されています。
o Integrity Checksum Data is the cryptographic checksum of the entire message starting with the Fixed IKE header through the Pad Length. The checksum MUST be computed over the encrypted message. Its length is determined by the integrity algorithm negotiated.
o 整合性チェックサムデータは、固定IKEヘッダーからパッド長までのメッセージ全体の暗号化チェックサムです。チェックサムは、暗号化されたメッセージに対して計算する必要があります。その長さは、交渉された整合性アルゴリズムによって決定されます。
There are some optional features of IKEv2, which might be useful for minimal implementations in some scenarios. Such features include raw public keys authentication and sending an IKE SA delete notification.
IKEv2にはいくつかのオプション機能があり、シナリオによっては最小限の実装に役立つ場合があります。このような機能には、生の公開鍵認証、IKE SA削除通知の送信などがあります。
In some scenarios, a minimal implementation device creates an IKE SA, sends one or few packets, perhaps gets some packets back, and then the device goes back to sleep, forgetting the IKE SA. In such scenarios, it would be nice for the minimal implementation to send the IKE SA delete notification to tell the other end that the IKE SA is going away, so it can free the resources.
いくつかのシナリオでは、最小実装デバイスがIKE SAを作成し、1つまたはいくつかのパケットを送信し、おそらくいくつかのパケットを取り戻し、デバイスはIKE SAを忘れてスリープ状態に戻ります。このようなシナリオでは、最小限の実装でIKE SA削除通知を送信して、IKE SAが廃止されることを相手側に通知し、リソースを解放できると便利です。
Deleting the IKE SA can be done by sending one packet with a fixed Message ID and with only one payload inside the Encrypted payload. The other end will send back an empty response:
IKE SAの削除は、固定メッセージIDと、暗号化されたペイロード内の1つのペイロードのみを含む1つのパケットを送信することで実行できます。もう一方の端は空の応答を送り返します：
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Initiator, Message ID=2),
SK {D} -->
<-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Response, Message ID=2),
SK {}
The Delete payload format is:
Deleteペイロードの形式は次のとおりです。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Num of SPIs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index(es) (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Delete Payload Format
図17：ペイロード形式の削除
o Protocol ID (1 octet) - Must be 1 for an IKE SA.
o プロトコルID（1オクテット）-IKE SAの場合は1でなければなりません。
o SPI Size (1 octet) - Length in octets of the SPI as defined by the protocol ID. It MUST be zero for IKE (SPI is in the message header).
o SPIサイズ（1オクテット）-プロトコルIDで定義されているSPIのオクテット単位の長さ。 IKEの場合はゼロでなければなりません（SPIはメッセージヘッダーにあります）。
o Num of SPIs (2 octets, unsigned integer) - The number of SPIs contained in the Delete payload. This MUST be zero for IKE.
o Num of SPIs（2 octets、unsigned integer）-Deleteペイロードに含まれるSPIの数。 IKEの場合、これはゼロでなければなりません。
o Security Parameter Index(es) (variable length) - Identifies the specific Security Association(s) to delete. The length of this field is determined by the SPI Size and Num of SPIs fields. This field is empty for the IKE SA delete.
o セキュリティパラメータインデックス（可変長）-削除する特定のセキュリティアソシエーションを識別します。このフィールドの長さは、SPIサイズとSPIの数フィールドによって決定されます。このフィールドは、IKE SA削除の場合は空です。
In some scenarios, the shared secret authentication is not safe enough, as anybody who knows the secret can impersonate the server. If the shared secret is printed on the side of the device, then anybody who gets physical access to the device can read it. In such environments, public key authentication allows stronger authentication with minimal operational overhead. Certificate support is quite complex, and minimal implementations do not usually have need for them. Using Raw Public Keys is much simpler, and it scales similar to certificates. The fingerprint of the raw public key can still be distributed by, for example, printing it on the side of the device allowing setup similar to using a shared secret.
シークレットを知っている人は誰でもサーバーになりすますことができるため、一部のシナリオでは、共有シークレット認証は十分に安全ではありません。共有シークレットがデバイスの側面に印刷されている場合、デバイスに物理的にアクセスできる人なら誰でもそれを読み取ることができます。このような環境では、公開鍵認証により、運用上のオーバーヘッドを最小限に抑えてより強力な認証が可能になります。証明書のサポートは非常に複雑であり、通常、最小限の実装では必要ありません。未加工の公開鍵の使用ははるかに簡単で、証明書と同様に拡張できます。未加工の公開鍵のフィンガープリントは、たとえば、デバイスの側面にそれを印刷することで配布でき、共有シークレットを使用するのと同様の設定が可能になります。
Raw public keys can also be used in a "leap of faith" or baby duck style initial setup, where the device imprints itself to the first device it sees when it boots up the first time. After that initial connection, it stores the fingerprint of the Raw Public Key of the server in its own configuration and verifies that it never changes (unless a "reset to factory settings" or similar command is issued).
生の公開鍵は、「リープオブフェイス」または赤ちゃんのアヒルスタイルの初期設定でも使用できます。この場合、デバイスは、最初の起動時に最初に表示されるデバイスに自身をインプリントします。最初の接続後、サーバーの未加工の公開鍵のフィンガープリントを独自の構成で保存し、変更されないことを確認します（「リセットして工場出荷時の設定」または同様のコマンドが発行されない限り）。
This changes the initial IKE_AUTH payloads as follows:
これにより、初期のIKE_AUTHペイロードが次のように変更されます。
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1),
SK {IDi, CERT, AUTH, SAi2, TSi, TSr,
N(INITIAL_CONTACT)} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1),
SK {IDr, CERT, AUTH, SAr2, TSi, TSr}
The CERT payloads contain the raw public keys used to sign the hash of the InitiatorSignedOctects/ResponderSignedOctects when generating an AUTH payload. Minimal implementations should use SHA-1 as the hash function as that is the "SHOULD" support algorithm specified in RFC 7296, so it is the most likely one that is supported by all devices.
CERTペイロードには、AUTHペイロードの生成時にInitiatorSignedOctects / ResponderSignedOctectsのハッシュに署名するために使用される生の公開鍵が含まれています。最小限の実装では、SHA-1をハッシュ関数として使用する必要があります。これは、RFC 7296で指定されている「SHOULD」サポートアルゴリズムであるため、すべてのデバイスでサポートされる可能性が最も高いアルゴリズムです。
Note that RFC 7296 already obsoleted the old Raw RSA Key method, and "Generic Raw Public-Key Support for IKEv2" [RFC7670] adds a new format to allow using any types of raw public keys with IKEv2. This document only specifies how to use the new format.
RFC 7296は古いRaw RSA Keyメソッドをすでに廃止しており、「IKEv2のGeneric Raw Public-Key Support」[RFC7670]は、IKEv2で任意のタイプのRaw公開キーを使用できるようにする新しいフォーマットを追加することに注意してください。このドキュメントでは、新しい形式の使用方法のみを指定しています。
In these setups, it might be possible that authenticating the server is not needed at all. If a minimal device is sending, for example, sensor information to the server, the server wants to verify that the sensor is who it claims to be using raw public keys, but the sensor does not really care who the server is. In such cases, the NULL authentication method [RFC7619] would be useful, as it allows devices to do one-way authentication.
これらの設定では、サーバーの認証がまったく必要ない可能性があります。最小限のデバイスがセンサー情報などをサーバーに送信している場合、サーバーは、センサーが未加工の公開鍵を使用していると主張している人物であることを確認する必要がありますが、センサーは実際にはサーバーが誰であるかを気にしません。このような場合、デバイスが一方向の認証を行うことができるので、NULL認証方法[RFC7619]が役立ちます。
Acknowledgements
謝辞
Most of the content of this document is copied from RFC 7296.
このドキュメントの内容のほとんどは、RFC 7296からコピーされています。
Author's Address
著者のアドレス
Tero Kivinen INSIDE Secure Eerikinkatu 28 HELSINKI FI-00180 FINLAND
Tero Kivinen INSIDE Secure Eerikinkatu 28 HELSINKI FI-00180 FINLAND
Email: kivinen@iki.fi