[要約] 要約：RFC 6027は、IPsecクラスタの問題を特定し、解決策を提案するものです。 目的：IPsecクラスタの問題を理解し、効果的な解決策を開発するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) Y. Nir
Request for Comments: 6027 Check Point
Category: Informational October 2010
ISSN: 2070-1721
IPsec Cluster Problem Statement
IPSECクラスター問題ステートメント
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 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
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.
[RFC5996]で説明されているように、[RFC5996]とIPSECは、[RFC4301]などで説明されているように、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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
「クラスター」は、同じセキュリティポリシーを実装し、同じドメインを保護する2つ以上のゲートウェイのセットです。クラスターは、冗長性と負荷共有を通じてスケーラビリティを通じて高可用性の両方を提供するために存在します。
"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.
「可用性」は、設計されたサービスを実行するシステムの能力の尺度です。これは、サービスが利用可能になるはずの時間から利用可能な時間の割合として測定されます。口語的には、可用性はパーセンテージではなく「ナイン」で表現されることがあり、3「ナイン」は99.9％の可用性、4「ナイン」を意味する99.99％の可用性などを意味します。
"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.
「フォールトトレランス」とは、指定された一連の障害条件が発生した場合でも、システムがサービスの可用性を維持する高可用性に関連するプロパティです。クラスターでは、クラスターメンバーの1つ以上が失敗した場合、システムがサービスの可用性を維持することを期待しています。
"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.
「Hot Standby Cluster」または「HS Cluster」は、メンバーの1人だけがいつでもアクティブであるクラスターです。このメンバーは「アクティブな」メンバーとも呼ばれ、他のメンバーは「スタンバイ」と呼ばれます。仮想ルーター冗長プロトコル（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クラスター」は、複数のメンバーが同時にアクティブになる可能性があるクラスターです。「負荷分散」という用語も一般的ですが、それはメンバー間で実際に負荷がバランスされていることを意味し、これは要件ではありません。
"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.
「フェイルオーバー」とは、あるメンバーが他のメンバーから何らかの負荷を引き継ぐイベントです。ホットスタンバイクラスターでは、これは、以前のアクティブメンバーの障害または管理者コマンドのためにスタンバイメンバーがアクティブになったときに発生します。負荷共有クラスターでは、これは通常、メンバーの1人が失敗したために発生しますが、特定の負荷分散技術は特定の負荷（特定の子セキュリティ協会（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.
「同期チャネル」は、クラスターメンバー間の通信チャネルであり、状態情報を転送するために使用されます。同期チャネルは、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.
クラスターメンバー（同期チャネル）間の通信チャネルの問題については完全には説明しません。また、後でこのスペースで何かを指定するつもりはありません。具体的には、混合ベンダークラスターは範囲外です。
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.
o Ike SASは数分、時間、または日々続き、キーやその他の情報を持ち運びます。一部のゲートウェイには、数千から数十万のIke SASが運ばれる場合があります。
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.
o IPSEC SASは数分または時間の間続き、キー、セレクター、およびその他の情報を運びます。一部のゲートウェイには、このようなIPSEC SASの数十万人が搭載される場合があります。
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.
o SPD（セキュリティポリシーデータベース）キャッシュエントリ。SPDは変化しませんが、SPDキャッシュは狭窄のためにその場で変化します。エントリは、少なくともSAD（Security Association Database）エントリと同じくらい長く続きますが、それよりも長持ちする傾向があります。
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 SASをどのように再現できるかを説明しています。
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.
セクション3.2で説明されている最初の問題を、状態を同期させることにより克服できます。SAが作成されるたびに、この新しい状態を他のすべてのメンバーに同期させることができます。しかし、これらの州は長年生きているだけでなく、常に変化しています。
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.
考えられる解決策の1つは、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の場合、リプレイカウンターは新しくアクティブなメンバーの最新のものではなく、新しくアクティブなメンバーがカウンターを繰り返す可能性があると仮定する必要があります。
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 SASのカウンターを10,000個のパケットで進めます。ピアにとって、これは最大10,000個のパケットが失われたように見えますが、ESPもAHも信頼できる配達を保証することはないため、これは受け入れられるはずです。
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 SASのパケットカウンターの同期です。パケットが新しくアクティブなメンバーに到着した場合、このパケットがリプレイであるかどうかを判断する方法はありません。定期的な同期は、この問題をまったく解決しません。これは、10,000個のパケットごとに同期し、フェールオーバーの前の最後の同期が170,000のカウンターを持っていると仮定するからです。パケット番号180,000がまだ処理されていないことは確かではありませんが、パケット175,000が新しくアクティブなメンバーに到着した場合、そのパケットがすでに処理されているかどうかを判断する方法はありません。同期は、カウンター番号165,000を持つものなど、非常に古いパケットの処理を防ぎます。180,000未満のすべてのカウンターを無視することも機能しません。これは、最大10,000個のドロップされたパケットであるため、非常に目立つ可能性があります。
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の問題に対するもう1つの可能な解決策は、フェイルオーバー後にすべての子供SASを再キーすることです。これは、実装と構成に応じて実行可能である場合とそうでない場合があります。
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.
o IKE SAのカウンターは、要求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 SASを使用した構成では、いくつかをゼロから再作成するか、セッション再開技術を使用する必要があることが許容されるほどまれである可能性があります。ただし、これを検出するには長い時間（数分）かかる場合があり、これにより、最初にクラスターを作成するという目標が否定されます。
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.
負荷共有クラスターの場合、すべてのアクティブメンバーは、IKEとIPSECの両方で同じSASを使用する必要がある場合があります。これは、ホットスタンバイクラスターの場合よりもさらに大きな問題です。これは、連続したパケットを同じピアゲートウェイに別のメンバーから送信する必要があるためです。
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の問題の解決策は、実装次第です。同期チャネルにロックメカニズムを作成するか、1人のメンバーがIKE SAを「所有」し、他のすべてのメンバーの子供SASを管理することができます。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.
1つ目は「粘着性」カテゴリです。ここでは、単一のピアとのすべての通信、または特定のSPDキャッシュエントリを含むすべての通信が単一のピアを通過します。この場合、特定のSAに一致するすべてのパケットは同じメンバーを通過するため、リプレイカウンターの同期を行う必要はありません。インバウンド処理は、ピアとセキュリティパラメーターインデックス（SPI）に基づいて正しいメンバーによってパケットを処理する必要があり、ほとんどのロードバランサーがSPIを一致させることができないため、「粘着性のある」問題（しゃれは意図していません）です。正しいメンバー、粘着性が特定のピアですべてのトラフィックに拡張されない限り。粘着性ソリューションのもう1つの欠点は、特に1つの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:
2番目は「複製」カテゴリで、各アクティブメンバーのIPSEC SASの各ペアに対して子SAが複製されます。同じピアの異なるパケットは、異なるメンバーを通過し、同じセレクターを持つ異なるSASを使用して保護され、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 複数の並列SASが必要であり、ピアは役に立たない。[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 同じフローに属するさまざまなパケットは、特にファイアウォールなどの深いインスレクションミドルウェアと統合されている場合、ピアゲートウェイにとって「奇妙」に見えるかもしれません。これが現在のゲートウェイに問題を引き起こすかどうかは不明です。「フロー」の定義は実装によって異なるため、これに反対することも不可能です。
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.
カウンターモード（CTR）（[RFC3686]）やガロア/カウンターモード（GCM）（[RFC4106]）などのカウンターモード暗号を含むSASには、さらに別の合併症があります。このようなモードの初期ベクトルを繰り返す必要はなく、送信者はこれを確実にするためにカウンターや線形フィードバックシフトレジスタ（LFSR）などのメソッドを使用してください。複数のアクティブメンバー間で共有されているSAの場合、またはあるメンバーから別のメンバーに失敗することさえある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アドレスがあります。トンネルモードの子SASによって保護されているパケットは、クラスター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ホストの派手な機能を使用して物事を変更して、IKEパケットがクラスターIPアドレスから出てくるようにすることです。これは、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に関連付けられたSPI、および各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.
さらに、プロトコル拡張の同期要件について考えて、クラスターに対するサービス拒否攻撃の機会を生み出さないようにする必要があります。
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.
セクション3.5で述べたように、インバウンドチャイルドSAが別のメンバーにフェイルオーバーすることを許可すると、リプレイカウンター保護を短時間無効にする効果があります。脅威は間違いなく低いですが、これが受け入れられるかどうかは政策決定です。
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つのSASによって保護されているフローの2つの方向の問題について説明します。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 Arora、Jean-Michel Combes、Dan Harkins、David Harrington、Steve Kent、Tero Kivinen、Alexey Melnikov、Yaron Sheffer、Melinda Shore、ロドニー・ヴァン・メーター。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、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] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン2（IKEV2）」、2010年9月。
[ARORA] Arora, J. and P. Kumar, "Alternate Tunnel Addresses for IKEv2", Work in Progress, April 2010.
[Arora] Arora、J。およびP. Kumar、「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] McGrew、D。およびB. Weis、「セキュリティペイロード（ESP）と認証ヘッダー（AH）をカプセル化するカウンターモードを使用してグループトラフィックを保護する」、2010年3月、進行中の作業。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode", RFC 3686, January 2009.
[RFC3686] Housley、R。、「高度な暗号化標準（AES）カウンターモードの使用」、RFC 3686、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. McGrew、「セキュリティペイロードをカプセル化する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、「IKEV2のリダイレクトメカニズム」、RFC 5685、2009年11月。
[RFC5723] Sheffer, Y. and H. Tschofenig, "IKEv2 Session Resumption", RFC 5723, January 2010.
[RFC5723] Sheffer、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
yoav nirチェックポイントソフトウェアテクノロジーズLtd. 5 hasolelim st。Tel Aviv 67897イスラエル
EMail: ynir@checkpoint.com