[要約] RFC 7791は、IKEv2でIKEセキュリティアソシエーションをクローンする方法について説明しています。このRFCの目的は、IKEv2のセキュリティアソシエーションを効率的に複製するための手法を提供することです。
Internet Engineering Task Force (IETF) D. Migault, Ed.
Request for Comments: 7791 Ericsson
Category: Standards Track V. Smyslov
ISSN: 2070-1721 ELVIS-PLUS
March 2016
Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2)
Internet Key Exchange Protocol Version 2（IKEv2）でのIKE Security Associationの複製
Abstract
概要
This document considers a VPN end user establishing an IPsec Security Association (SA) with a Security Gateway using the Internet Key Exchange Protocol version 2 (IKEv2), where at least one of the peers has multiple interfaces or where Security Gateway is a cluster with each node having its own IP address.
このドキュメントでは、VPNエンドユーザーが、インターネットキー交換プロトコルバージョン2（IKEv2）を使用してセキュリティゲートウェイとIPsecセキュリティアソシエーション（SA）を確立することを検討しています。ピアの少なくとも1つに複数のインターフェイスがあるか、セキュリティゲートウェイがそれぞれのクラスタである場合独自のIPアドレスを持つノード。
The protocol described allows a peer to clone an IKEv2 SA, where an additional SA is derived from an existing one. The newly created IKE SA is set without the IKEv2 authentication exchange. This IKE SA can later be assigned to another interface or moved to another cluster node.
説明されているプロトコルにより、ピアはIKEv2 SAを複製できます。追加のSAは既存のSAから派生します。新しく作成されたIKE SAは、IKEv2認証交換なしで設定されます。このIKE SAは、後で別のインターフェイスに割り当てたり、別のクラスターノードに移動したりできます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc7791.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7791で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Support Negotiation . . . . . . . . . . . . . . . . . . . 6
5.2. Cloning the IKE SA . . . . . . . . . . . . . . . . . . . 7
5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 7
6. Payload Description . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Setting a VPN on Multiple Interfaces . . . . . . . . 11
A.1. Setting VPN_0 . . . . . . . . . . . . . . . . . . . . . . 11
A.2. Creating an Additional IKE SA . . . . . . . . . . . . . . 12
A.3. Creating the Child SA for VPN_1 . . . . . . . . . . . . . 12
A.4. Moving VPN_1 on Interface_1 . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
The main scenario that motivated this document is a VPN end user establishing a VPN with a Security Gateway when at least one of the peers has multiple interfaces. Figure 1 represents the case when the VPN end user has multiple interfaces, Figure 2 represents the case when the Security Gateway has multiple interfaces, and Figure 3 represents the case when both the VPN end user and the Security Gateway have multiple interfaces. With Figure 1 and Figure 2, one of the peers has n = 2 interfaces and the other has a single interface. This results in the creation of up to n = 2 VPNs. With Figure 3, the VPN end user has n = 2 interfaces and the Security Gateway has m = 2 interfaces. This may lead to up to m x n VPNs.
このドキュメントの動機となった主なシナリオは、少なくとも1つのピアに複数のインターフェースがある場合に、VPNエンドユーザーがSecurity GatewayでVPNを確立することです。図1は、VPNエンドユーザーが複数のインターフェースを備えている場合、図2はSecurity Gatewayが複数のインターフェースを備えている場合、図3はVPNエンドユーザーとSecurity Gatewayの両方が複数のインターフェースを備えている場合を表しています。図1と図2では、ピアの1つにn = 2のインターフェースがあり、もう1つには単一のインターフェースがあります。これにより、最大n = 2のVPNが作成されます。図3では、VPNエンドユーザーにはn = 2のインターフェースがあり、Security Gatewayにはm = 2のインターフェースがあります。これにより、最大でm x nのVPNが発生する可能性があります。
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| ================= | |
| VPN | v | Security |
| End User | ================== Gateway |
| ================^ | |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
Figure 1: VPN End User with Multiple Interfaces
図1：複数のインターフェイスを持つVPNエンドユーザー
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| | ================== |
| VPN | v | Security |
| End User ================= | Gateway |
| | ^================= |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
Figure 2: Security Gateway with Multiple Interfaces
図2：複数のインターフェースを持つSecurity Gateway
+------------+ +------------+
| | Interface_0 Interface_0' | |
| ================================== |
| VPN | \\ // | Security |
| End User | // \\ | Gateway |
| ================================== |
| | Interface_1 Interface_1' | |
+------------+ +------------+
Figure 3: VPN End User and Security Gateway with Multiple Interfaces With the current IKEv2 protocol [RFC7296], each VPN requires an IKE SA, and setting an IKE SA requires an authentication. Authentication might require multiple round trips and an activity from the end user (like EAP-SIM [RFC4186] or EAP-TLS [RFC5216]) as well as crypto operations that would introduce an additional delay.
図3：複数のインターフェースを持つVPNエンドユーザーとセキュリティゲートウェイ現在のIKEv2プロトコル[RFC7296]では、各VPNにはIKE SAが必要であり、IKE SAの設定には認証が必要です。認証には、複数のラウンドトリップとエンドユーザーからのアクティビティ（EAP-SIM [RFC4186]またはEAP-TLS [RFC5216]など）と、追加の遅延を引き起こす暗号操作が必要になる場合があります。
Another scenario is a load-balancing solution. Load-sharing clusters are often built to be transparent for VPN end users. In the case of IPsec, this means that IKE and IPsec SA states are duplicated on every cluster node where the load balancer can redirect packets. The drawback of such an approach is that anti-replay related data (in particular, Sequence Number) must be reliably synchronized between participating nodes per every outgoing Authentication Header (AH) or Encapsulating Security Payload (ESP) packet, which makes building high-speed systems problematic. Another approach for building load-balancing systems is to make VPN end users aware of them, which allows for having two or more Security Gateways sharing the same ID, but each having its own IP address. In this case, the VPN end user first establishes an IKE SA with one of these gateways. Then, at some point of time the gateway makes a decision to move the client to a different cluster node. This can be done with Redirect Mechanism for IKEv2 [RFC5685]. The drawback of such an approach is that it requires a new IKE SA to be established from scratch, including full authentication. In some cases, this could be avoided by using IKEv2 Session Resumption [RFC5723] with a new gateway. However, this requires the VPN end user to know beforehand which new gateway to connect to. So, it is desirable to be able to clone the existing IKE SA, move it to a different Security Gateway, and then indicate to the VPN end user to use this new SA. This would allow participating Security Gateways to share the load between them.
別のシナリオは、負荷分散ソリューションです。負荷共有クラスタは、VPNエンドユーザーに対して透過的になるように構築されることがよくあります。 IPsecの場合、これは、IKEとIPsec SAの状態が、ロードバランサーがパケットをリダイレクトできるすべてのクラスターノードで複製されることを意味します。このようなアプローチの欠点は、アンチリプレイ関連のデータ（特にシーケンス番号）を、すべての発信認証ヘッダー（AH）またはカプセル化セキュリティペイロード（ESP）パケットごとに参加ノード間で確実に同期する必要があるため、高速に構築できることです。問題のあるシステム。ロードバランシングシステムを構築するための別のアプローチは、VPNエンドユーザーにそれらを認識させることです。これにより、2つ以上のSecurity Gatewayが同じIDを共有し、それぞれが独自のIPアドレスを持つことができます。この場合、VPNエンドユーザーはまず、これらのゲートウェイの1つを使用してIKE SAを確立します。次に、ある時点で、ゲートウェイはクライアントを別のクラスターノードに移動することを決定します。これは、IKEv2のリダイレクトメカニズム[RFC5685]で実行できます。このようなアプローチの欠点は、完全な認証を含め、新しいIKE SAを最初から確立する必要があることです。場合によっては、新しいゲートウェイでIKEv2セッション再開[RFC5723]を使用することでこれを回避できます。ただし、これには、VPNエンドユーザーが接続する新しいゲートウェイを事前に知っている必要があります。そのため、既存のIKE SAを複製し、それを別のSecurity Gatewayに移動して、VPNエンドユーザーにこの新しいSAを使用するように指示できることが望ましいです。これにより、参加しているSecurity Gatewayがそれらの間で負荷を共有できるようになります。
This document introduces the possibility of cloning the IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2). The main idea is that the peer with multiple interfaces sets the first IKE SA as usual. Then it takes advantage of the fact that this SA is completed and derives as many new parallel IKE SAs from it as the desired number of VPNs. On each IKE SA a VPN is negotiated by creating one or more IPsec SAs. This results in coexisting parallel VPNs. Then the VPN end user moves each IPsec SA to its proper location using the IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555]. Alternatively, the VPN end user may first move the IKE SAs and then create the IPsec SAs.
このドキュメントでは、インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）でIKE SAを複製する可能性を紹介します。主な考え方は、複数のインターフェイスを持つピアが通常どおり最初のIKE SAを設定することです。次に、このSAが完了したことを利用して、必要な数のVPNと同じ数の新しい並列IKE SAをSAから派生させます。各IKE SAで、1つ以上のIPsec SAを作成することにより、VPNがネゴシエートされます。これにより、並列VPNが共存します。次に、VPNエンドユーザーは、IKEv2モビリティおよびマルチホーミングプロトコル（MOBIKE）[RFC4555]を使用して、各IPsec SAを適切な場所に移動します。または、VPNエンドユーザーが最初にIKE SAを移動してから、IPsec SAを作成することもできます。
Note that it is up to the host's local policy to decide which additional VPNs to create and when to do it. The process of selecting address pairs for migration is a local matter.
作成する追加のVPNとそれをいつ実行するかを決定するのは、ホストのローカルポリシー次第であることに注意してください。移行するアドレスペアを選択するプロセスは、ローカルの問題です。
Furthermore, in the case of multiple interfaces on both ends, care should be taken to avoid the VPNs being duplicated by both ends or moved to both interfaces.
さらに、両端に複数のインターフェースがある場合は、VPNが両端で重複したり、両方のインターフェースに移動したりしないように注意する必要があります。
In addition, multiple MOBIKE operations may be involved from the Security Gateway or the VPN end user. Suppose, as depicted in Figure 3 for example, that the cloned VPN is between Interface _0 and Interface_0', and the VPN end user and the Security Gateway want to move it to Interface_1 and Interface_1'. The VPN end user may initiate a MOBIKE exchange in order to move it to Interface_1, in which case the cloned VPN is now between Interface_1 and Interface_0'. Then the Security Gateway may also initiate a MOBIKE exchange in order to move the VPN to Interface_1', in which case the VPN has reached its final destination.
さらに、Security GatewayまたはVPNエンドユーザーからの複数のMOBIKE操作が含まれる場合があります。たとえば、図3に示すように、クローンVPNがInterface _0とInterface_0 'の間にあり、VPNエンドユーザーとSecurity GatewayがそれをInterface_1とInterface_1'に移動したいとします。 VPNエンドユーザーは、それをInterface_1に移動するためにMOBIKE交換を開始できます。その場合、複製されたVPNは現在、Interface_1とInterface_0 'の間にあります。次に、セキュリティゲートウェイはVPNをInterface_1 'に移動するためにMOBIKE交換を開始することもできます。この場合、VPNは最終的な宛先に到達しています。
The combination of the IKE SA cloning with MOBIKE protocol provides IPsec communications with multiple interfaces the following advantages. First, cloning the IKE SA requires very few modifications to already existing IKEv2 implementations. Then, it takes advantage of the already existing and widely deployed MOBIKE protocol. Finally, it keeps a dedicated IKE SA for each VPN, which simplifies reachability tests and VPN maintenance.
IKE SAクローニングとMOBIKEプロトコルの組み合わせにより、複数のインターフェイスとのIPsec通信に次の利点がもたらされます。まず、IKE SAのクローンを作成するには、既存のIKEv2実装にほとんど変更を加える必要はありません。次に、既存の広く展開されているMOBIKEプロトコルを利用します。最後に、各VPNに専用のIKE SAを保持するため、到達可能性テストとVPNメンテナンスが簡素化されます。
Note also that the cloning of the IKE SA is independent from MOBIKE and can also address other future scenarios not described in the current document.
また、IKE SAの複製はMOBIKEから独立しており、現在のドキュメントに記載されていない他の将来のシナリオにも対応できることに注意してください。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This section defines terms and acronyms used in this document.
このセクションでは、このドキュメントで使用される用語と頭字語を定義します。
- VPN: Virtual Private Network -- one or more Child (IPsec) SAs created in tunnel mode between two peers.
- VPN：Virtual Private Network-2つのピア間のトンネルモードで作成された1つ以上の子（IPsec）SA。
- VPN End User: designates the end user that initiates the VPN with a Security Gateway. This end user may be mobile and move its VPN from one Security Gateway to another.
- VPNエンドユーザー：Security GatewayでVPNを開始するエンドユーザーを指定します。このエンドユーザーはモバイルで、VPNを1つのSecurity Gatewayから別のSecurity Gatewayに移動する場合があります。
- Security Gateway: designates a point of attachment for the VPN service. In this document, the VPN service is provided by multiple Security Gateways. Each Security Gateway may be considered as a specific hardware.
- Security Gateway：VPNサービスの接続ポイントを指定します。このドキュメントでは、VPNサービスは複数のSecurity Gatewayによって提供されています。各Security Gatewayは、特定のハードウェアと見なされます。
- IKE SA: IKE Security Association as defined in [RFC7296].
- いけ さ： いけ せくりｔｙ あっそしあちおん あｓ でふぃねｄ いん 「ＲＦＣ７２９６」。
This document specifies how to clone existing IKE SAs without performing new authentication. In order to achieve this goal, this document proposes that the two peers agree upon their ability to clone the IKE SA. This is done during the IKE_AUTH exchange by exchanging the CLONE_IKE_SA_SUPPORTED notifications. To create a new parallel IKE SA, one of the peers initiates a CREATE_CHILD_SA exchange as if it would rekey the existing IKE SA. In order to indicate that the current IKE SA must not be deleted, the initiator includes the CLONE_IKE_SA notification in the CREATE_CHILD_SA exchange. This results in two parallel IKE SAs.
このドキュメントでは、新しい認証を実行せずに既存のIKE SAを複製する方法について説明します。この目標を達成するために、このドキュメントでは、2つのピアがIKE SAを複製する能力について合意することを提案しています。これは、IKE_AUTH交換中にCLONE_IKE_SA_SUPPORTED通知を交換することによって行われます。新しい並列IKE SAを作成するには、ピアの1つが、既存のIKE SAのキーを再生成するかのようにCREATE_CHILD_SA交換を開始します。現在のIKE SAを削除してはならないことを示すために、イニシエーターはCLONE_IKE_SA通知をCREATE_CHILD_SA交換に含めます。これにより、2つの並列IKE SAが生成されます。
Note that without the CLONE_IKE_SA notification, the old IKE SA would be deleted after the rekey is successfully completed (as specified in Section 2.8 of [RFC7296].
CLONE_IKE_SA通知がないと、鍵の再生成が正常に完了した後に古いIKE SAが削除されることに注意してください（[RFC7296]のセクション2.8で指定されています）。
The initiator and the responder indicate their support for cloning IKE SA by exchanging the CLONE_IKE SA_SUPPORTED notifications. This notification MUST be sent in the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges -- in the first IKE_AUTH message from initiator and in the last IKE_AUTH message from responder). If both initiator and responder send this notification during the IKE_AUTH exchange, peers may clone this IKE SA. In the other case, the IKE SA MUST NOT be cloned.
イニシエーターとレスポンダーは、CLONE_IKE SA_SUPPORTED通知を交換することにより、IKE SAのクローン作成のサポートを示します。この通知は、IKE_AUTH交換で送信する必要があります（複数のIKE_AUTH交換の場合-イニシエーターからの最初のIKE_AUTHメッセージとレスポンダーからの最後のIKE_AUTHメッセージで）。イニシエーターとレスポンダーの両方がIKE_AUTH交換中にこの通知を送信した場合、ピアはこのIKE SAを複製できます。それ以外の場合、IKE SAを複製することはできません。
Initiator Responder
-------------------------------------------------------------------
HDR, SA, KEi, Ni -->
<-- HDR, SA, KEr, Nr
HDR, SK {IDi, AUTH,
SA, TSi, TSr,
N(CLONE_IKE_SA_SUPPORTED)} -->
<-- HDR, SK {IDr, AUTH,
SA, TSi, TSr,
N(CLONE_IKE_SA_SUPPORTED)}
The initiator of the rekey exchange includes the CLONE_IKE_SA notification in a CREATE_CHILD_SA request for rekeying the IKE SA. The CLONE_IKE_SA notification indicates that the current IKE SA will not be immediately deleted once the new IKE SA is created. Instead, two parallel IKE SAs are expected to coexist. The current IKE SA becomes the old IKE SA and the newly negotiated IKE SA becomes the new IKE SA. The CLONE_IKE_SA notification MUST appear only in the request message of the CREATE_CHILD_SA exchange concerning the IKE SA rekey. If the CLONE_IKE_SA notification appears in any other message, it MUST be ignored.
キー再生成交換のイニシエーターは、IKE SAのキー再生成のCREATE_CHILD_SA要求にCLONE_IKE_SA通知を含めます。 CLONE_IKE_SA通知は、新しいIKE SAが作成されても、現在のIKE SAがすぐに削除されないことを示しています。代わりに、2つの並列IKE SAが共存することが期待されています。現在のIKE SAが古いIKE SAになり、新しくネゴシエートされたIKE SAが新しいIKE SAになります。 CLONE_IKE_SA通知は、IKE SAキー再生成に関するCREATE_CHILD_SA交換の要求メッセージにのみ表示される必要があります。 CLONE_IKE_SA通知が他のメッセージに表示される場合は、無視する必要があります。
Initiator Responder
-------------------------------------------------------------------
HDR, SK {N(CLONE_IKE_SA), SA, Ni, KEi} -->
If the CREATE_CHILD_SA request is concerned with an IKE SA rekey and contains the CLONE_IKE_SA notification, the responder proceeds to the IKE SA rekey, creates the new IKE SA, and keeps the old IKE SA. No additional Notify Payloads are included in the CREATE_CHILD_SA response as represented below:
CREATE_CHILD_SA要求がIKE SAキー再生成に関係し、CLONE_IKE_SA通知が含まれている場合、レスポンダはIKE SAキー再生成に進み、新しいIKE SAを作成して、古いIKE SAを保持します。以下に示すように、追加の通知ペイロードはCREATE_CHILD_SA応答に含まれません。
<-- HDR, SK {SA, Nr, KEr}
When the IKE SA is cloned, peers MUST NOT transfer existing Child SAs that were created by the old IKE SA to the newly created IKE SA. So, all signaling messages concerning those Child SAs would continue to be sent over the old IKE SA. This is different from the regular IKE SA rekey in IKEv2.
IKE SAが複製されるとき、ピアは、古いIKE SAによって作成された既存の子SAを新しく作成されたIKE SAに転送してはなりません（MUST NOT）。したがって、それらの子SAに関するすべてのシグナリングメッセージは、古いIKE SAを介して送信され続けます。これは、IKEv2の通常のIKE SAキー再生成とは異なります。
There may be conditions when the responder for some reason is unable or unwilling to clone the IKE SA. This inability may be temporary or permanent.
何らかの理由でレスポンダがIKE SAのクローンを作成できない、または作成したくない場合があります。この無能力は一時的または永続的かもしれません。
Temporary inability occurs when the responder doesn't have enough resources at the moment to clone an IKE SA or when the IKE SA is being deleted by the responder. In this case, the responder SHOULD reject the request to clone the IKE SA with the TEMPORARY_FAILURE notification.
一時的に応答不能になるのは、現時点でIKE SAを複製するのに十分なリソースがレスポンダーにない場合、またはIKE SAがレスポンダーによって削除されている場合です。この場合、レスポンダは、TEMPORARY_FAILURE通知を使用してIKE SAを複製する要求を拒否する必要があります（SHOULD）。
<-- HDR, SK {N(TEMPORARY_FAILURE)}
After receiving this notification, the initiator MAY retry its request after waiting some period of time. See Section 2.25 of [RFC7296] for details.
この通知を受け取った後、イニシエーターは、しばらく待ってから要求を再試行してもよい（MAY）。詳細については、[RFC7296]のセクション2.25を参照してください。
In some cases, the responder may have restrictions on the number of coexisting IKE SAs with one peer. These restrictions may be either implicit (some devices may have enough resources to handle only a few IKE SAs) or explicit (provided by some configuration parameter). If the initiator wants to clone more IKE SAs than the responder is able or is configured to handle, the responder SHOULD reject the request with the NO_ADDITIONAL_SAS notification.
場合によっては、レスポンダーが1つのピアと共存するIKE SAの数に制限を設けることがあります。これらの制限は、暗黙的（一部のデバイスは少数のIKE SAのみを処理するのに十分なリソースを持っている場合があります）または明示的（いくつかの構成パラメーターによって提供される）のいずれかです。イニシエーターが、レスポンダーが処理できるように構成されているか、構成されているよりも多くのIKE SAを複製したい場合、レスポンダーは、NO_ADDITIONAL_SAS通知で要求を拒否する必要があります（SHOULD）。
<-- HDR, SK {N(NO_ADDITIONAL_SAS)}
This condition is considered permanent and the initiator SHOULD NOT retry cloning an IKE SA until some of the existing SAs with the responder are deleted.
この状態は永続的と見なされ、イニシエーターは、レスポンダを含む既存のSAの一部が削除されるまで、IKE SAのクローン作成を再試行してはなりません。
Figure 4 illustrates the Notify Payload packet format as described in Section 3.10 of [RFC7296]. This format is used for both the CLONE_IKE_SA and the CLONE_IKE_SA_SUPPORTED notifications.
図4は、[RFC7296]のセクション3.10で説明されているNotify Payloadパケット形式を示しています。この形式は、CLONE_IKE_SA通知とCLONE_IKE_SA_SUPPORTED通知の両方に使用されます。
The CLONE_IKE_SA_SUPPORTED notification is used in an IKEv2 exchange of type IKE_AUTH and the CLONE_IKE_SA is used in an IKEv2 exchange of type CREATE_CHILD_SA.
CLONE_IKE_SA_SUPPORTED通知は、IKE_AUTHタイプのIKEv2交換で使用され、CLONE_IKE_SAは、タイプCREATE_CHILD_SAのIKEv2交換で使用されます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Notify Payload
図4：ペイロードに通知
The fields Next Payload, Critical Bit, RESERVED, and Payload Length are defined in [RFC7296]. Specific fields defined in this document are:
フィールドNext Payload、Critical Bit、RESERVED、およびPayload Lengthは[RFC7296]で定義されています。このドキュメントで定義されている特定のフィールドは次のとおりです。
- Protocol ID (1 octet): Set to zero.
- プロトコルID（1オクテット）：ゼロに設定します。
- Security Parameter Index (SPI) Size (1 octet): Set to zero.
- セキュリティパラメータインデックス（SPI）サイズ（1オクテット）：ゼロに設定します。
- Notify Message Type (2 octets): Specifies the type of notification message. It is set to 16432 for the CLONE_IKE_SA_SUPPORTED notification or 16433 for the CLONE_IKE_SA notification.
- 通知メッセージタイプ（2オクテット）：通知メッセージのタイプを指定します。 CLONE_IKE_SA_SUPPORTED通知の場合は16432に設定され、CLONE_IKE_SA通知の場合は16433に設定されます。
IANA has allocated two values in the "IKEv2 Notify Message Types - Status Types" registry:
IANAは、「IKEv2通知メッセージタイプ-ステータスタイプ」レジストリに2つの値を割り当てています。
Value Notify Messages - Status Types
-----------------------------------------
16432 CLONE_IKE_SA_SUPPORTED
16433 CLONE_IKE_SA
The protocol defined in this document does not modify IKEv2. Security considerations for cloning an IKE SA are mostly the same as those for the base IKEv2 protocol described in [RFC7296].
このドキュメントで定義されているプロトコルは、IKEv2を変更しません。 IKE SAを複製するためのセキュリティの考慮事項は、[RFC7296]で説明されているベースIKEv2プロトコルの場合とほとんど同じです。
Cloning an IKE SA allows an initiator to duplicate existing SAs. As a result, it may influence any accounting or control mechanisms based on a single IKE SA per authentication.
IKE SAを複製すると、イニシエーターは既存のSAを複製できます。その結果、認証ごとに単一のIKE SAに基づくアカウンティングまたは制御メカニズムに影響を与える可能性があります。
Suppose a system has a limit on the number of IKE SAs it can handle. In this case, cloning an IKE SA may provide a way for resource exhaustion, as a single end user may populate multiple IKE SAs.
システムが処理できるIKE SAの数に制限があるとします。この場合、単一のエンドユーザーが複数のIKE SAを設定する可能性があるため、IKE SAのクローンを作成することでリソースを使い果たす可能性があります。
Suppose a system shares the IPsec resources by limiting the number of Child SAs per IKE SA. With a single IKE SA per end user, this provides an equal resource sharing. In this case, cloning the IKE SA provides the means for an end user to overpass this limit. Such a system should evaluate the number of Child SAs over the number of all IKE SAs associated to an end user.
IKE SAごとの子SAの数を制限することにより、システムがIPsecリソースを共有するとします。エンドユーザーごとに1つのIKE SAを使用することで、同等のリソース共有が実現します。この場合、IKE SAのクローンを作成すると、エンドユーザーがこの制限を超えることができます。このようなシステムでは、エンドユーザーに関連付けられているすべてのIKE SAの数に対して子SAの数を評価する必要があります。
Note that these issues are not unique to the ability of cloning the IKE SA, as multiple IKE SAs between two peers may be created without involving a cloning method. Note also that implementation can always limit the number of cloned IKE SAs.
2つのピア間に複数のIKE SAが作成されるため、これらの問題はIKE SAの複製機能に固有のものではないことに注意してください。また、実装では常に複製されたIKE SAの数を制限できることに注意してください。
Suppose the VPN or any other IPsec-based service monitoring is based on the liveliness of the first IKE SA. Such a system considers a service is accessed or used from the time IKE performs an authentication to the time the IKE SA is deleted. Such accounting methods were fine as any IKE SA required an authentication exchange. As cloning the IKE SA skips the authentication phase, it may make it possible to delete the initial IKE SA while the service is being used on the cloned IKE SA. Such accounting methods should consider that the service is being used from the first IKE SA establishment to until the last IKE SA is removed.
VPNまたはその他のIPsecベースのサービス監視が、最初のIKE SAの活気に基づいていると仮定します。このようなシステムは、IKEが認証を実行してからIKE SAが削除されるまで、サービスがアクセスまたは使用されていると見なします。 IKE SAは認証交換を必要としたため、このようなアカウンティング方式は問題ありませんでした。 IKE SAの複製は認証フェーズをスキップするため、複製されたIKE SAでサービスが使用されている間に、初期IKE SAを削除できる場合があります。このようなアカウンティング方式では、サービスが最初のIKE SAの確立から最後のIKE SAが削除されるまで使用されていることを考慮する必要があります。
When this solution is used to build load-balancing systems, then there is a necessity to transfer IKE SA states between nodes of a load-sharing cluster. Since IKE SA state contains sensitive information, such as session keys, implementations must take all due precautions. Such precautions might include using technical and/or administrative means to protect IKE SA state data. The details of what is transferred and how it is protected are out of scope of this document.
このソリューションを使用して負荷分散システムを構築する場合は、負荷分散クラスターのノード間でIKE SA状態を転送する必要があります。 IKE SA状態にはセッションキーなどの機密情報が含まれているため、実装ではすべての予防措置を講じる必要があります。そのような予防措置には、IKE SA状態データを保護するための技術的手段や管理手段の使用が含まれる場合があります。何が転送され、どのように保護されるかについての詳細は、このドキュメントの範囲外です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, <http://www.rfc-editor.org/info/rfc4555>.
[RFC4555] Eronen、P。、「IKEv2 Mobility and Multihoming Protocol（MOBIKE）」、RFC 4555、DOI 10.17487 / RFC4555、2006年6月、<http://www.rfc-editor.org/info/rfc4555>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<http://www.rfc-editor.org/info/rfc7296>。
[RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006, <http://www.rfc-editor.org/info/rfc4186>.
[RFC4186] Haverinen、H.、Ed。およびJ. Salowey、編、「モバイルコミュニケーション用グローバルシステム（GSM）加入者識別モジュール（EAP-SIM）の拡張認証プロトコル方式」、RFC 4186、DOI 10.17487 / RFC4186、2006年1月、<http：// www。 rfc-editor.org/info/rfc4186>。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, <http://www.rfc-editor.org/info/rfc5216>.
[RFC5216]サイモン、D。、アボバ、B。、およびR.ハースト、「EAP-TLS認証プロトコル」、RFC 5216、DOI 10.17487 / RFC5216、2008年3月、<http://www.rfc-editor.org / info / rfc5216>。
[RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, DOI 10.17487/RFC5685, November 2009, <http://www.rfc-editor.org/info/rfc5685>.
[RFC5685] Devarapalli、V。およびK. Weniger、「インターネットキー交換プロトコルバージョン2（IKEv2）のリダイレクトメカニズム」、RFC 5685、DOI 10.17487 / RFC5685、2009年11月、<http：//www.rfc-editor。 org / info / rfc5685>。
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, DOI 10.17487/RFC5723, January 2010, <http://www.rfc-editor.org/info/rfc5723>.
[RFC5723] Sheffer、Y。およびH. Tschofenig、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）セッションの再開」、RFC 5723、DOI 10.17487 / RFC5723、2010年1月、<http://www.rfc-editor.org/ info / rfc5723>。
This section is informational and exposes how a VPN end user, as illustrated in Figure 1, can build two VPNs on its two interfaces without multiple authentications. Other cases represented in Figure 2 and Figure 3 are similar and can be easily derived from this case. The mechanism is based on cloning the IKE SA and the MOBIKE extension [RFC4555].
このセクションは参考情報であり、図1に示すように、VPNエンドユーザーが複数の認証なしに2つのインターフェイスで2つのVPNを構築する方法を示しています。図2と図3に示されている他のケースも同様であり、このケースから簡単に導出できます。このメカニズムは、IKE SAとMOBIKE拡張[RFC4555]の複製に基づいています。
First, the VPN end user negotiates a VPN using one interface. This involves regular IKEv2 exchanges. In addition, the VPN end user and the Security Gateway advertise their support for MOBIKE. At the end of the IKE_AUTH exchange, VPN_0 is set as represented in Figure 5.
まず、VPNエンドユーザーは1つのインターフェイスを使用してVPNをネゴシエートします。これには、定期的なIKEv2交換が含まれます。さらに、VPNエンドユーザーとSecurity Gatewayは、MOBIKEのサポートをアドバタイズします。 IKE_AUTH交換の最後に、VPN_0が図5に示すように設定されます。
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| ================= | |
| VPN | v | Security |
| End User | ================== Gateway |
| = | |
| | Interface_1 | |
+------------+ +------------+
Figure 5: VPN End User Establishing VPN_0
図5：VPN_0を確立するVPNエンドユーザー
The exchanges are completely described in [RFC7296] and [RFC4555]. First, peers negotiate IKE SA parameters and exchange nonces and public keys in the IKE_SA_INIT exchange. In the figure below, they also proceed to NAT detection because of the use of MOBIKE.
交換は完全に[RFC7296]と[RFC4555]で説明されています。まず、ピアはIKE SAパラメータをネゴシエートし、IKE_SA_INIT交換でナンスと公開鍵を交換します。次の図では、MOBIKEを使用しているため、NAT検出にも進みます。
Initiator Responder
-------------------------------------------------------------------
(IP_I0:500 -> IP_R:500)
HDR, SA, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
<-- (IP_R:500 -> IP_I0:500)
HDR, SA, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
Then the initiator and the responder proceed to the IKE_AUTH exchange, advertise their support for MOBIKE and their ability to clone the IKE SA -- with the MOBIKE_SUPPORTED and the CLONE_IKE_SA_SUPPORTED notifications -- and negotiate the Child SA for VPN_0. Optionally, the initiator and the responder can advertise their multiple interfaces using the ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications.
次に、イニシエーターとレスポンダーはIKE_AUTH交換に進み、MOBIKEのサポートと、MOBIKE_SUPPORTEDおよびCLONE_IKE_SA_SUPPORTED通知を使用してIKE SAを複製する機能を通知し、VPN_0の子SAをネゴシエートします。オプションで、イニシエーターとレスポンダーは、ADDITIONAL_IP4_ADDRESSまたはADDITIONAL_IP6_ADDRESS通知を使用して、複数のインターフェースを通知できます。
(IP_I0:4500 -> IP_R:4500)
HDR, SK {IDi, AUTH,
SA, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_IP*_ADDRESS)+,]
N(CLONE_IKE_SA_SUPPORTED)} -->
<-- (IP_R:4500 -> IP_I0:4500)
HDR, SK {IDr, AUTH,
SA, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_IP*_ADDRESS)+,]
N(CLONE_IKE_SA_SUPPORTED)}
In this case, the VPN end user wants to establish an additional VPN with its Interface_1. The VPN end user will first establish a parallel IKE SA using a CREATE_CHILD_SA that concerns an IKE SA rekey associated with a CLONE_IKE_SA notification. This results in two separate IKE SAs between the VPN end user and the Security Gateway. Currently both IKE SAs are set using Interface_0 of the VPN end user.
この場合、VPNエンドユーザーは、Interface_1で追加のVPNを確立したいと考えています。 VPNエンドユーザーは、CLONE_IKE_SA通知に関連付けられたIKE SAキー再生成に関係するCREATE_CHILD_SAを使用して、パラレルIKE SAを最初に確立します。これにより、VPNエンドユーザーとSecurity Gatewayの間に2つの別々のIKE SAが生じます。現在、両方のIKE SAは、VPNエンドユーザーのInterface_0を使用して設定されています。
Initiator Responder
-------------------------------------------------------------------
(IP_I0:4500 -> IP_R:4500)
HDR, SK {N(CLONE_IKE_SA),
SA, Ni, KEi} -->
<-- (IP_R:4500 -> IP_I0:4500)
HDR, SK {SA, Nr, KEr}
Once the new IKE SA has been created, the VPN end user can initiate a CREATE_CHILD_SA exchange that concerns the creation of a Child SA for VPN_1. The newly created VPN_1 will use Interface_0 of the VPN end user.
新しいIKE SAが作成されると、VPNエンドユーザーは、VPN_1の子SAの作成に関係するCREATE_CHILD_SA交換を開始できます。新しく作成されたVPN_1は、VPNエンドユーザーのInterface_0を使用します。
It is out of scope for this document to define how the VPN end user handles traffic with multiple interfaces. The VPN end user can use the same inner IP address on its multiple interfaces. In this case, the same Traffic Selectors (that is, the IP address used for VPN_0 and VPN_1) can match for both VPNs VPN_0 and VPN_1. The VPN end user must be aware of such a match and be able to manage it. It can, for example, use distinct Traffic Selectors on both VPNs using different ports, manage the order of its Security Policy Database (SPD), or have SPD defined per interfaces. Defining these mechanisms is out of scope for this document. Alternatively, the VPN end user can use a different inner IP address for each interface.
VPNエンドユーザーが複数のインターフェイスでトラフィックを処理する方法を定義することは、このドキュメントの範囲外です。 VPNエンドユーザーは、複数のインターフェイスで同じ内部IPアドレスを使用できます。この場合、同じトラフィックセレクター（つまり、VPN_0とVPN_1に使用されるIPアドレス）は、VPNVPN VPNとVPN_1の両方で一致できます。 VPNエンドユーザーは、このような一致を認識し、管理できる必要があります。たとえば、異なるポートを使用する両方のVPNで個別のトラフィックセレクターを使用したり、セキュリティポリシーデータベース（SPD）の順序を管理したり、インターフェイスごとにSPDを定義したりできます。これらのメカニズムの定義は、このドキュメントの範囲外です。または、VPNエンドユーザーは、インターフェイスごとに異なる内部IPアドレスを使用できます。
The creation of VPN_1 is performed via the newly created IKE SA as follows:
VPN_1の作成は、新しく作成されたIKE SAを介して次のように実行されます。
Initiator Responder
-------------------------------------------------------------------
(IP_I0:4500 -> IP_R:4500)
HDR(new), SK(new) {SA, TSi, TSr} -->
<-- (IP_R:4500 -> IP_I0:4500)
HDR(new), SK(new) {SA, TSi, TSr}
The resulting configuration is depicted in Figure 6. VPN_0 and VPN_1 have been created, but both are using the same Interface: Interface_0.
結果の構成を図6に示します。VPN_0とVPN_1が作成されていますが、どちらも同じインターフェイスInterface_0を使用しています。
+------------+ +------------+
| | Interface_0 : VPN_0, VPN_1 | |
| ==================== | |
| VPN ================= v | Security |
| End User | v =============== Gateway |
| | ================== |
| | Interface_1 | |
+------------+ +------------+
Figure 6: VPN End User Establishing VPN_0 and VPN_1
図6：VPN_0とVPN_1を確立するVPNエンドユーザー
In this section, MOBIKE is used to move VPN_1 on Interface_1. The exchange is described in [RFC4555].
このセクションでは、MOBIKEを使用して、VPN_1をInterface_1に移動します。交換は[RFC4555]で説明されています。
(IP_I1:4500 -> IP_R:4500)
HDR(new), SK(new) {N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2)} -->
<-- (IP_R:4500 -> IP_I1:4500)
HDR(new), SK(new) {
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2)}
This results in the situation as described in Figure 7.
これにより、図7に示すような状況になります。
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| ================== | |
| VPN | v | Security |
| End User | ================= Gateway |
| =================^ | |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
Figure 7: VPN End User with Multiple Interfaces
図7：複数のインターフェイスを持つVPNエンドユーザー
Acknowledgments
謝辞
The ideas for this document came from various input from the IP Security Maintenance and Extensions (ipsecme) Working Group and from discussions with Tero Kivinen and Michael Richardson. Yaron Sheffer and Tero Kivinen provided significant input to set the current design of the protocol, as well as its designation.
このドキュメントのアイデアは、IP Security Maintenance and Extensions（ipsecme）ワーキンググループからのさまざまなインプットと、Tero KivinenおよびMichael Richardsonとの議論から生まれました。 Yaron ShefferとTero Kivinenは、プロトコルの現在の設計とその指定を設定するための重要な情報を提供しました。
Authors' Addresses
著者のアドレス
Daniel Migault (editor) Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada
Daniel Migault（編集者）Ericsson 8400 boulevard Decarie Montreal、QC H4P 2N2カナダ
Email: daniel.migault@ericsson.com
Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation
Valery Smyslov ELVIS-PLUS PO Box 81モスクワ（ゼレノグラード）124460ロシア連邦
Phone: +7 495 276 0211
Email: svan@elvis.ru