Internet Engineering Task Force (IETF) Y. Nir
Request for Comments: 6027 Check Point
Category: Informational October 2010
ISSN: 2070-1721
IPsec Cluster Problem Statement
Abstract
抽象
This document defines the terminology, problem statement, and requirements for implementing Internet Key Exchange (IKE) and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled in order to allow peers to interoperate with clusters from different vendors. Agreed upon terminology, problem statement, and requirements will allow IETF working groups to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations.
この文書では、専門用語、問題文の、およびクラスタ上のインターネットキー交換（IKE）とIPsecを実装するための要件を定義します。また、ピアが異なるベンダーのクラスタと相互運用できるようにするために充填する必要がある既存の標準とその実装のギャップを説明しています。用語、問題文の合意した、との要件は、IETFのワーキンググループは、クラスタの実装を簡素化するためのIPsec / IKEv2のメカニズムの開発を検討することができます。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6027.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6027で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 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
1.1. Conventions Used in This Document ..........................3
2. Terminology .....................................................3
3. The Problem Statement ...........................................5
3.1. Scope ......................................................5
3.2. A Lot of Long-Lived State ..................................6
3.3. IKE Counters ...............................................6
3.4. Outbound SA Counters .......................................6
3.5. Inbound SA Counters ........................................7
3.6. Missing Synch Messages .....................................8
3.7. Simultaneous Use of IKE and IPsec SAs by Different
Members ....................................................8
3.7.1. Outbound SAs Using Counter Modes ....................9
3.8. Different IP Addresses for IKE and IPsec ..................10
3.9. Allocation of SPIs ........................................10
4. Security Considerations ........................................10
5. Acknowledgements ...............................................11
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................11
IKEv2, as described in [RFC5996], and IPsec, as described in [RFC4301] and others, allows deployment of VPNs between different sites as well as from VPN clients to protected networks.
[RFC4301]などに記載されているように[RFC5996]に記載されているようのIKEv2、およびIPsecは、異なるサイト間のVPNの展開は、保護されたネットワークへのVPNクライアントから、ならびに可能。
As VPNs become increasingly important to the organizations deploying them, there is a demand to make IPsec solutions more scalable and less prone to down time, by using more than one physical gateway to either share the load or back each other up, forming a "cluster" (see Section 2). Similar demands have been made in the past for other critical pieces of an organization's infrastructure, such as DHCP and DNS servers, Web servers, databases, and others.
VPNはそれらを展開組織にますます重要になるにつれて、いずれかのバックお互いをアップロードを共有したりするために複数の物理ゲートウェイを使用することにより、IPsecのソリューションは、よりスケーラブルでダウンタイムが生じにくいようにする需要は、「クラスタを形成し、そこにあります「（第2節を参照）。同様の要求は、DHCPやDNSサーバー、Webサーバー、データベース、および他のような組織のインフラストラクチャの他の重要な部分のために、過去に行われています。
IKE and IPsec are, in particular, less friendly to clustering than these other protocols, because they store more state, and that state is more volatile. Section 2 defines terminology for use in this document and in the envisioned solution documents.
彼らはより多くの状態を保存するため、IKEおよびIPsecは、特に、これらの他のプロトコルよりもクラスタリングにはあまり友好的であり、その状態は、より揮発性です。第2節では、この文書に記載されていると想定されるソリューションのドキュメントで使用する用語を定義します。
In general, deploying IKE and IPsec in a cluster requires such a large amount of information to be synchronized among the members of the cluster that it becomes impractical. Alternatively, if less information is synchronized, failover would mean a prolonged and intensive recovery phase, which negates the scalability and availability promises of using clusters. In Section 3, we will describe this in more detail.
一般的に、クラスタ内のIKEとIPsecを展開する情報のような大規模な量が、それは非現実的となるクラスタのメンバ間で同期することが必要です。以下の情報が同期されている場合は別の方法として、フェイルオーバークラスタを使用しての拡張性と可用性の約束を否定し、長期かつ集中的な回復局面を、意味します。第3節では、我々はこれをより詳細に説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
"Single Gateway" is an implementation of IKE and IPsec enforcing a certain policy, as described in [RFC4301].
「単一のゲートウェイは、」[RFC4301]に記載されているように、特定のポリシーを実施IKEとIPsecの実装です。
"Cluster" is a set of two or more gateways, implementing the same security policy, and protecting the same domain. Clusters exist to provide both high availability through redundancy and scalability through load sharing.
「クラスタ」とは、同じセキュリティポリシーを実装すると、同じドメインを保護し、二つ以上のゲートウェイのセットです。クラスタは、負荷分散による冗長性とスケーラビリティによる高可用性の両方を提供するために存在します。
"Member" is one gateway in a cluster.
「メンバーは、」クラスタ内の1つのゲートウェイです。
"Availability" is a measure of a system's ability to perform the service for which it was designed. It is measured as the percentage of time a service is available from the time it is supposed to be available. Colloquially, availability is sometimes expressed in "nines" rather than percentage, with 3 "nines" meaning 99.9% availability, 4 "nines" meaning 99.99% availability, etc.
「可用性」は、それが設計されたサービスを実行するためのシステムの能力の尺度です。これは、サービスがそれを利用できることになっている時間から利用できる時間の割合として測定されます。口語、可用性が時々等99.9％の可用性、99.99％の可用性を意味4「ナイン」を意味する3「ナイン」と、「ナイン」ではなくパーセンテージで表され
"High Availability" is a property of a system, not a configuration type. A system is said to have high availability if its expected down time is low. High availability can be achieved in various ways, one of which is clustering. All the clusters described in this document achieve high availability. What "high" means depends on the application, but usually is 4 to 6 "nines" (at most 0.5-50 minutes of down time per year in a system that is supposed to be available all the time.
「高可用性」は、システムではなく、コンフィギュレーション・タイプのプロパティです。システムは、その期待ダウンタイムが低い場合、高可用性を持つと言われています。高可用性クラスタリングそのうちの1つは、様々な方法で達成することができます。本文書に記載されている全てのクラスタは、高可用性を実現します。どのような「高い」とは、アプリケーションに依存するが、通常は4〜6「ナイン」のすべての時間利用できるようになっているシステムでは年間ダウンタイムの（高々0.5〜50分です。
"Fault Tolerance" is a property related to high availability, where a system maintains service availability, even when a specified set of fault conditions occur. In clusters, we expect the system to maintain service availability, when one or more of the cluster members fails.
「フォールトトレランス」は、システムが故障条件の指定されたセットが発生した場合でも、サービスの可用性を維持し、高可用性に関連するプロパティです。クラスタでは、我々は、クラスタメンバーの一つ以上に障害が発生した場合、システムは、サービスの可用性を維持することを期待します。
"Completely Transparent Cluster" is a cluster where the occurrence of a fault is never visible to the peers.
「完全に透明なクラスタは、」障害の発生がピアに見えることはありませんクラスタです。
"Partially Transparent Cluster" is a cluster where the occurrence of a fault may be visible to the peers.
「部分的に透明なクラスタ」は、障害の発生がピアに見ることができるクラスタです。
"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 "standbys". The Virtual Router Redundancy Protocol (VRRP) ([RFC5798]) is one method of building such a cluster.
「ホットスタンバイクラスタ」、または「HSクラスタは、」メンバーの一つだけが一度にアクティブであるクラスタです。 （S）他は、「スタンバイ」と呼ばれるのに対し、このメンバーはまた、「アクティブ」メンバーと呼ばれています。仮想ルータ冗長プロトコル（VRRP）（[RFC5798]）は、このようなクラスタを構築する1つの方法です。
"Load Sharing Cluster", or "LS Cluster" is a cluster where more than one of the members may be active at the same time. The term "load balancing" is also common, but it implies that the load is actually balanced between the members, and this is not a requirement.
「負荷分散クラスタ」、または「LSクラスタ」は、メンバーの2つ以上が同時にアクティブであり得るクラスタです。用語「ロード・バランシング」も一般的ですが、それは負荷がメンバー間の実際のバランスであり、これは必要条件ではないことを意味します。
"Failover" is the event where one member takes over some load from some other member. In a hot standby cluster, this happens when a standby member becomes active due to a failure of the former active member, or because of an administrator command. In a load sharing cluster, this usually happens because of a failure of one of the members, but certain load-balancing technologies may allow a particular load (such as all the flows associated with a particular child Security Association (SA)) to move from one member to another to even out the load, even without any failures.
「フェイルオーバー」とは、一つのメンバーが他のメンバーからのいくつかの負荷を引き継ぐイベントです。ホットスタンバイクラスタでは、これは、スタンバイメンバーがアクティブになったときにより元のアクティブメンバの故障が起こる、またはので、管理者コマンドの。負荷分散クラスタでは、これは通常ので、メンバーの一人の障害の発生したが、特定の負荷分散技術は、から移動する（例えば、特定の子のSecurity Association（SA）に関連付けられたすべてのフローのような）特定の負荷を可能にすることができますでも、どんな障害が発生することなく、負荷を均等にする別のメンバー。
"Tight Cluster" is a cluster where all the members share an IP address. This could be accomplished using configured interfaces with specialized protocols or hardware, such as VRRP, or through the use of multicast addresses, but in any case, peers need only be configured with one IP address in the Peer Authentication Database.
「タイトなクラスタは、」すべてのメンバーがIPアドレスを共有するクラスタです。これは、VRRPとして、またはマルチキャストアドレスを使用することにより、特殊なプロトコルまたはハードウェアで構成されたインターフェースを使用して達成することができるが、いずれの場合にも、ピアは、ピア認証データベース内の1つのIPアドレスが設定されるだけでよいです。
"Loose Cluster" is a cluster where each member has a different IP address. Peers find the correct member using some method such as DNS queries or the IKEv2 redirect mechanism ([RFC5685]). In some cases, a member's IP address(es) may be allocated to another member at failover.
「ルーズクラスタ」は、各メンバーが異なるIPアドレスを持つクラスターです。ピアは、DNSクエリ又はIKEv2のリダイレクト機構（[RFC5685]）のようないくつかの方法を使用して、正しいメンバーを見つけます。いくつかの場合において、会員のIPアドレス（ES）は、フェイルオーバー時に他の部材に割り当てることができます。
"Synch Channel" is a communications channel among the cluster members, which is used to transfer state information. The synch channel may or may not be IP based, may or may not be encrypted, and may work over short or long distances. The security and physical characteristics of this channel are out of scope for this document, but it is a requirement that its use be minimized for scalability.
「のSynchチャネルは」状態情報を転送するために使用されるクラスタ・メンバ間の通信チャネルです。同期チャネルはよく、またはIPベースされていないか、または暗号化してもしなくてもよい、と短いまたは長い距離にわたって動作する可能性があります。このチャネルのセキュリティと物理的特性は、このドキュメントの範囲外ですが、それはその使用が拡張性を最小限にすることが必要条件です。
This section starts by scoping the problem, and goes on to list each of the issues encountered while setting up a cluster of IPsec VPN gateways.
このセクションでは、問題をスコープで開始し、およびIPsec VPNゲートウェイのクラスタをセットアップ中に発生した問題のそれぞれをリストするために行きます。
This document will make no attempt to describe the problems in setting up a generic cluster. It describes only problems related to the IKE/IPsec protocols.
この文書では、一般的なクラスタのセットアップに問題を説明する試みをしないでしょう。これは、IKE / IPsecプロトコルに関連した問題のみを説明しています。
The problem of synchronizing the policy between cluster members is out of scope, as this is an administrative issue that is not particular to either clusters or to IPsec.
これはどちらかのクラスタへやIPsecに特定のない行政課題であるとして、クラスタメンバー間の政策を同期の問題は、範囲外です。
The interesting scenario here is VPN, whether inter-domain or remote access. Host-to-host transport mode is not expected to benefit from this work.
ここで興味深いシナリオは、ドメイン間またはリモートアクセスするかどうか、VPNです。ホスト間トランスポートモードは、この作品の恩恵を受けることが期待されていません。
We do not describe in full the problems of the communication channel between cluster members (the Synch Channel), nor do we intend to specify anything in this space later. Specifically, mixed-vendor clusters are out of scope.
私たちは、クラスタメンバー（Synchのチャネル）との間の通信チャネルの完全な問題では説明しません、また私たちは、この後のスペースに何も指定していきます。具体的には、混合ベンダークラスタは範囲外です。
The problem statement anticipates possible protocol-level solutions between IKE/IPsec peers in order to improve the availability and/or performance of VPN clusters. One vendor's IPsec endpoint should be able to work, optimally, with another vendor's cluster.
問題文は、可用性および/またはVPNクラスタのパフォーマンスを向上させるために、IKE / IPsecピア間の可能なプロトコルレベルのソリューションを見込んでいます。ワンベンダーのIPsecのエンドポイントは、他のベンダーのクラスタと、最適に、働くことができるはずです。
IKE and IPsec have a lot of long-lived state:
IKEおよびIPsecは長命状態の多くを持っています：
o IKE SAs last for minutes, hours, or days, and carry keys and other information. Some gateways may carry thousands to hundreds of thousands of IKE SAs.
分、時間、または日の最後のIKE SAがO、およびキーやその他の情報を運びます。いくつかのゲートウェイには、IKE SAの数十万人に数千人を運ぶことができます。
o IPsec SAs last for minutes or hours, and carry keys, selectors, and other information. Some gateways may carry hundreds of thousands of such IPsec SAs.
数分または数時間のために最後のIPsec SAは、O、およびキー、セレクタ、およびその他の情報を運びます。一部のゲートウェイは、IPsecのSAの数十万人を運ぶことができます。
o SPD (Security Policy Database) cache entries. While the SPD is unchanging, the SPD cache changes on the fly due to narrowing. Entries last at least as long as the SAD (Security Association Database) entries, but tend to last even longer than that.
SPD（セキュリティポリシーデータベース）キャッシュエントリO。 SPDは不変ですが、原因の狭窄にその場でSPDキャッシュの変更。エントリーの最後の少なくとも同じ長SAD（セキュリティアソシエーションデータベース）などのエントリが、それでも長いものより長持ちする傾向があります。
A naive implementation of a cluster would have no synchronized state, and a failover would produce an effect similar to that of a rebooted gateway. [RFC5723] describes how new IKE and IPsec SAs can be recreated in such a case.
クラスタの単純な実装には同期状態を持たないであろう、そしてフェイルオーバーが再起動ゲートウェイと同様の効果を生成します。 [RFC5723]は、新しいIKEとIPsec SAはこのような場合に再現することができる方法について説明します。
We can overcome the first problem described in Section 3.2, by synchronizing states -- whenever an SA is created, we can synch this new state to all other members. However, those states are not only long lived, they are also ever changing.
SAが作成されるたびに、我々は他のすべてのメンバーにこの新しい状態を同期さすることができます - 私たちは、最初の状態を同期させることにより、3.2節で説明した問題を克服することができます。しかし、それらの状態が唯一の長命されていない、彼らはまた、常に変化しています。
IKE has message counters. A peer MUST NOT process message n until after it has processed message n-1. Skipping message IDs is not allowed. So a newly active member needs to know the last message IDs both received and transmitted.
IKEは、メッセージカウンタを持っています。ピアは、メッセージN-1を処理した後まで、メッセージnを処理してはいけません。メッセージIDをスキップすることはできません。そこで、新たにアクティブになったメンバーは、最後のメッセージID受信と送信の両方を知っている必要があります。
One possible solution is to synchronize information about the IKE message counters after every IKE exchange. This way, the newly active member knows what messages it is allowed to process, and what message IDs to use on IKE requests, so that peers process them. This solution may be appropriate in some cases, but may be too onerous in systems with a lot of SAs. It also has the drawback that it never recovers from the missing synch message problem, which is described in Section 3.6.
一つの可能な解決策は、すべてのIKE交換後のIKEメッセージカウンタについての情報を同期させることです。この方法では、新たにアクティブになったメンバーは、処理するために、許可されているメッセージを知っている、とピアがそれらを処理するように、IKE要求にどのようなメッセージIDを使用します。このソリューションは、いくつかのケースでは適切かもしれないが、SAの多いシステムでは、あまりにも面倒かもしれません。それはまた、セクション3.6で説明されて行方不明同期メッセージの問題から回復したことがないという欠点があります。
The Encapsulating Security Payload (ESP) and Authentication Header (AH) have an optional anti-replay feature, where every protected packet carries a counter number. Repeating counter numbers is considered an attack, so the newly active member MUST NOT use a replay counter number that has already been used. The peer will drop those packets as duplicates and/or warn of an attack.
カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）は、すべての保護されたパケットは、カウンタ番号を運ぶオプションのアンチリプレイ機能を持っています。カウンターの数字を繰り返すこと、攻撃と考えられているので、新たにアクティブになったメンバーが既に使用されているリプレイカウンタ番号を使用してはなりません。ピアは重複としてそれらのパケットをドロップする、および/または攻撃を警告します。
Though it may be feasible to synchronize the IKE message counters, it is almost never feasible to synchronize the IPsec packet counters for every IPsec packet transmitted. So we have to assume that at least for IPsec, the replay counter will not be up to date on the newly active member, and the newly active member may repeat a counter.
それはIKEメッセージカウンタを同期することは可能かもしれないが、それが送信され、すべてのIPsecパケットにIPsecパケットカウンタを同期させることがほとんどない可能ではありません。だから我々は、少なくともIPsecのため、リプレイカウンタが新たにアクティブメンバーに最新でないことを前提としなければならない、と新たにアクティブになったメンバーは、カウンタを繰り返してもよいです。
A possible solution is to synch replay counter information, not for each packet emitted, but only at regular intervals, say, every 10,000 packets or every 0.5 seconds. After a failover, the newly active member advances the counters for outbound IPsec SAs by 10,000 packets. To the peer, this looks like up to 10,000 packets were lost, but this should be acceptable, as neither ESP nor AH guarantee reliable delivery.
可能な解決策は、各パケットが放出されていないため、リプレイカウンタ情報を同期さすることであるが、唯一の定期的な間隔で、たとえば、10,000パケットごとまたはごとに0.5秒。フェイルオーバー後、新たにアクティブになったメンバーは万個のパケットによってアウトバウンドのIPsec SAのカウンタを進めます。どちらもESPもAHは、信頼性の高い配信を保証してピアに、これは以下のようになります最大10,000パケットが、失われたが、これは許容されるべきです。
An even tougher issue is the synchronization of packet counters for inbound IPsec SAs. If a packet arrives at a newly active member, there is no way to determine whether or not this packet is a replay. The periodic synch does not solve this problem at all, because suppose we synchronize every 10,000 packets, and the last synch before the failover had the counter at 170,000. It is probable, though not certain, that packet number 180,000 has not yet been processed, but if packet 175,000 arrives at the newly active member, it has no way of determining whether or not that packet has already been processed. The synchronization does prevent the processing of really old packets, such as those with counter number 165,000. Ignoring all counters below 180,000 won't work either, because that's up to 10,000 dropped packets, which may be very noticeable.
でも厳しい問題は、インバウンドのIPsec SAのパケットカウンタの同期です。パケットが新たにアクティブメンバーで到着した場合、このパケットはリプレイであるかどうかを判断する方法はありません。フェイルオーバーが17万でカウンターを持っていた前に、定期的な同期は、我々は10,000パケットごとに同期させるとしているため、すべてでこの問題を解決し、最後の同期はありません。それは、特定されていないが、そのパケット番号18万がまだ処理されていない可能性があるが、パケット175,000は、新たにアクティブメンバーに到着した場合、そのパケットはすでに処理されたか否かを判断する方法はありません。同期は、このようなカウンタ番号165000を持つものとして本当に古いパケットの処理を防止しません。それは、最大10,000のですが、非常に顕著でありうる、パケットをドロップするので18万以下のすべてのカウンタを無視すると、いずれかの動作しません。
The easiest solution is to learn the replay counter from the incoming traffic. This is allowed by the standards, because replay counter verification is an optional feature (see Section 3.2 in [RFC4301]). The case can even be made that it is relatively secure, because non-attack traffic will reset the counters to what they should be, so an attacker faces the dual challenge of a very narrow window for attack, and the need to time the attack to a failover event. Unless the attacker can actually cause the failover, this would be very difficult. It should be noted, though, that although this solution is acceptable as far as RFC 4301 goes, it is a matter of policy whether this is acceptable.
最も簡単な解決策は、着信トラフィックからリプレイカウンタを学ぶことです。リプレイカウンタの検証はオプション機能（[RFC4301]でセクション3.2を参照）であるため、これは、標準で許可されています。場合はそうであっても、攻撃者はへの攻撃時に攻撃、および必要性のための非常に狭い窓の二重の課題に直面している、非攻撃トラフィックは、彼らがどうあるべきかにカウンタをリセットされますので、それは、比較的安全であると判断することができますフェイルオーバーイベント。攻撃者は、実際にフェイルオーバーを引き起こす可能性がない限り、これは非常に困難であろう。この解決策は限りRFC 4301が行くとして許容ですが、それはこれが許容できるかどうかポリシーの問題であること、しかし、注意すべきです。
Another possible solution to the inbound IPsec SA problem is to rekey all child SAs following a failover. This may or may not be feasible depending on the implementation and the configuration.
インバウンドのIPsec SAの問題に対する別の可能な解決策は、フェイルオーバー後にすべての子SAをリキーすることです。これは、または実装や構成に応じて実行可能であってもなくてもよいです。
The synch channel is very likely not to be infallible. Before failover is detected, some synchronization messages may have been missed. For example, the active member may have created a new child SA using message n. The new information (entry in the SAD and update to counters of the IKE SA) is sent on the synch channel. Still, with every possible technology, the update may be missed before the failover.
同期チャネルは無謬ではないことが非常に可能性があります。フェイルオーバーが検出される前に、いくつかの同期のメッセージが見逃されている可能性があります。例えば、アクティブメンバは、メッセージNを使用して新しい子SAを作成してもよいです。新しい情報（IKE SAのカウンタへのSADと更新のエントリは）同期チャネル上で送信されます。それでも、あらゆる可能な技術で、更新は、フェイルオーバーの前に逃したことがあります。
This is a bad situation, because the IKE SA is doomed. The newly active member has two problems:
IKE SAが運命にあるので、これは、悪い状況です。新たにアクティブになったメンバーには2つの問題があります。
o It does not have the new IPsec SA pair. It will drop all incoming packets protected with such an SA. This could be fixed by sending some DELETEs and INVALID_SPI notifications, if it wasn't for the other problem.
Oこれは、新しいIPsec SAのペアを持っていません。それは、そのようなSAで保護されているすべての着信パケットをドロップします。それは他の問題のためではなかった場合、これは、いくつかの削除とINVALID_SPI通知を送信することにより固定することができます。
o The counters for the IKE SA show that only request n-1 has been sent. The next request will get the message ID n, but that will be rejected by the peer. After a sufficient number of retransmissions and rejections, the whole IKE SA with all associated IPsec SAs will get dropped.
IKE SAのカウンタOのみ要求N-1が送信されたことを示します。次の要求は、メッセージID nを取得しますが、それは、ピアによって拒否されます。再送信と拒否十分な数の後、すべての関連のIPsecのSAと全体IKE SAがドロップされます。
The above scenario may be rare enough that it is acceptable that on a configuration with thousands of IKE SAs, a few will need to be recreated from scratch or using session resumption techniques. However, detecting this may take a long time (several minutes) and this negates the goal of creating a cluster in the first place.
上記のシナリオは、IKE SAの数千有する構成に、いくつかのスクラッチ又はセッション再開技術を使用してから再作成する必要があることは許容可能であることは十分に稀であってもよいです。しかし、これを検出することは、長い時間（数分）に乗り、これが最初の場所でクラスタを作成するという目標を否定することがあります。
For load sharing clusters, all active members may need to use the same SAs, both IKE and IPsec. This is an even greater problem than in the case of hot standby clusters, because consecutive packets may need to be sent by different members to the same peer gateway.
負荷共有クラスタの場合、すべてのアクティブなメンバーが同じSAS、IKEとIPsecの両方を使用する必要があります。連続するパケットが同じピアゲートウェイに異なるメンバーによって送信される必要があるかもしれないので、これは、ホットスタンバイクラスタの場合よりもさらに大きな問題です。
The solution to the IKE SA issue is up to the implementation. It's possible to create some locking mechanism over the synch channel, or else have one member "own" the IKE SA and manage the child SAs for all other members. For IPsec, solutions fall into two broad categories.
IKE SAの問題を解決するには、実装次第です。これは、同期チャネルを介して、いくつかのロック機構を作成するか、他の一つのメンバー「自分」IKE SAを持っており、他のすべてのメンバーの子SAを管理することが可能です。 IPsecのために、解決策は2つの広いカテゴリーに分類されます。
The first is the "sticky" category, where all communications with a single peer, or all communications involving a certain SPD cache entry go through a single peer. In this case, all packets that match any particular SA go through the same member, so no synchronization of the replay counter needs to be done. Inbound processing is a "sticky" issue (no pun intended), because the packets have to be processed by the correct member based on peer and the Security Parameter Index (SPI), and most load balancers will not be able to match the SPIs to the correct member, unless stickiness extends to all traffic with a particular peer. Another disadvantage of sticky solutions is that the load tends to not distribute evenly, especially if one SA covers a significant portion of IPsec traffic.
最初は、単一のピアとのすべての通信、または特定のSPDキャッシュエントリを含むすべての通信は、単一のピアを通過する「スティッキー」カテゴリです。この場合、いずれかの特定のSAは、同じ部材を通って行く一致するすべてのパケットので、リプレイカウンタの同期が行われる必要があります。パケットがピアに基づいて、正しいメンバーおよびセキュリティパラメータインデックス（SPI）で処理しなければならない、とほとんどのロードバランサがにSPIを一致させることができなくなりますので、着信処理は、「粘着性」の問題（しゃれ意図）であります正しい部材、粘着性は、特定のピアとのすべてのトラフィックに延びていない限り。粘着性溶液の別の欠点は、一SAがIPsecトラフィックの大部分を覆っている場合は特に、負荷が均等に分配しない傾向があることです。
The second is the "duplicate" category, where the child SA is duplicated for each pair of IPsec SAs for each active member. Different packets for the same peer go through different members, and get protected using different SAs with the same selectors and matching the same entries in the SPD cache. This has some shortcomings:
第二は、子SAは、それぞれのアクティブなメンバーのためのIPsec SAの各ペアのために複製されたカテゴリを、「複製」です。同じピアの異なるパケットは、異なるメンバーを通過し、同じセレクタと異なるSAを使用したとSPDキャッシュ内の同じエントリに一致する保護されます。これは、いくつかの欠点があります：
o It requires multiple parallel SAs, for which the peer has no use. Section 2.8 of [RFC5996] specifically allows this, but some implementation might have a policy against long-term maintenance of redundant SAs.
Oそれは、ピアが全く使用を持たないため、複数の並列SAを必要とします。 [RFC5996]のセクション2.8には、これを具体的に許可しますが、いくつかの実装では、冗長SAの長期維持に対するポリシーを持っているかもしれません。
o Different packets that belong to the same flow may be protected by different SAs, which may seem "weird" to the peer gateway, especially if it is integrated with some deep-inspection middleware such as a firewall. It is not known whether this will cause problems with current gateways. It is also impossible to mandate against this, because the definition of "flow" varies from one implementation to another.
同じフローに属しているO異なるパケットは、それがファイアウォールなどのいくつかのディープインスペクションミドルウェアと統合されている場合は特に、ピア・ゲートウェイに「奇妙」に見えるかもしれません異なるのSAによって保護されていてもよいです。現在のゲートウェイとの問題を引き起こすかどうかは知られていません。 「フロー」の定義は一の実施から別のものに変わるので、これに対して強制することも不可能です。
o Reply packets may arrive with an IPsec SA that is not "matched" to the one used for the outgoing packets. Also, they might arrive at a different member. This problem is beyond the scope of this document and should be solved by the application, perhaps by forwarding misdirected packets to the correct gateway for deep inspection.
Oパケットは、発信パケットのために使用されるものに「マッチ」されていないのIPsec SAで到着することが返信。また、彼らは別のメンバーに到着するかもしれません。この問題は、この文書の範囲を超えて、おそらく深い検査のために正しいゲートウェイに誤ったパケットを転送することによって、アプリケーションによって解決されなければなりません。
For SAs involving counter mode ciphers such as Counter Mode (CTR) ([RFC3686]) or Galois/Counter Mode (GCM) ([RFC4106]) there is yet another complication. The initial vector for such modes MUST NOT be repeated, and senders use methods such as counters or linear feedback shift registers (LFSRs) to ensure this. For an SA shared between more than one active member, or even failing over from one member to another, the cluster members need to make sure that they do not generate the same initial vector. See [COUNTER_MODES] for a discussion of this problem in another context.
SAは、このようなカウンタモード（CTR）（[RFC3686]）またはガロア/カウンタ・モード（GCM）（[RFC4106]）としてカウンタモード暗号を伴うための別の合併症がまだ存在します。そのようなモードのための初期ベクトルを繰り返してはいけません、そして送信者は、これを保証するために、このようなカウンタまたは線形フィードバックシフトレジスタ（LFSR）などのメソッドを使用しています。 SAは、複数のアクティブなメンバー間で共有、あるいは別のメンバーからのフェールオーバーの場合は、クラスタメンバーは、彼らが同じ初期ベクトルを生成しないことを確認する必要があります。別のコンテキストでこの問題の議論のための[COUNTER_MODES]を参照してください。
In many implementations there are separate IP addresses for the cluster, and for each member. While the packets protected by tunnel mode child SAs are encapsulated in IP headers with the cluster IP address, the IKE packets originate from a specific member, and carry that member's IP address. This may be done so that IPsec traffic bypasses the load balancer for greater scalability. For the peer, this looks weird, as the usual thing is for the IPsec packets to come from the same IP address as the IKE packets. Unmodified peers may drop such packets.
多くの実装では、クラスタの、および各メンバーのための個別のIPアドレスが存在します。トンネルモード子のSAによって保護されたパケットがクラスタIPアドレスを持つIPヘッダでカプセル化されているが、IKEパケットは、特定のメンバーに由来し、そのメンバのIPアドレスを運びます。 IPsecトラフィックが大きいスケーラビリティのためのロードバランサを迂回するようにこれが行うことができます。 IPsecパケットは、IKEパケットと同じIPアドレスから来るのをいつもの事はあるとして、ピアの場合、これは、奇妙に見えます。修飾されていないピアは、このようなパケットをドロップすることがあります。
One obvious solution is to use some fancy capability of the IKE host to change things so that IKE packets also come out of the cluster IP address. This can be achieved through NAT or through assigning multiple addresses to interfaces. This is not, however, possible for all implementations, and will not reduce load on the balancer.
1つの明白な解決策は、IKEパケットが、クラスタIPアドレスから出てくるように物事を変更するにはIKEホストのいくつかの空想の機能を使用することです。これは、NATを介して、またはインターフェイスに複数のアドレスを割り当てることによって達成することができます。これは、しかし、すべての実装のために可能ではない、とバランサーの負荷を軽減しません。
[ARORA] discusses this problem in greater depth, and proposes another solution, that does involve protocol changes.
【ARORA】大きい深さでこの問題を議論し、プロトコルの変更を伴わない別の解決策を提案しています。
The SPI associated with each child SA, and with each IKE SA, MUST be unique relative to the peer of the SA. Thus, in the context of a cluster, each cluster member MUST generate SPIs in a fashion that avoids collisions (with other cluster members) for these SPI values. The means by which cluster members achieve this requirement is a local matter, outside the scope of this document.
それぞれの子SAと、各IKE SAに関連付けられたSPIは、SAのピアに対して一意でなければなりません。したがって、クラスタのコンテキストで、各クラスタメンバは、これらのSPI値に対して（他のクラスタメンバーと）衝突を回避する方法でSPIを生成しなければなりません。クラスタメンバーは、この要件を達成する手段は、この文書の範囲外で、ローカルの問題です。
Implementations running on clusters MUST be as secure as implementations running on single gateways. In other words, no extension or interpretation used to allow operation in a cluster may facilitate attacks that are not possible for single gateways.
クラスタ上で実行されている実装は、単一のゲートウェイ上で実行されているの実装と同様に安全でなければなりません。換言すれば、拡張子または解釈は、クラスタ内の動作は、単一のゲートウェイに不可能な攻撃を容易にすることができる可能にするために使用されません。
Moreover, thought must be given to the synching requirements of any protocol extension to make sure that it does not create an opportunity for denial-of-service attacks on the cluster.
また、思考が、それは、クラスタ上のサービス妨害（DoS）攻撃の機会を作成していないことを確認するために、任意のプロトコル拡張のパク要件に与えられなければなりません。
As mentioned in Section 3.5, allowing an inbound child SA to failover to another member has the effect of disabling replay counter protection for a short time. Though the threat is arguably low, it is a policy decision whether this is acceptable.
インバウンド子SAは、別のメンバーにフェイルオーバーすることができ、3.5節で述べたように、短い時間のためにリプレイカウンタ保護を無効にする効果があります。脅威は間違いなく低いですが、これは許容可能であるかどうかを政策決定です。
Section 3.7 describes the problem of the two directions of a flow being protected by two SAs that are not part of a matched pair or that are not even being processed by the same cluster member. This is not a security problem as far as IPsec is concerned because IPsec has policy at the IP, protocol and port level only. However, many IPsec implementations are integrated with stateful firewalls, which need to see both sides of a flow. Such implementations may have to forward packets to other members for the firewall to properly inspect the traffic.
セクション3.7は、流れの二つの方向の問題が一致ペアの一部ではないか、それがあっても同一のクラスタ・メンバによって処理されていない2つのSAによって保護されて記載されています。 IPsecはIP、プロトコルおよびポートのみレベルでポリシーを持っているので、これは限りIPsecが懸念しているセキュリティ上の問題ではありません。しかし、多くのIPsec実装は、流れの両側を参照する必要がステートフルファイアウォール、と統合されています。このような実装は適切にトラフィックを検査するため、ファイアウォールのために他のメンバーにパケットを転送する必要があります。
This document is the collective work, and includes contribution from many people who participate in the IPsecME working group.
この文書では、集合著作物であり、IPsecMEワーキンググループに参加し、多くの人々からの寄与を含んでいます。
The editor would particularly like to acknowledge the extensive contribution of the following people (in alphabetical order): Jitender Arora, Jean-Michel Combes, Dan Harkins, David Harrington, Steve Kent, Tero Kivinen, Alexey Melnikov, Yaron Sheffer, Melinda Shore, and Rodney Van Meter.
エディタは、特に以下の人（アルファベット順）の大規模な貢献を認めるしたいと思います：Jitenderアローラ、ジャン・ミッシェル・ザコームス、ダンハーキンズ、デヴィッド・ハリントン、スティーブケント、TERO Kivinen、アレクセイ・メルニコフ、ヤロンシェファー、メリンダ・ショア、およびロドニー・バン・メーター。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", September 2010.
[RFC5996]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2（IKEv2の）"、2010年9月。
[ARORA] Arora, J. and P. Kumar, "Alternate Tunnel Addresses for IKEv2", Work in Progress, April 2010.
【ARORA]アローラ、J.およびP.クマール、 "IKEv2のための代替トンネルアドレス"、進歩、2010年4月ワーク。
[COUNTER_MODES] McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic", Work in Progress, March 2010.
[COUNTER_MODES]マグリュー、D.とB.ヴァイス、進歩、2010年3月ワーク「グループトラフィックを保護するためにカプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）とカウンターモードの使用」。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode", RFC 3686, January 2009.
[RFC3686] Housley氏、R.、RFC 3686 "のAdvanced Encryption Standard（AES）カウンタモードの使用" を、2009年1月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106] Viega、J.とD.マグリュー、 "IPsecのカプセル化セキュリティペイロード（ESP）におけるガロア/カウンタモード（GCM）の使用"、RFC 4106、2005年6月。
[RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for IKEv2", RFC 5685, November 2009.
[RFC5685] Devarapalli、V.およびK. Wenigerは、RFC 5685、2009年11月、 "IKEv2のためのメカニズムをリダイレクト"。
[RFC5723] Sheffer, Y. and H. Tschofenig, "IKEv2 Session Resumption", RFC 5723, January 2010.
[RFC5723]シェファー、Y.およびH. Tschofenig、 "のIKEv2セッション再開"、RFC 5723、2010年1月。
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)", RFC 5798, March 2010.
[RFC5798] Nadas、S.、 "仮想ルータ冗長プロトコル（VRRP）"、RFC 5798、2010年3月。
Author's Address
著者のアドレス
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st. Tel Aviv 67897 Israel
ヨアフニールは、ポイント・ソフトウェア・テクノロジーズ株式会社5 Hasolelim STをチェックしてください。テルアビブ67897イスラエル
EMail: ynir@checkpoint.com
メールアドレス：ynir@checkpoint.com