[要約] RFC 6311は、IKEv2/IPsecの高可用性をサポートするためのプロトコルを定義しています。その目的は、ネットワークの冗長性と信頼性を向上させ、セキュアな通信を確保することです。
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
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）クラスターとして実装されることがよくあります。ただし、IPSEC HAクラスタリング、特にインターネットキーエクスチェンジプロトコルバージョン2（IKEV2）クラスタリングには多くの問題があります。以前のドキュメント「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.
このドキュメントでは、IKEV2プロトコルの拡張機能を定義して、一般的に展開されているホットスタンバイクラスターの「IPSECクラスター問題ステートメント」の主な問題を解決し、他の問題に実装アドバイスを提供します。解決される主な問題は、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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].
Internet Key Exchange Protocolバージョン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ベースのVPNSのホットスタンバイクラスター実装の場合、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:
このドキュメントでは、IKEV2プロトコルの拡張機能を定義して、IKEメッセージID同期とIPSEC SAリプレイカウンター同期の主な問題を解決し、他の問題に対処するための実装アドバイスを提供します。以下は、このドキュメントに記載されているソリューションの要約です。
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.
このドキュメントでは、IKEV2メッセージIDとIPSEC HAクラスターのコンテキストでの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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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カウンター同期」は、クラスターの1人のメンバーとピア間の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 「Hot Standby Cluster」または「HS Cluster」は、一度にメンバーの1人だけがアクティブであるクラスターです。このメンバーは「アクティブ」メンバーとも呼ばれ、他のメンバーは「スタンバイ」メンバーと呼ばれます。仮想ルーター冗長プロトコル（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 「Peer」は、ホットスタンバイクラスターとの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 「複数のフェイルオーバー」とは、3人以上のメンバーがいるクラスターで、M1からM2からM3まで、たとえば急速に連続して複数のフェールオーバーイベントが発生する状況です。実装がこの状況を処理できること、つまり、古いフェールオーバーをまだ処理している場合でも、新しいフェイルオーバーイベントを処理することができることが私たちの目標です。
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]).
o 「IPSECリプレイカウンター」は、セキュリティペイロード（ESP）シーケンス番号または拡張シーケンス番号（[2]のセクション2.2）、または認証ヘッダー（AH）プロトコルのそれぞれのフィールド（[3]のセクション2.5）のカプセル化のセキュリティペイロード（ESP）シーケンス番号（[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
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は、クラスターを透過的にするには、多くの状態を同期する必要があると述べています。そのデータの実際のボリュームは非常に実装に依存しており、同じ実装であっても、データの量は大きく異なる場合があります。ドメイン間VPNに使用されるIPSECゲートウェイは、他の1ダースのゲートウェイを備えており、8時間ごとに再キーにされたSASを使用するには、リモートアクセスに使用され、10,000人のクライアントをサポートするのと同様のゲートウェイよりもはるかに少ない同期トラフィックが必要です。これは、カウンターの同期がSAの数に比例し、データがほとんど必要ないためであり、SAのセットアップには多くのデータが必要です。さらに、リモートアクセスIKEとIPSEC SAのセットアップは、特定の時間に発生する傾向があるため、10,000人のクライアントを搭載したゲートウェイの例では、午前9時に1秒あたり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.
これらの方法が不十分な場合、一部のSASでは、状態全体が同期されていないことは賢明かもしれません。代わりに、SAの存在の兆候のみが同期されます。これは、問題のある声明[6]のセクション3.7で説明されているように）と組み合わせて、特定のピアからのトラフィックが実際のフェールオーバーが発生する前に別のメンバーに届かないことを保証します。それが起こった場合、[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を同期せず、各メンバーに1つずつ複数のアウトバウンドSASを作成することです。このオプションの問題は、ピアがこれらの複数の並列SASを冗長であると見なし、そのうちの1つを除くすべてを取り壊す可能性があることです。
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では、特に複数の並列SASが許可されていますが、これに与えられた理由は、異なるサービス品質（QOS）属性を持つ複数のSASを持つことです。したがって、これはQOSで動作するIKEV2実装の新しい要件ではありませんが、QoSメカニズムが使用されていない場合でも、IPSECピアは複数の並列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では、2つの異なるSASに同じセキュリティパラメーターインデックス（SPI）番号を割り当てる2つのクラスターメンバーの問題について説明します。この動作は、[5]のセクション4.4.2.1に違反します。SPIスペースの分割、同期チャネル上のリクエスト応答、ロックメカニズムなど、実装がそのような衝突を回避できるようにするためのいくつかのスキームがあります。これらは十分に堅牢で利用可能であるため、RFC 4301 [5]のセクション4.4.2.1のルールを例外にする必要はないと考えており、実装を解決するためにこの問題を残すことができます。クラスターメンバーは、同じSPIで複数のインバウンドSASを生成してはなりません。
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.
カウンターモード（CTR）[9]やガロア/カウンターモード（GCM）[10]などのカウンターモード暗号を含むSASには、さらに別の合併症があります。このようなモードの初期ベクトルを繰り返す必要はなく、送信者はカウンターや線形フィードバックシフトレジスタ（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衝突の問題と同じように、初期ベクターの衝突を回避する方法があり、これは実装に任されています。負荷共有のコンテキストでは、並列SASもこの問題に対する単純な解決策です。
The IKEv2 protocol [4] states that "An IKE endpoint MUST NOT exceed the peer's stated window size for transmitted IKE requests".
IKEV2プロトコル[4]は、「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は、特定の時点で複数のリクエストを未解決のものにすることを可能にするウィンドウ化メカニズムを導入しますが、送信された最古のメッセージが認められるまで送信者のウィンドウが移動しないことを義務付けています。単一のメッセージを失うことで、再送信が繰り返されることに続いて、再送信が承認されていない場合に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.
o IKEメッセージID値の場合、新しくアクティブなクラスターメンバーとピアは、将来のIKEメッセージが削除されないように、新しい値のペアを交渉します。
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.
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リプレイカウンター同期をサポートする能力をネゴシエートします。これは、IKEV2_MESSAGE_ID_SYNC_SUPPORTEDおよびIPSEC_REPLAY_COUNTER_SUPORTEDのいずれかまたは両方を交換することによって行われます。これらの能力を交渉するとき、そのようなサポートがイニシエーターによって主張されない限り、レスポンダーは能力のサポートを主張してはなりません。SAの寿命の間に、両当事者によってサポートが主張された能力のみを使用できます。この拡張機能に関するピアの機能は、IKEV2 SA状態の一部であるため、クラスターメンバー間で共有する必要があります。
This per-IKE SA information is shared with the other cluster members.
このPer-y-ysの情報は、他のクラスターメンバーと共有されます。
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カウンターをピアと同期させる必要があります。現在、4つの可能なケースがあります。
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情報交換を生成し、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 SASは、ピアとクラスターメンバーの正確な状態に応じて、フェールオーバーに耐えられない場合があります。
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.
新しくアクティブなメンバーは、2つのカウンター値を含むリクエストを送信します。1つはメンバー（それ自体）、もう1つはピア用、およびランダムなNonCEを送信します。値M1とP1を示します。ピアは、M2とP2の2つのカウンター値を含むメッセージで応答します（通知のペイロードでは、値は逆に表示されることに注意してください）。以下のルールの目標は、攻撃者が同期メッセージを再生するのを防ぎ、それにより現在進行中の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 メンバーは、送信された値を他のクラスターメンバーに通知する必要があります。これにより、2回目のフェイルオーバーイベントが発生した場合、同期メッセージが再生されないようにします。このようなリプレイは、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.
o ピアは、M1がクラスターから見た最高値以下の場合、受信した同期メッセージを静かにドロップする必要があります。これには、以前に受信した同期メッセージが含まれます。
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の高く、クラスターから受信した最高の送信者値を超えるものでなければなりません。これには、以前に受信した同期メッセージが含まれます。
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値の高く、ピアが使用する最高の送信者値を超えている必要があります。
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フィールドが含まれています。このフィールドは、変更されずに応答で返される必要があります。受信した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通知を送信します。
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サイズ」フィールドを0に設定して、SPIがこのメッセージに存在しないことを示す必要があります。通知は特定のセキュリティ関連に固有のものではないため、「プロトコル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サイズ」フィールドを0に設定して、SPIがこのメッセージに存在しないことを示す必要があります。通知は特定のセキュリティ関連に固有のものではないため、「プロトコルID」を0に設定する必要があります。「ペイロード長」フィールドは、汎用ペイロードヘッダーを含むペイロード全体のオクテットの長さに設定されます。「Notifyメッセージタイプ」フィールドは、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 NonCeデータ（4オクテット）：ランダムNonCeデータ。データは、同期要求と応答で同一である必要があります。
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 expection_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 expection_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リプレイカウンターを同期するために定義されています。単一のIKESAの下に確立された多数のIPSEC SAがある可能性があるため、各IKEの値を直接同期することはありません。代わりに、デルタ値が送信され、このIKE SAの子SASのすべてのリプレイカウンターは同じ値で増加します。このソリューションでは、すべての子供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リプレイカウンターをインクリメントすることを要求します。このフィールドのサイズは、子SASに関連付けられたESNビットに依存します。ESNビットが1の場合、フィールドのサイズは8オクテットです。それ以外の場合は、4オクテットです。これにより、各IKE SAの子SASがESNビットのオンまたはオフのいずれかを制限することに注意してください。
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.
o 問題のあるIKEV2/IPSECパケット、つまり、予想される受信ウィンドウの外側のパケットを受信した場合。
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.
o 最近のIPSEC SAを使用してトラフィックがあり、スタンバイメンバーがそのリプレイカウンターが古くなっている可能性があると疑っている場合。
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.
スタンバイメンバーに多数のセッションがある可能性があり、それらすべての同期交換を送信する可能性があるため、スタンバイメンバーは「怠zy」ファッションで交換を開始することを選択できます。各ピアからトラフィックを受けることを期待しています。一般に、スタンバイメンバーは、その裁量でこの交換を自由に開始できます。実装の考慮事項には、一定量のトラフィック損失を乗り切る能力と、多数のピアと同時にカウンター同期を開始するクラスターメンバーの能力が含まれます。
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と関連するすべての子供SASの単一の一貫したビューを共有しています。このドキュメントで説明されているようにフェールオーバーの状況には、IKEメッセージの強制削除が含まれる場合があり、その結果、ピアの1つだけに存在する子SASなどの矛盾が生じます。そのようなSAは、そのピアが使用すると無効な_spiが返される可能性があります。[4]のセクション1.5は、この場合に無効な_SPI通知を送信することを許可しているが義務付けられていないことに注意してください。
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 アクティブなクラスターメンバーとピアデバイスがセッションを確立します。どちらも、IKEV2_MESSAGE_ID_SUPPORTED通知をIKE_AUTH Exchangeで送信することにより、カウンター情報を同期する機能を発表します。
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, 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.
o ピアは、新しいメッセージID値で応答しながら、保留中の応答を待つべきではありません。たとえば、ウィンドウのサイズが5で、ピアのウィンドウが3-7の場合、ピアがリクエスト3、4、5、6、および7を送信し、4、5、6、および7に対してのみ回答を受信した場合3の場合、spedced_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の場合、ピアが3ではなくリクエストを受け取った場合、3つのリクエストを受け取った場合、equided_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.
o 負荷分散のためのIKEV2リダイレクトメカニズム[13]は、SAセットアップの初期段階（IKE_SA_INITおよびIKE_AUTH交換）またはセッションの確立後のいずれかを使用できます。SAカウンター同期は、IKE SAが確立され、フェイルオーバーイベントが発生した後にのみ有用です。したがって、リダイレクトとは異なり、最初の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）攻撃のみである可能性があり、2つのバリアントを認識しています。
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.
o メッセージIDの同期応答のリプレイ：これは、同期ペイロードとともにNonCeデータを送信することにより反論されます。応答で同じNONCEデータを返す必要があります。したがって、スタンバイメンバーは、現在のリクエストに対してのみ返信を受け入れます。有効な応答を受け取った後、同じ応答を再度処理してはならず、追加の応答を破棄する必要があります。
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で述べたように、window外でのカウンター同期をトリガーすると、再生される潜在的に再生されるメッセージは、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通知メッセージタイプを紹介します。新しいNotifyメッセージタイプには、次のように値が割り当てられています。
+-------------------------------------+-------+
| 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 SethiとFrederic 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.
また、レビューのコメントと貴重な提案について、次の人々（アルファベット順）に感謝したいと思います：ダン・ハーキンス、ポール・ホフマン、スティーブ・ケント、テロ・キビネン、デビッド・マクグリュー、ペッカ・ライコネン。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[2] Kent、S。、「セキュリティペイロード（ESP）のカプセル化IP」、RFC 4303、2005年12月。
[3] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[3] Kent、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] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン2（IKEV2）」、RFC 5996、2010年9月。
[5] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[5] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[6] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, October 2010.
[6] NIR、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.、ed。、「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] Nir、Y.、Ed。、Wierbowski、D.、Detienne、F。、およびP. Sethi、「インターネットキーエクスチェンジプロトコル（IKE）のクイッククラッシュ検出方法」、RFC 6290、2011年6月。
[9] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[9] Housley、R。、「IPSECがセキュリティペイロードをカプセル化した高度な暗号化標準（AES）カウンターモード（ESP）を使用して」、RFC 3686、2004年1月。
[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. McGrew、「セキュリティペイロードをカプセル化するIPSECでのガロア/カウンターモード（GCM）の使用（ESP）」、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] McGrew、D。およびB. Weis、「セキュリティペイロード（ESP）と認証ヘッダー（AH）をカプセル化するカウンターモードを使用して、グループトラフィックを保護する」、RFC 6054、2010年11月。
[12] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
[12] Sheffer、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、「インターネットキーエクスチェンジプロトコルバージョン2（IKEV2）のリダイレクトメカニズム」、RFC 5685、2009年11月。
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値がどのように同期されるかを示すいくつかの例を示します。Tuple Notationを使用して、各プロトコルパーティーで2つのカウンターがexpect_send_req_message_idおよびspect_recv_req_message_idを（spected_send_req_message_id、speed_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メッセージカウンターが既に同期している場合（最初の例のように）、数字が両側の間で逆になると予想されることに注意してください。1つのプロトコルパーティが次のリクエストを4として送信する予定の場合、もう1つは次の受信リクエストが4になると予想します。
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）です。これらはメンバーから受信した値と同じであるため、そのまま送信されます。
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.
この例では、ピアは最近、メッセージID 3でIKEメッセージを送信し、ID 4でIKEメッセージを受け取りました。したがって、次のメッセージのピアの期待値は（4、5）です。これらはどちらもメンバーから受け取ったばかりの対応する値よりも高くなります（この比較を行うと、タプルメンバーの順序が逆転します！）したがって、それらはそのまま送信されます。
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).
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
Raj Singh（編集者）Cisco Systems、Inc。Divyashree Chambers、B Wing、O'Shaugnessy Road Bangalore、Karnataka 560025 India
Phone: +91 80 4301 3320
EMail: rsj@cisco.com
Kalyani Garigipati Cisco Systems, Inc. Divyashree Chambers, B Wing, O'Shaugnessy Road Bangalore, Karnataka 560025 India
Kalyani Garigipati Cisco Systems、Inc。Divyashree Chambers、B Wing、O'Shaugnessy Road Bangalore、Karnataka 560025 India
Phone: +91 80 4426 4831
EMail: kagarigi@cisco.com
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim St. Tel Aviv 67897 Israel
yoav nirチェックポイントソフトウェアテクノロジーズLtd. 5 Hasolelim St. Tel Aviv 67897イスラエル
EMail: ynir@checkpoint.com
Yaron Sheffer Porticor Cloud Security
Yaron Sheffer Porticor Cloud Security
EMail: yaronf.ietf@gmail.com
Dacheng Zhang Huawei Technologies Ltd.
Dacheng Zhang Huawei Technologies Ltd.
EMail: zhangdacheng@huawei.com