Internet Engineering Task Force (IETF) R. Singh, Ed.
Request for Comments: 6311 G. Kalyani
Category: Standards Track Cisco
ISSN: 2070-1721 Y. Nir
Check Point
Y. Sheffer
Porticor
D. Zhang
Huawei
July 2011
Protocol Support for High Availability of IKEv2/IPsec
Abstract
抽象
The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable, and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However, there are many issues in IPsec HA clustering, and in particular in Internet Key Exchange Protocol version 2 (IKEv2) clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol.
IPsecプロトコルスイートは、ビジネスクリティカルなネットワーク・トラフィックのために広く使用されています。 、高可用性よりスケーラブル、および故障耐性のIPsecの展開を行うために、彼らはしばしばIPsecの高可用性（HA）クラスタとして実装されています。しかし、多くの問題は、インターネット鍵交換プロトコルバージョン2（IKEv2の）クラスタリングでのIPsec HAクラスタリングでは、特にあります。以前の文書、「IPsecのクラスタ問題文は」IKEv2の/ IPsecのHAクラスタ環境で発生する問題を列挙します。この文書では、プロトコルへの最小限の変更で、これらの問題を解決します。
This document defines an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot standby cluster, and provides implementation advice for other issues. The main issues solved are the synchronization of IKEv2 Message ID counters, and of IPsec replay counters.
この文書では、一般的に展開され、ホットスタンバイクラスタ内の「IPsecのクラスタの問題に関する声明」の主な問題点を解決するためのIKEv2プロトコルに拡張を定義、およびその他の問題のための実装のアドバイスを提供します。解決の主な問題は、IKEv2のメッセージIDカウンタの、およびIPsecのリプレイカウンタの同期です。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（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/rfc6311.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6311で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Issues Resolved from IPsec Cluster Problem Statement ............7
3.1. Large Amount of State ......................................8
3.2. Multiple Members Using the Same SA .........................9
3.3. Avoiding Collisions in SPI Number Allocation ...............9
3.4. Interaction with Counter Modes .............................9
4. The IKEv2/IPsec SA Counter Synchronization Problem .............10
5. SA Counter Synchronization Solution ............................11
5.1. Processing Rules for IKE Message ID Synchronization .......13
5.2. Processing Rules for IPsec Replay Counter
Synchronization ...........................................14
6. IKEv2/IPsec Synchronization Notification Payloads ..............14
6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification ..........15
6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification ......15
6.3. The IKEV2_MESSAGE_ID_SYNC Notification ....................16
6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification ................16
7. Implementation Details .........................................17
8. IKE SA and IPsec SA Message Sequencing .........................18
8.1. Handling of Pending IKE Messages ..........................18
8.2. Handling of Pending IPsec Messages ........................18
8.3. IKE SA Inconsistencies ....................................19
9. Step-by-Step Details ...........................................19
10. Interaction with Other Specifications .........................20
11. Security Considerations .......................................21
12. IANA Considerations ...........................................21
13. Acknowledgements ..............................................22
14. References ....................................................22
14.1. Normative References .....................................22
14.2. Informative References ...................................22
Appendix A. IKEv2 Message ID Sync Examples ........................24
A.1. Normal Failover -- Example 1 ...............................24
A.2. Normal Failover -- Example 2 ...............................24
A.3. Normal Failover -- Example 3 ...............................25
A.4. Simultaneous Failover ......................................25
The IPsec protocol suite, including the Internet Key Exchange Protocol version 2 (IKEv2), is a major building block of virtual private networks (VPNs). In order to make such VPNs highly available, more scalable, and failure-resistant, these VPNs are implemented as IKEv2/IPsec Highly Available (HA) clusters. However, there are many issues with the IKEv2/IPsec HA cluster. Sections 3 and 4 below expand on the issues around the IKEv2/IPsec HA cluster solution, issues which were first described in the problem statement [6].
インターネット鍵交換プロトコルバージョン2（IKEv2の）を含むIPsecプロトコルスイートは、仮想プライベートネットワーク（VPN）の主要なビルディング・ブロックです。 、高可用性よりスケーラブル、故障耐性のようなVPNを作るために、これらのVPNはのIKEv2 / IPsecの高可用性（HA）クラスタとして実装されています。しかし、IKEv2の/ IPsecのHAクラスタと多くの問題があります。セクション3と4は、以下のIKEv2 / IPsecのHAクラスタソリューションの周りに問題に展開し、第一の問題文に記載された問題[6]。
In the case of a hot standby cluster implementation of IKEv2/ IPsec-based VPNs, the IKEv2/IPsec session is first established between the peer and the active member of the cluster. Later, the active member continuously syncs/updates the IKE/IPsec security association (SA) state to the standby member of the cluster. This primary SA state sync-up takes place upon each SA bring-up and/or rekey. Performing the SA state synchronization/update for every single IKE and IPsec message is very costly, so normally it is done periodically. As a result, when the failover event happens, this is first detected by the standby member and, possibly after a considerable amount of time, it becomes the active member. During this failover process, the peer is unaware of the failover event, and keeps sending IKE requests and IPsec packets to the cluster, as in fact it is allowed to do because of the IKEv2 windowing feature. After the newly active member starts, it detects the mismatch in IKE Message ID values and IPsec replay counters and needs to resolve this situation. Please see Section 4 for more details of the problem.
IKEv2 / IPsecベースのVPNのホットスタンバイクラスタの実装の場合、のIKEv2 / IPsecのセッションは、最初のピアとクラスタのアクティブなメンバーとの間で確立されます。以降、アクティブメンバが連続/クラスタのスタンバイメンバにIKE / IPsecセキュリティアソシエーション（SA）状態を更新する同期。この主要SA状態同期アップは、各SAの立ち上げおよび/またはリキー時に行われます。すべての単一のIKEおよびIPsec SAメッセージの状態同期/更新を行うことが非常に高価であるため、通常は定期的に行われます。その結果、フェイルオーバー・イベントが発生したとき、これは最初、おそらくかなりの時間後、アクティブメンバになり、スタンバイ部材によって検出されます。このフェイルオーバー・プロセス中に、ピアは、フェールオーバーイベントを認識しない、実際に理由のIKEv2ウィンドウ機能を行うことを許可されているように、クラスタにIKE要求とIPsecパケットを送信し続けます。新しくアクティブになったメンバーが開始された後、それはIKEメッセージID値とのIPsecリプレイカウンターの不一致を検出し、この状況を解決する必要があります。問題の詳細については、第4章を参照してください。
This document defines an extension to the IKEv2 protocol to solve the main issues of IKE Message ID synchronization and IPsec SA replay counter synchronization, and gives implementation advice to address other issues. Following is a summary of the solutions provided in this document:
この文書では、IKEメッセージID同期およびIPsec SAリプレイカウンタ同期の主要な問題を解決するためのIKEv2プロトコルに拡張を定義し、他の問題に対処するために実装のアドバイスを与えます。このドキュメントに記載されているソリューションの概要は、次のとおりです。
o IKEv2 Message ID synchronization: This is done by syncing up the expected send and receive Message ID values with the peer, and updating the values at the newly active cluster member.
OのIKEv2メッセージIDの同期化：これは予想される送信を同期ピアとメッセージID値を受信し、新たにアクティブなクラスタメンバに値を更新することによって行われます。
o IPsec replay counter synchronization: This is done by incrementing the cluster's outgoing SA replay counter values by a "large" number; in addition, the newly active member requests the peer to increment the replay counter values it is using for the peer's outgoing traffic.
O IPsecのリプレイカウンタ同期：これは、「大規模な」数でクラスタの発信SAリプレイカウンタ値をインクリメントすることによって行われます。加えて、新たにアクティブになったメンバーが、それはピアの発信トラフィック用に使用されたリプレイカウンタ値をインクリメントするピアを要求します。
Although this document describes the IKEv2 Message ID and IPsec replay counter synchronization in the context of an IPsec HA cluster, the solution provided is generic and can be used in other scenarios where IKEv2 Message ID or IPsec SA replay counter synchronization may be required.
この文書は、IPsecのHAクラスタのコンテキストでのIKEv2メッセージIDおよびIPsecリプレイカウンタ同期を記載しているが、提供されるソリューションは、一般的であり、IKEv2のメッセージIDやIPsec SAリプレイカウンタ同期が必要とされ得る他のシナリオで使用することができます。
Implementations differ on the need to synchronize the IKEv2 Message ID and/or IPsec replay counters. Both of these problems are handled separately, using a separate notification for each capability. This provides the flexibility of implementing either or both of these solutions.
実装は、IKEv2のメッセージIDおよび/またはIPsecのリプレイカウンタを同期させる必要に異なります。これらの問題の両方は、各機能のために別々の通知を使用して、別々に処理されます。これは、これらのソリューションのいずれかまたは両方を実装するための柔軟性を提供します。
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 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[1]に記載のように解釈されます。
"SA Counter Synchronization" is the informational exchange defined in this document to synchronize the IKEv2/IPsec SA counter information between one member of the cluster and the peer.
「SAカウンタ同期」とは、一つのクラスターのメンバーとピアとの間のIKEv2 / IPsec SAのカウンタ情報を同期させるために、この文書で定義された情報交換です。
Some of the terms listed below are reused from [6] with further clarification in the context of the current document.
下記の用語のいくつかは、現在のドキュメントのコンテキストでさらに明確と[6]から再利用されます。
o "Hot Standby Cluster", or "HS Cluster", is a cluster where only one of the members is active at any one time. This member is also referred to as the "active" member, whereas the other(s) are referred to as "standby" members. The Virtual Router Redundancy Protocol (VRRP) [7] is one method of building such a cluster. The goal of the hot standby cluster is to create the illusion of a single virtual gateway to the peer(s).
O「ホットスタンバイクラスタ」、または「HSクラスタ」、メンバーの一つだけが一度にアクティブであるクラスタです。 （S）他が「待機」のメンバーと呼ばれ、一方、このメンバーはまた、「アクティブ」メンバーと呼ばれています。仮想ルータ冗長プロトコル（VRRP）[7]そのようなクラスタを構築する1つの方法です。ホットスタンバイクラスタの目標は、ピア（複数可）に単一の仮想ゲートウェイの錯覚を作成することです。
o "Active Member" is the primary member in the hot standby cluster. It is responsible for forwarding packets on behalf of the virtual gateway.
O「アクティブメンバーは、」ホットスタンバイクラスタの主要メンバーです。これは、仮想ゲートウェイに代わってパケットを転送する責任があります。
o "Standby Member" is the primary backup member. This member takes control, i.e., becomes the active member, after the failover event.
O「スタンバイメンバは、」プライマリ・バックアップのメンバーです。このメンバーは、制御を要する、すなわち、フェイルオーバー・イベントの後、アクティブなメンバーになります。
o "Peer" is an IKEv2/IPsec endpoint that maintains an IPsec connection with the hot standby cluster. The peer identifies the cluster by the cluster's (single) IP address. If a failover event occurs, the standby member of the cluster becomes active, and the peer normally doesn't notice that failover has taken place. Although we treat the peer as a single entity, it may also be a cluster.
O「ピアは、」ホットスタンバイクラスタとのIPsec接続を維持のIKEv2 / IPsecのエンドポイントです。ピアは、クラスタの（シングル）IPアドレスによってクラスタを識別します。フェールオーバーイベントが発生した場合、クラスタのスタンバイメンバーがアクティブになり、ピアが正常にフェイルオーバーが行われたことを気づいていません。我々は単一のエンティティとしてピアを扱いますが、それはまた、クラスタかもしれません。
o "Multiple failover" is the situation where, in a cluster with three or more members, multiple failover events happen in rapid succession, e.g., from M1 to M2, and then to M3. It is our goal that the implementation should be able to handle this situation, i.e., to handle the new failover event even if it is still processing the old failover.
o「は、複数のフェイルオーバーが」とし、M3に、三人の以上のメンバーを持つクラスタで、複数のフェイルオーバーイベントがM1からM2に、例えば、矢継ぎ早に起こる状況です。これは、実装が、それはまだ古いフェイルオーバーを処理している場合でも、新しいフェイルオーバー・イベントを処理するために、すなわち、このような状況に対処することができるはず私たちの目標です。
o "Simultaneous failover" is the situation where two clusters have an IPsec connection between them, and failover happens at both ends at the same time. It is our goal that implementations should be able to handle simultaneous failover.
O「同時フェイルオーバー」は、2つのクラスタは、それらの間のIPsec接続を持っている状況で、フェイルオーバーが同時に両端に発生します。これは、実装が同時フェールオーバーを処理することができるはず私たちの目標です。
o "IPsec replay counter" is the Encapsulating Security Payload (ESP) Sequence Number or Extended Sequence Number (Section 2.2 of [2]), or the respective field in the Authentication Header (AH) protocol (Section 2.5 of [3]).
「IPsecのリプレイカウンタ」Oカプセル化セキュリティペイロード（ESP）シーケンス番号または拡張認証ヘッダ（AH）プロトコル（[3]のセクション2.5）内のシーケンス番号（[2]のセクション2.2）、またはそれぞれのフィールドです。
The generic term "IKEv2/IPsec SA Counters" is used throughout this document. This term refers to both IKEv2 Message ID counters and IPsec replay counters. According to the IPsec standards, the IKEv2 Message ID counter is mandatory, and used to ensure reliable delivery as well as to protect against message replay in IKEv2; the IPsec SA replay counters are optional, and are used to provide the IPsec anti-replay feature.
一般的な用語「IKEv2の/ IPsec SAのカウンタは、」この文書全体で使用されます。この用語は、IKEv2のメッセージIDカウンタとIPsecのリプレイカウンタの両方を意味します。 IPsecの規格によれば、IKEv2のメッセージIDカウンタは必須であり、かつ信頼性の高い配信を確実にするために、並びにのIKEv2のメッセージリプレイから保護するために使用されます。 IPsecのSAのリプレイカウンタはオプションであり、およびIPSecアンチリプレイ機能を提供するために使用されています。
Some of these terms are used in the following architectural diagram.
これらの用語のいくつかは、次のアーキテクチャ図で使用されています。
+---------------+
| |
| Hot Standby |
| Cluster |
| |
| +---------+ |
| | | |
| | Active | |
| | | |
| | Member | |
| | | |
| +---------+ |
| ^ |
+---------+ | Synch | |
| | | Channel | |
| IPsec | IKE/IPsec Traffic | | |
| | <=============================> | | |
| Peer | | | |
| | | | |
+---------+ | | |
| v |
| +---------+ |
| | | |
| | Standby | |
| | | |
| | Member | |
| | | |
| +---------+ |
+---------------+
An IPsec Hot Standby Cluster
IPsecのホットスタンバイクラスタ
"IPsec Cluster Problem Statement" [6] enumerates the problems raised by IPsec clusters. The following table lists the problem statement's sections that are resolved by this document.
「IPsecのクラスタの問題文は」[6]のIPsecクラスターが提起した問題を列挙します。次の表に、このドキュメントによって解決される問題ステートメントのセクションを示しています。
o 3.2. A Lot of Long-Lived State o 3.3. IKE Counters o 3.4. Outbound SA Counters o 3.5. Inbound SA Counters o 3.6. Missing Synch Messages o 3.7. Simultaneous Use of IKE and IPsec SAs by Different Members * 3.7.1. Outbound SAs Using Counter Modes o 3.8. Different IP Addresses for IKE and IPsec o 3.9. Allocation of SPIs
3.2 O。 3.3 O長期性状態のロット。 IKEは3.4 oをカウンタ。アウトバウンドSAは3.5 oをカウンタ。インバウンドSAは3.6 oをカウンタ。 3.7 oをSynchのメッセージがありません。異なるメンバーによるIKEとIPsec SAの同時使用* 3.7.1。カウンターモード3.8 Oを使用したアウトバウンドのSA。 3.9 O IKEおよびIPsecのための異なるIPアドレス。 SPIのの配分
The main problem areas are solved using the protocol extension defined below, starting with Section 5; additionally, this section provides implementation advice for other issues in the following subsections. Implementers should note that these subsections include a number of new security-critical requirements.
主な問題領域は、セクション5で始まる、以下に定義されるプロトコル拡張を使用して解決されます。さらに、このセクションは以下のサブセクションで他の問題のための実装のアドバイスを提供します。実装者は、これらのサブセクションは、新しいセキュリティ上重要な要件の数を含めることに注意してください。
Section 3.2 of the problem statement [6] mentions that a lot of state needs to be synchronized for a cluster to be transparent. The actual volume of that data is very much implementation-dependent, and even for the same implementation, the amounts of data may vary wildly. An IPsec gateway used for inter-domain VPN with a dozen other gateways, and having SAs that are rekeyed every 8 hours, will need a lot less synchronization traffic than a similar gateway used for remote access, and supporting 10,000 clients. This is because counter synchronization is proportional to the number of SAs and requires little data, and the setting up of an SA requires a lot of data. Additionally, remote access IKE and IPsec SA setup tend to happen at a particular time of day, so the example gateway with the 10,000 clients may see 30-50 IKE SA setups per second at 9:00 AM. This would require very heavy synchronization traffic over that short period of time.
[6]問題文の3.2節では、クラスタを透明にするために多くの状態を同期させる必要があることに言及します。そのデータの実際の量は非常に実装依存であり、さらに同じ実装のために、データの量は、乱暴に異なる場合があります。 8時間ごとにリキーされたIPsecダース他のゲートウェイで、ドメイン間VPNのために使用されるゲートウェイ、および持つSAは、リモートアクセスのために使用される同様のゲートウェイよりもはるかに少ない同期トラフィックを必要とし、10,000クライアントをサポートします。カウンタ同期はSAの数に比例し、少しのデータを必要とし、SAの設定までは、大量のデータを必要とするからです。また、リモートアクセスIKEとIPsec SAの設定は、一日の特定の時間に発生する傾向があるので、万クライアントとの例ゲートウェイは、午前9時毎秒30-50 IKE SAのセットアップを参照してくださいことがあります。これは時間の短い期間にわたって非常に重い同期トラフィックを必要とします。
If a large volume of traffic is necessary, it may be advisable to use a dedicated high-speed network interface for synch traffic. When packet loss can be made extremely low, it may be advisable to use a stateless transport such as UDP, to minimize network overhead.
トラフィックの大容量が必要な場合、同期トラフィックのための専用の高速ネットワークインターフェースを使用するのが望ましいことがあります。パケットロスが極めて低くすることができる場合は、ネットワークのオーバーヘッドを最小限に抑えるために、UDPのようなステートレストランスポートを使用することが推奨されます。
If these methods are insufficient, it may be prudent that for some SAs the entire state is not synchronized. Instead, only an indication of the SA's existence is synchronized. This, in combination with a sticky solution (as described in Section 3.7 of the problem statement [6]) ensures that the traffic from a particular peer does not reach a different member before an actual failover happens. When that happens, the method described in [8] can be used to quickly force the peer to set up a new SA.
これらの方法では不十分である場合、いくつかのSAの全体の状態が同期されていないことが賢明かもしれません。代わりに、SAの存在の唯一の表示が同期されます。これは、粘着性溶液（問題文のセクション3.7に記載されているように[6]）と組み合わせて、実際のフェイルオーバーが発生する前に特定のピアからのトラフィックが別部材に到達しないことを保証します。そのような場合、に記載された方法[8]すばやく新しいSAをセットアップするためにピアを強制するために使用することができます。
In a load-sharing cluster of the "duplicate" variety (see Section 3.7 of the problem statement [6]), multiple members may need to send traffic with the same selectors. To actually use the same SA, the cluster would have to synchronize the replay counter after every packet, and that would impose unreasonable requirements on the synch connection.
「複製」様々な負荷分散クラスタでは（問題文[6]のセクション3.7を参照）、複数のメンバーが同じセレクタでトラフィックを送信する必要があるかもしれません。実際には同じSAを使用するには、クラスタは、すべてのパケットの後にリプレイカウンタを同期させるために、そしてそれは同期の接続に不当な要求を課す必要があります。
A far better solution would be to not synchronize the outbound SA, and create multiple outbound SAs, one for each member. The problem with this option is that the peer might view these multiple parallel SAs as redundant, and tear down all but one of them.
はるかに良い解決策は、アウトバウンドSAを同期、および複数のアウトバウンドのSA、各メンバーのための1つを作成しないことであろう。このオプションを使用して問題は、ピアが冗長なように、これら複数の並列SAを表示し、そのうちの一つが、すべてを取り壊すかもしれないということです。
Section 2.8 of [4] specifically allows multiple parallel SAs, but the reason given for this is to have multiple SAs with different Quality of Service (QoS) attributes. So while this is not a new requirement of IKEv2 implementations working with QoS, we re-iterate here that IPsec peers MUST accept the long-term existence of multiple parallel SAs, even when QoS mechanisms are not in use.
[4]のセクション2.8は、具体的には、複数の並列SAを可能にするが、このために与えられた理由は、Service（QoS）の異なる品質を有する複数のSAを有することである属性。これは、QoSでの作業のIKEv2の実装の新しい要件ではありませんのでながら、私たちは、IPsecピアは、QoSメカニズムが使用されていない場合でも、複数の並列SAの長期的な存在を受け入れなければならないことをここで繰り返しますが。
Section 3.9 of the problem statement [6] describes the problem of two cluster members allocating the same Security Parameter Index (SPI) number for two different SAs. This behavior would violate Section 4.4.2.1 of [5]. There are several schemes to allow implementations to avoid such collisions, such as partitioning the SPI space, a request-response over the synch channel, and locking mechanisms. We believe that these are sufficiently robust and available so that we don't need to make an exception to the rules in Section 4.4.2.1 of RFC 4301 [5], and we can leave this problem for the implementations to solve. Cluster members must not generate multiple inbound SAs with the same SPI.
問題文[6]のセクション3.9には、二つの異なるSAの同じセキュリティパラメータインデックス（SPI）番号を割り当てる2人のクラスタメンバーの問題について説明します。この動作は、[5]のセクション4.4.2.1に違反します。実装は、SPI空間、同期チャネルを介して要求応答を分割し、ロック機構などの衝突を回避することを可能にするいくつかの方式があります。私たちは、[5]、我々はRFC 4301のセクション4.4.2.1でのルールに例外を作成する必要がないように、これらは十分に堅牢で利用可能であることを信じて、我々は解決するために実装するために、この問題を残すことができます。クラスタメンバーは、同じSPIを持つ複数のインバウンドSAを生成してはなりません。
For SAs involving counter mode ciphers such as Counter Mode (CTR) [9] or Galois/Counter Mode (GCM) [10], there is yet another complication. The initial vector for such modes MUST NOT be repeated, and senders may use methods such as counters or linear feedback shift registers (LFSRs) to ensure this property. For an SA shared between multiple active members (load-sharing cases), implementations MUST ensure that no initial vector is ever repeated. Similar concerns apply to an SA failing over from one member to another. See [11] for a discussion of this problem in another context.
SAは、このようなカウンタモード（CTR）としてカウンタモード暗号を含む[9]又はガロア/カウンタ・モード（GCM）[10]、さらに別の合併症があります。そのようなモードのための初期ベクトルを繰り返してはいけません、そして送信者は、このプロパティを確実にするために、このようなカウンタまたは線形フィードバックシフトレジスタ（LFSR）などの方法を使用してもよいです。 SAは、複数のアクティブなメンバー（負荷分散の場合）の間で共有するために、実装には、初期ベクトルがこれまで繰り返されないことを確実にしなければなりません。同様の懸念は別のメンバーからフェイルオーバーSAに適用されます。別のコンテキストでこの問題の議論のための[11]を参照してください。
Just as in the SPI collision problem, there are ways to avoid a collision of initial vectors, and this is left up to implementations. In the context of load sharing, parallel SAs are a simple solution to this problem as well.
ただ、SPIの衝突の問題のように、初期ベクトルの衝突を回避する方法がありますが、これは実装に任されています。負荷分散の文脈では、並列SAは同様にこの問題に対する簡単な解決策です。
The IKEv2 protocol [4] states that "An IKE endpoint MUST NOT exceed the peer's stated window size for transmitted IKE requests".
[4]のIKEv2プロトコルは、「IKEエンドポイントが送信IKE要求をピアの記載ウィンドウサイズを超えてはならない」と述べています。
All IKEv2 messages are required to follow a request-response paradigm. The initiator of an IKEv2 request MUST retransmit the request, until it has received a response from the peer. IKEv2 introduces a windowing mechanism that allows multiple requests to be outstanding at a given point of time, but mandates that the sender's window should not move until the oldest message it has sent is acknowledged. Loss of even a single message leads to repeated retransmissions followed by an IKEv2 SA teardown if the retransmissions remain unacknowledged.
すべてのIKEv2メッセージは、要求応答パラダイムに従うことが求められています。それはピアから応答を受信するまでのIKEv2要求のイニシエータは、リクエストを再送しなければなりません。 IKEv2のは、複数の要求がある時点で優秀にすることができますウィンドウのメカニズムを導入し、それが送信された最も古いメッセージが確認されるまで、送信者のウィンドウが移動してはならないことを義務付け。 1つでもメッセージの損失は、再送信が認められていない残っている場合のIKEv2 SAのティアダウンが続く繰り返し再送信につながります。
An IPsec hot standby cluster is required to ensure that in the case of failover, the standby member becomes active immediately. The standby member is expected to have the exact value of the Message ID counter as the active member had before failover. Even assuming the best effort to update the Message ID values from active to standby member, the values at the standby member can still be stale due to the following reasons:
IPsecのホットスタンバイクラスタは、フェイルオーバーの場合には、スタンバイメンバが直ちにアクティブになることを確実にするために必要とされます。スタンバイメンバは、アクティブメンバがフェイルオーバ前に持っていたように、メッセージIDカウンタの正確な値を有することが期待されます。スタンバイメンバにアクティブからメッセージID値を更新するための最良の努力を仮定すると、スタンバイメンバにおける値は、まだ次の理由に失効することができます。
o The standby member is unaware of the last message that was received and acknowledged by the previously active member, as the failover event could have happened before the standby member could be updated.
スタンバイメンバーが更新される前に、フェールオーバーイベントが起きている可能性があるOスタンバイメンバーは、以前にアクティブなメンバーが受信したと認められた最後のメッセージを認識しません。
o The standby member does not have information about on-going unacknowledged requests sent by the previously active member. As a result, after the failover event, the newly active member cannot retransmit those requests.
Oスタンバイメンバーが以前にアクティブメンバによって送信される未確認の要求を行く上で、情報を持っていません。その結果、フェイルオーバー・イベントの後、新たにアクティブになったメンバーは、これらの要求を再送信することはできません。
When a standby member takes over as the active member, it can only initialize the Message ID values from the previously updated values. This would make it reject requests from the peer when these values are stale. Conversely, the standby member may end up reusing a stale Message ID value, which would cause the peer to drop the request. Eventually, there is a high probability of the IKEv2 and corresponding IPsec SAs getting torn down simply because of a transitory Message ID mismatch and retransmission of requests, negating the benefits of the high-availability cluster despite the periodic update between the cluster members.
スタンバイメンバがアクティブメンバとして引き継ぐ場合、それだけで以前に更新された値からメッセージIDの値を初期化することができます。これは、これらの値が古くなっているピアからの要求を拒否するだろう。逆に、スタンバイメンバは、ピアが要求をドロップする原因となる失効メッセージID値を、再利用に終わることができます。結局、IKEv2の高い確率があり、対応するIPsecのSAがクラスタメンバー間の定期的な更新にもかかわらず、高可用性クラスタの利点を否定する、という理由だけリクエストの一時メッセージIDの不一致と再送取り壊さ取得します。
A similar issue is also observed with IPsec anti-replay counters if anti-replay protection is enabled, which is commonly the case. Regardless of how well the ESP and AH SA counters are synchronized from the active to the standby member, there is a chance that the standby member would end up with stale counter values. The standby member would then use those stale counter values when sending IPsec packets. The peer would drop such packets, since when the anti-replay protection feature is enabled, duplicate use of counters is not allowed. Note that IPsec allows the sender to skip some counter values and continue sending with higher counter values.
アンチリプレイ保護は一般的にそうである、有効になっている場合、同様の問題は、IPsecのアンチリプレイカウンターで観察されます。かかわらず、ESPとAH SAカウンタがスタンバイメンバにアクティブから同期しているどれだけの、スタンバイメンバーが古いカウンタ値で終わるだろうと可能性があります。 IPsecパケットを送信するときに、スタンバイメンバーがそれらの古いカウンタ値を使用します。アンチリプレイ保護機能が有効になっているとき、カウンターの重複使用が許可されていないため、ピアは、このようなパケットをドロップします。 IPsecは、送信者がいくつかのカウンタ値をスキップして、高いカウンタ値を送信し続けることを可能にすることに注意してください。
We conclude that a mechanism is required to ensure that the standby member has correct Message ID and IPsec counter values when it becomes active, so that sessions are not torn down as a result of mismatched counters.
我々は、機構は、それがアクティブになったときにセッションが不一致カウンタの結果として解体されないようにスタンバイ部材は、正しいメッセージIDとのIPsecカウンタ値を持っていることを確認する必要があると結論しています。
This document defines two separate approaches to resolving the issues of mismatched IKE Message ID values and IPsec counter values.
この文書では、ミスマッチIKEメッセージID値とのIPsecカウンタ値の問題を解決するには、2つの別個のアプローチを定義します。
o In the case of IKE Message ID values, the newly active cluster member and the peer negotiate a pair of new values so that future IKE messages will not be dropped.
将来IKEメッセージがドロップされないようにO IKEメッセージID値の場合には、新たにアクティブなクラスタメンバとピアは、新しい値の組を交渉します。
o For IPsec counter values, the newly active member and the peer both increment their respective counter values, "skipping forward" by a large number, to ensure that no IPsec counters are ever reused.
IPsecのカウンタ値についてはO、新たにアクティブなメンバーとピアの両方にはIPsecのカウンタがこれまで再利用されないことを確実にするために、多数によって「前方スキップ」、それぞれのカウンタ値をインクリメントします。
Although conceptually separate, the two synchronization processes would typically take place simultaneously.
概念的に独立したが、2つの同期プロセスは、典型的には、同時に行われます。
First, the peer and the active member of the cluster negotiate their ability to support IKEv2 Message ID synchronization and/or IPsec replay counter synchronization. This is done by exchanging one or both of the IKEV2_MESSAGE_ID_SYNC_SUPPORTED and IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED notifications during the IKE_AUTH exchange. When negotiating these capabilities, the responder MUST NOT assert support of a capability unless such support was asserted by the initiator. Only a capability whose support was asserted by both parties can be used during the lifetime of the SA. The peer's capabilities with regard to this extension are part of the IKEv2 SA state, and thus MUST be shared between the cluster members.
まず、ピア及びクラスタのアクティブなメンバーは、IKEv2のメッセージIDの同期および/またはIPsecのリプレイカウンタ同期をサポートするための能力を交渉します。これは、IKE_AUTH交換中IKEV2_MESSAGE_ID_SYNC_SUPPORTEDとIPSEC_REPLAY_COUNTER_SYNC_SUPPORTED通知の一方または両方を交換することによって行われます。これらの機能を交渉する場合、そのようなサポートはイニシエータによってアサートされた場合を除き、応答者は、機能のサポートを表明してはなりません。その支援両当事者がアサートされた唯一の機能は、SAの有効期間中に使用することができます。この拡張に関してピアの機能はのIKEv2 SAの状態の一部であり、従って、クラスタ・メンバ間で共有されなければなりません。
This per-IKE SA information is shared with the other cluster members.
このあたりのIKE SA情報は、他のクラスタメンバーと共有されています。
Peer Active Member
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH,
[N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),]
[N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),]
SAi2, TSi, TSr} ---------->
<-------- HDR, SK {IDr, [CERT+], [CERTREQ+], AUTH,
[N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),]
[N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),]
SAr2, TSi, TSr}
After a failover event, the standby member MAY use the IKE Message ID and/or IPsec replay counter synchronization capability when it becomes the active member, and provided support for the capabilities used has been negotiated. Following that, the peer MUST respond to any synchronization message it receives from the newly active cluster member, subject to the rules noted below.
フェイルオーバー・イベントの後、スタンバイメンバは、アクティブメンバになったときに、IKEメッセージIDおよび/またはIPsecのリプレイカウンタ同期機能を使用して、ネゴシエートされた使用機能のためのサポートを提供するかもしれません。その次、ピアは、以下に記載の規則に従う、それは新たにアクティブなクラスタメンバから受ける任意の同期メッセージに応答しなければなりません。
After the failover event, when the standby member becomes active, it has to synchronize its SA counters with the peer. There are now four possible cases:
スタンバイメンバーがアクティブになったときにフェイルオーバー・イベントの後、それはピアとそのSAカウンタを同期しなければなりません。四つの可能なケースが存在することになります。
1. The cluster member wishes to only perform IKE Message ID value synchronization. In this case, it initiates an Informational exchange, with Message ID zero and the sole notification IKEV2_MESSAGE_ID_SYNC.
1.クラスタ・メンバは、IKEメッセージID値の同期を実行することを望みます。この場合、メッセージIDはゼロとソール通知IKEV2_MESSAGE_ID_SYNCとの情報交換を開始します。
2. If the newly active member wishes to perform only IPsec replay counter synchronization, it generates a regular IKEv2 Informational exchange using the current Message ID values, and containing the IPSEC_REPLAY_COUNTER_SYNC notification.
2.新たにアクティブメンバのみのIPsecリプレイカウンタ同期を行いたい場合は、現在のメッセージID値を使用して、正規のIKEv2 INFORMATIONAL交換を生成し、IPSEC_REPLAY_COUNTER_SYNC通知を含みます。
3. If synchronization of both counters is needed, the cluster member generates a zero-Message ID message as in case #1, and includes both notifications in this message.
両方のカウンタの同期が必要な場合3.クラスタ・メンバは、ケース＃1のようにゼロメッセージIDのメッセージを生成し、このメッセージに両方の通知を含みます。
4. Lastly, the peer may not support this extension. This is known to the newly active member (because the cluster members must share this information, as noted earlier). This case is the existing IKEv2 behavior, and the IKE and IPsec SAs may or may not survive the failover, depending on the exact state on the peer and the cluster member.
4.最後に、ピアは、この拡張機能をサポートしていない場合があります。 （クラスタメンバがこの情報を共有しなければならないので、前述したように、）これは、新たにアクティブなメンバーにはよく知られています。この場合は、既存のIKEv2動作であり、IKEおよびIPsec SAはまたはピアとクラスタメンバ上の正確な状態に応じて、フェールオーバーを生存してもしなくてもよいです。
This figure contains the IKE message exchange used for SA counter synchronization. The following subsections describe the details of the sender and receiver processing of each message.
この図は、SAのカウンタ同期に使用するIKEメッセージの交換が含まれています。以下のサブセクションでは、各メッセージの送信側と受信側の処理の詳細を述べます。
Standby [Newly Active] Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK {N(IKEV2_MESSAGE_ID_SYNC),
[N(IPSEC_REPLAY_COUNTER_SYNC)]} -------->
<--------- HDR, SK {N(IKEV2_MESSAGE_ID_SYNC)}
Alternatively, if only IPsec replay counter synchronization is desired, a normal Informational exchange is used, where the Message ID is non-zero:
唯一のIPsecリプレイカウンタ同期が望まれる場合あるいは、通常の情報交換は、メッセージIDがゼロである場合、使用されています。
Standby [Newly Active] Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK{N(IPSEC_REPLAY_COUNTER_SYNC)} -------->
<--------- HDR
The newly active member sends a request containing two counter values, one for the member (itself) and another for the peer, as well as a random nonce. We denote the values M1 and P1. The peer responds with a message containing two counter values, M2 and P2 (note that the values appear in the opposite order in the notification's payload). The goal of the rules below is to prevent an attacker from replaying a synchronization message and thereby invalidating IKE messages that are currently in process.
新しくアクティブになった部材は、二つのカウンタ値は、ピア用部材（自体）と別のもの、ならびにランダムnonceを含む要求を送信します。私たちは、値M1とP1を示しています。ピアは、二つのカウンタ値、M2及びP2（値は通知のペイロードに逆の順序で表示されることに留意されたい）を含むメッセージで応答します。以下の規則の目的は、同期メッセージを再生し、それによってプロセスに現在あるIKEメッセージを無効からの攻撃を防ぐことです。
o M1 is the next sender's Message ID to be used by the member. M1 MUST be chosen so that it is larger than any value known to have been used. It is RECOMMENDED to increment the known value at least by the size of the IKE sender window.
O M1は、メンバーによって使用される次の送信者のメッセージIDです。それが使用されていることが知られている任意の値よりも大きくなるようにM1を選択しなければなりません。 IKEの送信者ウィンドウのサイズによって少なくとも既知の値をインクリメントすることをお勧めします。
o P1 SHOULD be 1 more than the last Message ID value received from the peer, but may be any higher value.
O P1は、ピアから受信した最後のメッセージIDの値よりも1以上であるべきであるが、任意のより高い値であってもよいです。
o The member SHOULD communicate the sent values to the other cluster members, so that if a second failover event takes place, the synchronization message is not replayed. Such a replay would result in the eventual deletion of the IKE SA (see below).
第フェイルオーバー・イベントが発生した場合、同期メッセージが再生されないようにOメンバーは、他のクラスタ・メンバに送信された値を通信する必要があります。そのような再生は、IKE SA（下記参照）の最終的な欠失をもたらすであろう。
o The peer MUST silently drop any received synchronization message if M1 is lower than or equal to the highest value it has seen from the cluster. This includes any previous received synchronization messages.
M1がより低いか、それがクラスタから見た最高値に等しい場合、Oピアは静かに任意の受信した同期メッセージを削除する必要があります。これは、以前受信した同期メッセージを含んでいます。
o M2 MUST be at least the higher of the received M1, and one more than the highest sender value received from the cluster. This includes any previous received synchronization messages.
O M2は、少なくとも受信されたM1の高い、およびクラスタから受信した最高センダ値よりも1つ多くなければなりません。これは、以前受信した同期メッセージを含んでいます。
o P2 MUST be the higher of the received P1 value, and one more than the highest sender value used by the peer.
O P2は、受信したP1の値より高い、およびピアによって使用される最高センダ値よりも1つ多くなければなりません。
o The request contains a Nonce field. This field MUST be returned in the response, unchanged. A response MUST be silently dropped if the received nonce does not match the one that was sent.
O要求は、ノンスのフィールドが含まれています。このフィールドは変わらず、応答で返さなければなりません。受信nonceが送信されたものと一致しない場合、応答が静かに下げなければなりません。
o Both the request and the response MUST NOT contain any additional payloads, other than an optional IPSEC_REPLAY_COUNTER_SYNC notification in the request.
O要求と応答の両方が要求における任意IPSEC_REPLAY_COUNTER_SYNC通知以外の追加のペイロードを含んでいてはなりません。
o The request and the response MUST both be sent with a Message ID value of zero.
O要求と応答は両方ともゼロのメッセージIDの値で送らなければなりません。
Upon failover, the newly active member MUST increment its own replay counter (the counter used for outgoing traffic), so as to prevent the case of its traffic being dropped by the peer as replay. We note that IPsec allows the replay counter to skip forward by any amount. The estimate is based on the outgoing IPsec bandwidth and the frequency of synchronization between cluster members. In those implementations where it is difficult to estimate this value, the counter can be incremented by a very large number, e.g., 2**30. In the latter case, a rekey SHOULD follow shortly afterwards, to ensure that the counter never wraps around.
そのトラフィックの場合は、再生などのピアによってドロップされないように、フェイルオーバーの際に、新たにアクティブメンバは、独自のリプレイカウンタ（発信トラフィックに使用されるカウンタ）をインクリメントしなければなりません。私たちは、IPsecは、リプレイカウンタは任意の量で前方にスキップすることを可能にすることに注意してください。推定値は、送信のIPsec帯域幅とクラスタメンバ間の同期の頻度に基づいています。この値を推定することは困難であるそれらの実施態様では、カウンタは、非常に多く、例えば、2 ** 30だけ増分することができます。後者の場合、キー更新は、カウンタがラップアラウンドしないことを保証するために、その後すぐに従ってください。
Next, the cluster member estimates the number of incoming messages it might have missed, using similar logic. The member sends out an IPSEC_REPLAY_COUNTER_SYNC notification, either stand-alone or together with an IKEV2_MESSAGE_ID_SYNC notification.
次に、クラスタメンバは、それは同様のロジックを使用して、見逃しているかもしれない、着信メッセージの数を推定します。メンバーはIPSEC_REPLAY_COUNTER_SYNC通知を送信し、いずれかのスタンドアロンまたは一緒にIKEV2_MESSAGE_ID_SYNC通知で。
If the IPSEC_REPLAY_COUNTER_SYNC is included in the same message as IKEV2_MESSAGE_ID_SYNC, the peer MUST process the Message ID notification first (which might cause the entire message to be dropped as a replay). Then, it MUST increment the replay counters for all Child SAs associated with the current IKE SA by the amount requested by the cluster member.
IPSEC_REPLAY_COUNTER_SYNCをIKEV2_MESSAGE_ID_SYNC同じメッセージに含まれている場合、ピアは（メッセージ全体がリプレイとして落下させる可能性がある）最初のメッセージIDの通知を処理しなければなりません。その後、それはクラスタメンバによって要求された量によって現在のIKE SAに関連付けられているすべての子SAのリプレイカウンタを増加しなければなりません。
This section lists the new notification payload types defined by this extension.
このセクションでは、この拡張によって定義された新しい通知ペイロードタイプを示しています。
All multi-octet fields representing integers are laid out in big endian order (also known as "most significant byte first", or "network byte order").
整数を表すすべてのマルチオクテットのフィールドは、（また、「最も重要な最初のバイト」、または「ネットワークバイト順序」として知られている）ビッグエンディアン順に配置されています。
This notification payload is included in the IKE_AUTH request/ response to indicate support of the IKEv2 Message ID synchronization mechanism described in this document.
この通知ペイロードは、本書では説明のIKEv2メッセージID同期機構のサポートを示すために、IKE_AUTH要求/応答に含まれています。
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(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and 'Notify Message Type' fields are the same as described in Section 3 of [4]. The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The 'Notify Message Type' field is set to indicate IKEV2_MESSAGE_ID_SYNC_SUPPORTED (16420). There is no data associated with this notification.
「次にペイロード」、「ペイロード長」、「プロトコルID」、「SPIサイズ」、及び[4]のセクション3に記載されているようにフィールドと同じである「メッセージタイプ通知」が。 「SPIサイズ」フィールドは、SPIがこのメッセージに存在しないことを示すために0に設定しなければなりません。通知は、特定のセキュリティアソシエーションに固有ではないので、「プロトコルID」は、0に設定しなければなりません。 「ペイロード長」フィールドは、汎用ペイロード・ヘッダを含むペイロード全体のオクテットの長さに設定されています。 「通知メッセージタイプ」フィールドはIKEV2_MESSAGE_ID_SYNC_SUPPORTED（16420）を示すために設定されています。この通知に関連付けられているデータはありません。
This notification payload is included in the IKE_AUTH request/ response to indicate support for the IPsec SA replay counter synchronization mechanism described in this document.
この通知のペイロードは、この文書に記載されたIPsec SAリプレイカウンタ同期機構のサポートを示すために、IKE_AUTH要求/応答に含まれています。
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(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and 'Notify Message Type' fields are the same as described in Section 3 of [4] . The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The 'Notify Message Type' field is set to indicate IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED (16421). There is no data associated with this notification.
「次にペイロード」、「ペイロード長」、「プロトコルID」、「SPIサイズ」、及び[4]のセクション3に記載されているようにフィールドと同じである「メッセージタイプ通知」が。 「SPIサイズ」フィールドは、SPIがこのメッセージに存在しないことを示すために0に設定しなければなりません。通知は、特定のセキュリティアソシエーションに固有ではないので、「プロトコルID」は、0に設定しなければなりません。 「ペイロード長」フィールドは、汎用ペイロード・ヘッダを含むペイロード全体のオクテットの長さに設定されています。 「通知メッセージタイプ」フィールドはIPSEC_REPLAY_COUNTER_SYNC_SUPPORTED（16421）を示すために設定されています。この通知に関連付けられているデータはありません。
This notification payload type (16422) is defined to synchronize the IKEv2 Message ID values between the newly active (formerly standby) cluster member and the peer.
この通知のペイロードタイプ（16422）は、新たにアクティブ（旧スタンバイ）クラスタ・メンバとピアとの間のIKEv2メッセージID値を同期させるために定義されています。
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(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXPECTED_SEND_REQ_MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXPECTED_RECV_REQ_MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It contains the following data.
これは、次のデータが含まれています。
o Nonce Data (4 octets): The random nonce data. The data should be identical in the synchronization request and response.
O乱数データ（4つのオクテット）：ランダムな乱数データ。データは、同期要求および応答が同一でなければなりません。
o EXPECTED_SEND_REQ_MESSAGE_ID (4 octets): This field is used by the sender of this notification payload to indicate the Message ID it will use in the next request that it will send to the other protocol peer.
O EXPECTED_SEND_REQ_MESSAGE_ID（4つのオクテット）：このフィールドは、それが他のプロトコルのピアに送信することを次のリクエストで使用するメッセージIDを示すために、この通知ペイロードの送信者によって使用されています。
o EXPECTED_RECV_REQ_MESSAGE_ID (4 octets): This field is used by the sender of this notification payload to indicate the Message ID it is expecting in the next request to be received from the other protocol peer.
O EXPECTED_RECV_REQ_MESSAGE_ID（4つのオクテット）：このフィールドは、それが他のプロトコルのピアから受信する次の要求に期待されているメッセージIDを示すために、この通知ペイロードの送信者によって使用されています。
This notification payload type (16423) is defined to synchronize the IPsec SA replay counters between the newly active (formerly standby) cluster member and the peer. Since there may be numerous IPsec SAs established under a single IKE SA, we do not directly synchronize the value of each one. Instead, a delta value is sent, and all replay counters for Child SAs of this IKE SA are incremented by the same value. Note that this solution requires that either all Child SAs use Extended Sequence Numbers (ESNs) or else that no Child SA uses ESNs. This notification is only sent by the cluster.
この通知のペイロードタイプ（16423）は、新たにアクティブ（旧スタンバイ）クラスタ・メンバとピアとの間のIPsec SAのリプレイカウンタを同期させるために定義されています。単一IKE SAの下で設立され、多数のIPsecのSAがある場合がありますので、我々は直接各1の値を同期しません。代わりに、デルタ値が送信され、このIKE SAの子SAの全てのリプレイカウンタが同じ値だけ増分されています。このソリューションが必要なことに注意してくださいそのいずれかのすべての子のSAS使用拡張シーケンス番号（のESN）または誰の子SAはのESNを使用していないことを。この通知は、クラスタによって送信されます。
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(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming IPsec SA delta value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The notification payload contains the following data.
通知ペイロードは以下のデータが含まれています。
o Incoming IPsec SA delta value (4 or 8 octets): The sender requests that the peer should increment all the Child SA replay counters for the sender's incoming (the peer's outgoing) traffic by this value. The size of this field depends on the ESN bit associated with the Child SAs: if the ESN bit is 1, the field's size is 8 octets; otherwise, it is 4 octets. We note that this constrains the Child SAs of each IKE SA to either all have the ESN bit on or off.
O着信のIPsec SAのデルタ値（4つのまたは8オクテット）：ピアが、この値によって送信者、受信（ピアの発信）トラフィックのためにすべての子SAのリプレイカウンタをインクリメントする必要があり、送信者のリクエスト。このフィールドのサイズは、子供のSAに関連付けられているESNビットに依存します：ESNビットが1であれば、フィールドのサイズは8つのオクテットです。それ以外の場合は、4つのオクテットです。我々は、これはすべてがオンまたはオフにESNのビットを持っているいずれかの各IKE SAの子SAを制約することに注意してください。
This protocol does not change any of the existing IKEv2 rules regarding Message ID values.
このプロトコルは、メッセージID値に関する既存のIKEv2のルールを変更しません。
The standby member can initiate the synchronization of IKEv2 Message IDs under different circumstances.
スタンバイメンバーは、異なる状況下でのIKEv2メッセージIDの同期を開始することができます。
o When it receives a problematic IKEv2/IPsec packet, i.e., a packet outside its expected receive window.
それが問題のIKEv2 / IPsecパケットを受信すると、O、即ち、その予想外のパケットがウィンドウを受信します。
o When it has to send the first IKEv2/IPsec packet after a failover event.
Oそれは、フェールオーバーイベント後の最初のIKEv2 / IPsecパケットを送信するために持っていた場合。
o When it has just received control from the active member and wishes to update the values proactively, so that it need not start this exchange later, when sending or receiving the request.
Oそれだけアクティブメンバからの制御を受け、要求を送信または受信するとき、それは、後でこの交換を開始する必要がないように、積極的に値を更新することを希望した場合。
To clarify the first alternative: the normal IKE behavior of rejecting out-of-window messages is not changed, but such messages can still be a valid trigger for the exchange defined in this document. To avoid denial-of-service (DoS) attacks resulting from replayed messages, the peer MUST NOT initiate counter synchronization for any particular IKE SA more than once per failover event.
最初の選択肢を明確にする：外のウィンドウメッセージを拒否する通常のIKEの動作が変更されていませんが、そのようなメッセージはまだこの文書で定義された交換のための有効なトリガすることができます。リプレイメッセージから生じるサービス拒否（DoS）攻撃を回避するために、ピアは、複数回フェイルオーバー・イベント当たりより任意の特定のIKE SAのカウンタ同期を開始してはいけません。
The standby member can initiate the synchronization of IPsec SA replay counters:
スタンバイメンバーは、IPsec SAのリプレイカウンタの同期を開始することができます。
o If there has been traffic using the IPsec SA in the recent past and the standby member suspects that its replay counter may be stale.
最近の過去とスタンバイメンバーでのIPsec SAを使用してトラフィックがあった場合にはOそのリプレイカウンタが古いかもしれないかと疑っています。
Since there can be a large number of sessions at the standby member, and sending synchronization exchanges for all of them may result in overload, the standby member can choose to initiate the exchange in a "lazy" fashion: only when it has to send or expects to receive traffic from each peer. In general, the standby member is free to initiate this exchange at its discretion. Implementation considerations include the ability to survive a certain amount of traffic loss, and the capacity of a cluster member to initiate counter synchronization simultaneously with a large number of peers.
過負荷になることがあり、それらのすべてのためのスタンバイメンバでの多数のセッション、および送信同期交換が存在することができるので、スタンバイメンバーが「怠惰」な方法で交換を開始することを選択することができます：それは送ったりしている場合にのみ、各ピアからのトラフィックを受信することを期待します。一般的には、スタンバイメンバーは、その裁量で、この交換を開始するために自由です。実装の考慮事項は、トラフィック損失の一定量を生存する能力、およびピアの数が多いと同時にカウンタの同期を開始するクラスタメンバーの能力を含みます。
The straightforward definitions of message sequence numbers, retransmissions, and replay protection in IPsec and IKEv2 are strained by the failover scenarios described in this document. This section describes some policy choices that need to be made by implementations in this setting.
IPsecとのIKEv2のメッセージシーケンス番号、再送信、および再生保護の簡単な定義は、この文書で説明フェールオーバーシナリオで緊張しています。このセクションでは、この設定では実装によってなされる必要があるいくつかの政策選択を説明しています。
After sending its "receive" counter, the cluster member MUST reject (silently drop) any incoming IKE messages that are outside its declared window. A similar rule applies to the peer. Local policies vary, and strict implementations will reject any incoming IKE message arriving before Message ID synchronization is complete.
その「受信」カウンタを送信した後、クラスタメンバは、（サイレントドロップ）その宣言ウィンドウの外にある任意の着信IKEメッセージを拒絶しなければなりません。同様のルールは、ピアに適用されます。ローカルポリシーが異なる場合、およびメッセージIDの同期が完了する前に、厳格な実装が到着着信IKEメッセージを拒否します。
For IPsec, there is often a trade-off between security and reliability of the protected protocols. Here again, there is some leeway for local policy. Some implementations might accept incoming traffic that is outside the replay window for some time after the failover event, and until the counters had been synchronized. Strict implementations will only accept traffic that's inside the "safe" window.
IPsecのために、多くの場合、保護されたプロトコルの安全性と信頼性とのトレードオフがあります。ここで再び、ローカルポリシーの余裕があります。一部の実装では、フェールオーバーイベント後もしばらくはリプレイウィンドウの外にある着信トラフィックを受け入れるかもしれない、とカウンタが同期されるまで。厳格な実装では、唯一の「安全な」ウィンドウ内のトラフィックを受け入れます。
IKEv2 is normally a reliable protocol. As long as an IKE SA is valid, both peers share a single, consistent view of the IKE SA and all associated Child SAs. Failover situations as described in this document may involve forced deletion of IKE messages, resulting in inconsistencies, such as Child SAs that exist on only one of the peers. Such SAs might cause an INVALID_SPI to be returned when used by that peer. Note that Section 1.5 of [4] allows but does not mandate sending an INVALID_SPI notification in this case.
IKEv2のは、通常、信頼性の高いプロトコルです。限りIKE SAが有効であるように、両方のピアは、IKE SAと関連するすべての子SAの単一の一貫したビューを共有します。この文書で説明したように、フェイルオーバーの状況は、唯一のピアの上に存在し、そのような子供のSAなどの矛盾、その結果、IKEメッセージの強制削除を含むことができます。このようなSAはそのピアで使用された場合INVALID_SPIが戻されることがあります。 [4]を可能にするが、この場合にINVALID_SPI通知を送信強制しないのセクション1.5に留意されたいです。
The IPsecME Working Group discussed at some point a proposed set of rules for dealing with such situations. However, we believe that these situations should be rare in practice; as a result, the "default" behavior of tearing down the entire IKE SA is to be preferred over the complexity of dealing with a multitude of edge cases.
IPsecMEワーキンググループはいくつかの点でこのような状況に対処するためのルールの提案セットを議論しました。しかし、我々はこのような状況は実際には稀であるべきと信じています。結果として、全体のIKE SAを切断する「デフォルト」動作は、エッジケースの多くに対処する複雑さよりも好ましいことです。
This section goes through the sequence of steps of a typical failover event, looking at a case where the IKEv2 Message ID values are synchronized.
このセクションでは、IKEv2のメッセージID値が同期化されている場合を見て、典型的なフェイルオーバーイベントの一連の工程を経ます。
o The active cluster member and the peer device establish the session. They both announce the capability to synchronize counter information by sending the IKEV2_MESSAGE_ID_SYNC_SUPPORTED notification in the IKE_AUTH exchange.
Oアクティブなクラスタメンバとピアデバイスは、セッションを確立します。これらは両方ともIKE_AUTH交換にIKEV2_MESSAGE_ID_SYNC_SUPPORTED通知を送信することにより、カウンタ情報を同期する機能を発表します。
o Some time later, the active member dies, and a standby member takes over. The standby member sends its own idea of the IKE Message IDs (both incoming and outgoing) to the peer in an Informational message exchange with Message ID zero.
Oいくつかの時間後、アクティブ部材はダイ、およびスタンバイ部材が引き継ぎます。スタンバイ部材は、メッセージIDゼロの情報メッセージ交換にピアにIKEメッセージID（着信と発信の両方）の独自のアイデアを送信します。
o The peer first authenticates the message. The peer compares the received values with the values available locally and picks the higher value. It then updates its Message IDs with the higher values and also proposes the same values in its response.
Oピアは、最初のメッセージを認証します。ピアは、局所的に利用可能な値を有する受信された値を比較し、より高い値を選びます。これは、より高い値でそのメッセージIDを更新し、また、その応答で同じ値を提案しています。
o The peer should not wait for any pending responses while responding with the new Message ID values. For example, if the window size is 5 and the peer's window is 3-7, and if the peer has sent requests 3, 4, 5, 6, and 7 and received responses only for 4,
新しいメッセージID値で応答したまま、oピアは、保留中の応答を待つべきではありません。例えば、ウィンドウサイズが5であり、ピアのウィンドウが3-7であり、そしてピアはリクエスト3、4、5、6を送信した場合、および7のみ4への応答を受信した場合、
5, 6, and 7 but not for 3, then it should include the value 8 in its EXPECTED_SEND_REQ_MESSAGE_ID payload and should not wait for a response to message 3 any more.
5、6、および7ではなく3のために、それはそのEXPECTED_SEND_REQ_MESSAGE_IDペイロードに値8を含むべきであり、それ以上のメッセージ3への応答を待つべきではありません。
o Similarly, the peer should also not wait for pending (incoming) requests. For example, if the window size is 5 and the peer's window is 3-7, and if the peer has received requests 4, 5, 6, and 7 but not 3, then it should send the value 8 in the EXPECTED_RECV_REQ_MESSAGE_ID payload, and should not expect to receive message 3 any more.
O同様に、ピアは、（受信）要求をペンディング待つべきではありません。例えば、ウィンドウサイズが5であり、ピアのウィンドウが3-7であり、ピアが要求4、5、6、および7ではなく3を受信した場合、それはEXPECTED_RECV_REQ_MESSAGE_IDペイロードに値8を送信する必要がある場合と任意のより多くのメッセージ3を受け取ることを期待してはいけません。
The usage scenario of this IKEv2/IPsec SA counter synchronization solution is that an IKEv2 SA has been established between the active member of a hot standby cluster and a peer, followed by a failover event occurring and the standby member becoming active. The solution further assumes that the IKEv2 SA state was continuously synchronized between the active and standby members of the cluster before the failover event.
これのIKEv2 / IPsec SAのカウンタ同期溶液の使用シナリオは、IKEv2のSAは、フェイルオーバー・イベントが発生すると、スタンバイメンバーがアクティブになった後、ホットスタンバイクラスタのアクティブメンバーとピアとの間で確立されていることです。溶液をさらにのIKEv2 SAの状態を連続的にフェイルオーバー・イベント前に、クラスタのアクティブおよびスタンバイメンバー間で同期されたことを前提としています。
o Session resumption [12] assumes that a peer (client or initiator) detects the need to re-establish the session. In IKEv2/IPsec SA counter synchronization, it is the newly active member (a gateway or responder) that detects the need to synchronize the SA counter after the failover event. Also, in a hot standby cluster, the peer establishes the IKEv2/IPsec session with a single IP address that represents the whole cluster, so the peer normally does not detect the event of failover in the cluster unless the standby member takes too long to become active and the IKEv2 SA times out by use of the IKEv2 liveness check mechanism. To conclude, session resumption and SA counter synchronization after failover are mutually exclusive: they are not expected to be used together, and both features can coexist within the same implementation without affecting each other.
Oセッション再開[12]のピア（クライアントまたはイニシエータ）は、セッションを再確立する必要性を検出することを想定しています。 IKEv2 / IPsec SAのカウンタ同期では、フェイルオーバー・イベント後SAカウンタを同期させる必要性を検出し、新たにアクティブメンバ（ゲートウェイまたは応答）があります。スタンバイメンバーになる時間がかかりすぎるしない限り、ピアは通常、クラスタ内のフェイルオーバーのイベントを検出しないように。また、ホットスタンバイクラスタでは、ピアは、クラスタ全体を表す単一のIPアドレスでのIKEv2 / IPSecセッションを確立しますIKEv2の生存性チェック機構を使用することにより外アクティブおよびIKEv2のSA回。結論するには、フェイルオーバー後のセッションの再開とSAカウンタ同期は相互に排他的である：彼らは一緒に使用されることが予想されていない、との両方の機能が相互に影響を与えずに同じ実装の中に共存させることができます。
o The IKEv2 Redirect mechanism for load balancing [13] can be used either during the initial stages of SA setup (the IKE_SA_INIT and IKE_AUTH exchanges) or after session establishment. SA counter synchronization is only useful after the IKE SA has been established and a failover event has occurred. So, unlike Redirect, it is irrelevant during the first two exchanges. Redirect after the session has been established is mostly useful for timed or planned shutdown/maintenance. A real failover event cannot be detected by the active member ahead of time, and so using Redirect after session establishment is not possible in the case of failover. So, Redirect and SA counter synchronization after failover are mutually exclusive, in the sense described above.
負荷分散のためのIKEv2リダイレクト機構O [13]を使用することができるいずれかのSAのセットアップ（IKE_SA_INIT及びIKE_AUTH交換）又はセッション確立後の初期段階。 IKE SAが確立されており、フェイルオーバー・イベントが発生した後にSAのカウンタ同期にのみ有効です。だから、リダイレクトとは異なり、それは、第1と第2の交換の際には無関係です。セッションが確立された後にリダイレクトすることは時限式または計画停止/保守のために特に便利です。実際のフェイルオーバー・イベントが前もってアクティブメンバーによって検出されず、従って、セッション確立後のリダイレクトを使用すると、フェイルオーバーの場合には不可能であることができます。だから、フェイルオーバー後にリダイレクトし、SAカウンタ同期が上記の意味で、相互に排他的です。
o IKEv2 Failure Detection [8] solves a similar problem where the peer can rapidly detect that a cluster member has crashed based on a token. It is unrelated to the current scenario, because the goal in failover is for the peer not to notice that a failure has occurred.
O IKEv2の障害検出は、[8]ピアが急速にクラスタ・メンバがトークンに基づいてクラッシュしたことを検出することができる同様の問題を解決します。ピアは、障害が発生していることに注意することがないため、フェイルオーバー中に目標があるので、それは、現在のシナリオとは無関係です。
Since Message ID synchronization messages need to be sent with Message ID zero, they are potentially vulnerable to replay attacks. Because of the semantics of this protocol, these can only be denial-of-service (DoS) attacks, and we are aware of two variants.
メッセージID同期メッセージはメッセージIDゼロで送信される必要があるので、リプレイ攻撃に対して潜在的に脆弱です。このプロトコルのセマンティクスのため、これらはサービス拒否（DoS）攻撃することができ、我々は二つの変種を認識しています。
o Replay of Message ID synchronization request: This is countered by the requirement that the Send counter sent by the cluster member should always be monotonically increasing, a rule that the peer enforces by silently dropping messages that contradict it.
OメッセージID同期要求のリプレイは：これはクラスタメンバによって送信された送信カウンタは常に単調に増加しなければならない要件、ピアは黙ってそれを否定メッセージをドロップすることによって強制するルールによって打ち消されます。
o Replay of the Message ID synchronization response: This is countered by sending the nonce data along with the synchronization payload. The same nonce data has to be returned in the response. Thus, the standby member will accept a reply only for the current request. After it receives a valid response, it MUST NOT process the same response again and MUST discard any additional responses.
メッセージID同期応答のOリプレイ：これは、同期ペイロードと共に乱数データを送信することによって相殺されます。同じ乱数データは、応答で返される必要があります。このように、スタンバイメンバーは、現在の要求に対する応答を受け付けます。それが有効なレスポンスを受信した後、再度同じ応答を処理してはならないし、追加の応答を捨てなければなりません。
As mentioned in Section 7, triggering counter synchronization by out-of-window, potentially replayed messages could open a DoS vulnerability. This risk is mitigated by the solution described in that section.
外のウィンドウでカウンタ同期をトリガする、第7節で述べたように、潜在的に再生されたメッセージは、DoSの脆弱性を開くことができます。このリスクは、そのセクションで説明したソリューションによって軽減されます。
This document introduces four new IKEv2 Notification Message types as described in Section 6. The new Notify Message Types have been assigned values as follows.
次のように新しい通知メッセージタイプに値が割り当てられている第6節で説明したようにこの文書は4つの新しいIKEv2の通知メッセージの種類を紹介します。
+-------------------------------------+-------+
| Name | Value |
+-------------------------------------+-------+
| IKEV2_MESSAGE_ID_SYNC_SUPPORTED | 16420 |
| IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED | 16421 |
| IKEV2_MESSAGE_ID_SYNC | 16422 |
| IPSEC_REPLAY_COUNTER_SYNC | 16423 |
+-------------------------------------+-------+
We would like to thank Pratima Sethi and Frederic Detienne for their review comments and valuable suggestions for the initial version of the document.
私たちは、彼らのレビューコメントや文書の最初のバージョンのための貴重な提案のためPratimaセティとフレデリックDetienneに感謝したいと思います。
We would also like to thank the following people (in alphabetical order) for their review comments and valuable suggestions: Dan Harkins, Paul Hoffman, Steve Kent, Tero Kivinen, David McGrew, and Pekka Riikonen.
ダンハーキンズ、ポール・ホフマン、スティーブケント、TERO Kivinen、デビッドマグリュー、およびペッカRiikonen：我々はまた、彼らのレビューコメントと貴重な提案のために（アルファベット順）以下の人々に感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[2]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[3] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[3]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[4] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[4]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2（IKEv2の）"、RFC 5996、2010年9月。
[5] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[5]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[6] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, October 2010.
[6]ニール、Y.、 "IPsecのクラスタの問題に関する声明"、RFC 6027、2010年10月。
[7] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[7] Nadas、S.、エド。、 "IPv4とIPv6の仮想ルータ冗長プロトコル（VRRP）バージョン3"、RFC 5798、2010年3月。
[8] Nir, Y., Ed., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)", RFC 6290, June 2011.
[8]ニール、Y.、エド。、Wierbowski、D.、Detienne、F.、およびP.セティ、RFC 6290、2011年6月 "インターネット鍵交換プロトコル（IKE）のクイッククラッシュ検出方法"。
[9] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[9] Housley氏、R.、RFC 3686、2004年1月 "のAdvanced Encryption Standard（AES）のIPsecカプセル化セキュリティペイロード（ESP）、カウンタモードを使用しました"。
[10] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[10] Viega、J.とD.マグリュー、 "IPsecのカプセル化セキュリティペイロード（ESP）におけるガロア/カウンタモード（GCM）の使用"、RFC 4106、2005年6月。
[11] McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic", RFC 6054, November 2010.
[11]マグリュー、D.とB.ヴァイス、RFC 6054 "グループトラフィックを保護するためにカプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）とカウンターモードの使用"、2010年11月。
[12] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
[12]シェファー、Y.およびH. Tschofenig、 "インターネット鍵交換プロトコルバージョン2（IKEv2の）セッション再開"、RFC 5723、2010年1月。
[13] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, November 2009.
[13] Devarapalli、V.およびK. Weniger、2009年11月、RFC 5685 "インターネット鍵交換プロトコルバージョン2（IKEv2の）ためのメカニズムをリダイレクト"。
Appendix A. IKEv2 Message ID Sync Examples
付録A. IKEv2のメッセージID同期の例
This (non-normative) section presents some examples that illustrate how the IKEv2 Message ID values are synchronized. We use a tuple notation, denoting the two counters EXPECTED_SEND_REQ_MESSAGE_ID and EXPECTED_RECV_REQ_MESSAGE_ID on each protocol party as (EXPECTED_SEND_REQ_MESSAGE_ID, EXPECTED_RECV_REQ_MESSAGE_ID).
この（非標準）セクションには、IKEv2のメッセージIDの値が同期している様子を示すいくつかの例を示します。我々は（EXPECTED_SEND_REQ_MESSAGE_ID、EXPECTED_RECV_REQ_MESSAGE_ID）などの各プロトコルのパーティ上の2つのカウンタEXPECTED_SEND_REQ_MESSAGE_IDとEXPECTED_RECV_REQ_MESSAGE_IDを示す、タプル表記を使用します。
Note that if the IKE message counters are already synchronized (as in the first example), we expect the numbers to be reversed between the two sides. If one protocol party intends to send the next request as 4, then the other expects the next received request to be 4.
IKEメッセージカウンタが既に（最初の例のように）同期している場合、我々は数字は、2つの側の間に反転されることを期待することに留意されたいです。 1つのプロトコルのパーティが4として次の要求を送信しようとした場合、もう一方は、次の受信要求が4であることを期待しています。
A.1. Normal Failover -- Example 1
A.1。通常のフェイルオーバー - 例1
Standby (Newly Active) Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sync Request (0, 5) -------->
Peer has the values (5, 0), so it sends
<------------- (5, 0) as the Sync Response
In this example, the peer has most recently sent an IKE request with Message ID 4, and has never received a request. So the peer's expected values for the next pair of messages are (5, 0). These are the same values as received from the member, and therefore they are sent as-is.
この例では、ピアは、最近メッセージID 4とのIKE要求を送信した、と依頼を受けたことはありません。だから、メッセージの次のペアのためのピアの期待値は（5,0）です。これらは、メンバーから受信したと同じ値であるので、それらはそのままで送信されます。
A.2. Normal Failover -- Example 2
A.2。通常のフェイルオーバー - 例2
Standby (Newly Active) Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sync Request (2, 3) -------->
Peer has the values (4, 5), so it sends
<------------- (4, 5) as the Sync Response
In this example, the peer has most recently sent an IKE message with the Message ID 3, and received one with ID 4. So the peer's expected values for the next pair of messages are (4, 5). These are both higher than the corresponding values just received from the member (the order of tuple members is reversed when doing this comparison!), and therefore they are sent as-is.
したがって、メッセージの次の対のためのピアの期待値は（4,5）であり、この例では、ピアは、最近メッセージID 3とIKEメッセージを送信しており、ID 4とのいずれかを受け取りました。これらは、両方のちょうどメンバーから受信した対応する値（この比較を行う際にタプルメンバーの順序が逆転する！）よりも高くなっているので、それらはそのままで送信されます。
A.3. Normal Failover -- Example 3
A.3。通常のフェイルオーバー - 例3
Standby (Newly Active) Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sync Request (2, 5) -------->
Peer has the values (2, 4), so it sends
<-------------(5, 4) as the Sync Response
In this example, the newly active member expects to send the next IKE message with ID 2. It sends an expected receive value of 5, which is higher than the last ID value it has seen from the peer, because it believes some incoming messages may have been lost. The peer has last sent a message with ID 1, and received one with ID 3, indicating that a couple of messages sent by the previously active member had not been synchronized into the other member. So the peer's next expected (send, receive) values are (2, 4). The peer replies with the maximum of the received and the expected value for both send and receive counters: (max(2, 5), max(4, 2)) = (5, 4).
それはいくつかの受信メッセージができると考えているので、この例では、新たにアクティブ部材は、IDそれがピアから見た最後のID値より高い5の受信期待値を、送信2と次IKEメッセージを送信することを期待します失われています。ピアは、最後のID 1を持つメッセージを送信し、そして以前にアクティブメンバによって送信されたメッセージのカップルが他のメンバーに同期されていなかったことを示し、ID 3とのいずれかを受けました。だから、相手の次の期待（受信、送信）値が（2、4）。ピアが受信さの最大で応答との両方のための期待値がカウンタを送受信：（MAX（2,5）、MAX（4,2））=（5,4）。
A.4. Simultaneous Failover
A.4。同時フェイルオーバー
In the case of simultaneous failover, both sides send their synchronization requests simultaneously. The eventual outcome of synchronization consists of the higher counter values. This is demonstrated in the following figure.
同時フェイルオーバーが発生した場合には、双方が同時に彼らの同期要求を送信します。同期の最終的な結果は、より高いカウンタ値から成ります。これは、次の図に示されています。
Standby (Newly Active) Member Peer - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
スタンバイ（新しくアクティブになった）メンバーピア - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sync Request (4,4) ----->
<-------------- Sync Request (5,5)
Sync Response (5,5) ---->
<-------- Sync Response (5,5)
Authors' Addresses
著者のアドレス
Raj Singh (editor) Cisco Systems, Inc. Divyashree Chambers, B Wing, O'Shaugnessy Road Bangalore, Karnataka 560025 India
ラジ・シン（エディタ）は、シスコシステムズ、株式会社Divyashreeチェンバース、B棟、O'Shaugnessyロードバンガロール、カルナータカ560025インド
Phone: +91 80 4301 3320 EMail: rsj@cisco.com
電話：+91 80 4301 3320 Eメール：rsj@cisco.com
Kalyani Garigipati Cisco Systems, Inc. Divyashree Chambers, B Wing, O'Shaugnessy Road Bangalore, Karnataka 560025 India
Kalyani Garigipatiシスコシステムズ、株式会社Divyashreeチェンバース、B棟、O'Shaugnessyロードバンガロール、カルナータカ560025インド
Phone: +91 80 4426 4831 EMail: kagarigi@cisco.com
電話：+91 80 4426 4831 Eメール：kagarigi@cisco.com
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim St. Tel Aviv 67897 Israel
ヨアフニールは、ポイント・ソフトウェア・テクノロジーズ株式会社5 Hasolelim聖テルアビブ67897イスラエルをチェック
EMail: ynir@checkpoint.com
メールアドレス：ynir@checkpoint.com
Yaron Sheffer Porticor Cloud Security
ヤロンシェファーPorticorクラウドセキュリティ
EMail: yaronf.ietf@gmail.com
メールアドレス：yaronf.ietf@gmail.com
Dacheng Zhang Huawei Technologies Ltd.
DAは張HU A技術有限公司にあり
EMail: zhangdacheng@huawei.com
メールアドレス：zhangdacheng@huawei.com