[要約] RFC 4621は、IKEv2 Mobility and Multihoming (MOBIKE) プロトコルの設計に関するものであり、モバイルデバイスの移動や複数のネットワーク接続に対応するためのプロトコルです。このRFCの目的は、モバイルデバイスのセキュアな通信を維持しながら、ネットワークの変更や移動に対応することです。
Network Working Group T. Kivinen
Request for Comments: 4621 Safenet, Inc.
Category: Informational H. Tschofenig
Siemens
August 2006
Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
IKEV2モビリティとマルチホミング（MOBIKE）プロトコルの設計
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility).
IKEV2モビリティとマルチホミング（MOBIKE）プロトコルは、インターネットキーエクスチェンジプロトコルバージョン2（IKEV2）の拡張です。これらの拡張機能は、ホストが複数のIPアドレスを所有している場合、および/またはIPSECホストのIPアドレスが時間の経過とともに変更される場合（たとえば、モビリティなど）、IKEおよびIPSECセキュリティアソシエーションの効率的な管理を可能にする必要があります。
This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded.
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Scenarios .......................................................6
3.1. Mobility Scenario ..........................................6
3.2. Multihoming Scenario .......................................7
3.3. Multihomed Laptop Scenario .................................8
4. Scope of MOBIKE .................................................8
5. Design Considerations ..........................................10
5.1. Choosing Addresses ........................................10
5.1.1. Inputs and Triggers ................................11
5.1.2. Connectivity .......................................11
5.1.3. Discovering Connectivity ...........................12
5.1.4. Decision Making ....................................12
5.1.5. Suggested Approach .................................12
5.2. NAT Traversal (NAT-T) .....................................12
5.2.1. Background and Constraints .........................12
5.2.2. Fundamental Restrictions ...........................13
5.2.3. Moving behind a NAT and Back .......................13
5.2.4. Responder behind a NAT .............................14
5.2.5. NAT Prevention .....................................15
5.2.6. Suggested Approach .................................15
5.3. Scope of SA Changes .......................................15
5.4. Zero Address Set Functionality ............................16
5.5. Return Routability Check ..................................17
5.5.1. Employing MOBIKE Results in Other Protocols ........19
5.5.2. Return Routability Failures ........................20
5.5.3. Suggested Approach .................................21
5.6. IPsec Tunnel or Transport Mode ............................22
6. Protocol Details ...............................................22
6.1. Indicating Support for MOBIKE .............................22
6.2. Path Testing and Window size ..............................23
6.3. Message Presentation ......................................24
6.4. Updating Address Set ......................................25
7. Security Considerations ........................................26
8. Acknowledgements ...............................................26
9. References .....................................................27
9.1. Normative references ......................................27
9.2. Informative References ....................................27
The purpose of IKEv2 is to mutually authenticate two hosts, to establish one or more IPsec Security Associations (SAs) between them, and subsequently to manage these SAs (for example, by rekeying or deleting). IKEv2 enables the hosts to share information that is relevant to both the usage of the cryptographic algorithms that should be employed (e.g., parameters required by cryptographic algorithms and session keys) and to the usage of local security policies, such as information about the traffic that should experience protection.
IKEV2の目的は、2つのホストを相互に認証し、それらの間に1つまたは複数のIPSECセキュリティ関連（SA）を確立し、その後これらのSASを管理することです（たとえば、削除または削除することにより）。IKEV2により、ホストは、採用すべき暗号化アルゴリズムの使用（例えば、暗号化アルゴリズムやセッションキーに必要なパラメーター）と、ローカルセキュリティポリシーの使用などのローカルセキュリティポリシーの使用の両方に関連する情報を共有できます。保護を経験する必要があります。
IKEv2 assumes that an IKE SA is created implicitly between the IP address pair that is used during the protocol execution when establishing the IKEv2 SA. This means that, in each host, only one IP address pair is stored for the IKEv2 SA as part of a single IKEv2 protocol session, and, for tunnel mode SAs, the host places this single pair in the outer IP headers. Existing IPsec documents make no provision to change this pair after an IKE SA is created (except for dynamic address update of Network Address Translation Traversal (NAT-T)).
IKEV2は、IKEV2 SAを確立する際にプロトコル実行中に使用されるIPアドレスペア間でIKE SAが暗黙的に作成されると想定しています。つまり、各ホストでは、IKEV2 SAに1つのIKEV2プロトコルセッションの一部として1つのIPアドレスペアのみが保存され、トンネルモードSASの場合、ホストはこのシングルペアを外側のIPヘッダーに配置します。既存のIPSECドキュメントは、IKE SAが作成された後にこのペアを変更する規定を作成しません（ネットワークアドレス変換トラバーサル（NAT-T）の動的アドレス更新を除く）。
There are scenarios where one or both of the IP addresses of this pair may change during an IPsec session. In principle, the IKE SA and all corresponding IPsec SAs could be re-established after the IP address has changed. However, this is a relatively expensive operation, and it can be problematic when such changes are frequent. Moreover, manual user interaction (for example, when using human-operated token cards (SecurID)) might be required as part of the IKEv2 authentication procedure. Therefore, an automatic mechanism is needed that updates the IP addresses associated with the IKE SA and the IPsec SAs. The MOBIKE protocol provides such a mechanism.
このペアのIPアドレスの1つまたは両方がIPSECセッション中に変更されるシナリオがあります。原則として、IKE SAとすべての対応するIPSEC SASは、IPアドレスが変更された後に再確立される可能性があります。ただし、これは比較的高価な操作であり、そのような変更が頻繁に発生する場合に問題がある場合があります。さらに、IKEV2認証手順の一部として、手動のユーザーインタラクション（たとえば、人間操作トークンカードを使用する場合）が必要になる場合があります。したがって、IKE SAおよびIPSEC SASに関連付けられたIPアドレスを更新する自動メカニズムが必要です。Mobikeプロトコルは、このようなメカニズムを提供します。
The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306]. As IKEv2 is built on the IPsec architecture [RFC4301], all protocols developed within the MOBIKE working group must be compatible with both IKEv2 and the architecture described in RFC 4301. This document does not discuss mobility and multi-homing support for IKEv1 [RFC2409] or the obsoleted IPsec architecture described in RFC 2401 [RFC2401].
Mobikeプロトコルは、IKEV2 [RFC4306]の上で動作すると想定されています。IKEV2はIPSECアーキテクチャ[RFC4301]に基づいて構築されているため、Mobikeワーキンググループ内で開発されたすべてのプロトコルは、RFC 4301で説明されているIKEV2とアーキテクチャの両方と互換性がなければなりません。または、RFC 2401 [RFC2401]に記載されている廃止されたIPSECアーキテクチャ。
This document is structured as follows: After some important terms are introduced in Section 2, a number of relevant usage scenarios are discussed in Section 3. Section 4 describes the scope of the MOBIKE protocol. Section 5 discusses design considerations affecting the MOBIKE protocol. Section 6 investigates details regarding the MOBIKE protocol. Finally, this document concludes in Section 7 with security considerations.
このドキュメントは次のように構成されています。セクション2でいくつかの重要な用語が導入された後、セクション3で関連する使用シナリオの多くについて説明します。セクション4では、Mobikeプロトコルの範囲について説明します。セクション5では、Mobikeプロトコルに影響を与える設計上の考慮事項について説明します。セクション6では、Mobikeプロトコルに関する詳細を調査します。最後に、このドキュメントはセクション7でセキュリティ上の考慮事項を締めくくります。
This section introduces the terminology that is used in this document.
このセクションでは、このドキュメントで使用される用語を紹介します。
Peer
ピア
A peer is an IKEv2 endpoint. In addition, a peer implements the MOBIKE extensions, defined in [RFC4555].
ピアはIKEV2エンドポイントです。さらに、ピアは[RFC4555]で定義されているMobike Extensionsを実装します。
Available address
利用可能なアドレス
An address is said to be available if the following conditions are met:
次の条件が満たされている場合、住所は利用可能であると言われています。
* The address has been assigned to an interface.
* アドレスはインターフェイスに割り当てられています。
* If the address is an IPv6 address, we additionally require (a) that the address is valid as defined in RFC 2461 [RFC2461], and (b) that the address is not tentative as defined in RFC 2462 [RFC2462]. In other words, we require the address assignment to be complete.
* アドレスがIPv6アドレスである場合、（a）アドレスがRFC 2461 [RFC2461]で定義されているように有効であること、および（b）アドレスがRFC 2462 [RFC2462]で定義されているように暫定的ではないことがさらに要求されます。つまり、アドレスの割り当てを完了する必要があります。
Note that this explicitly allows an address to be optimistic as defined in [RFC4429].
* If the address is an IPv6 address, it is a global unicast or unique site-local address, as defined in [RFC4193]. That is, it is not an IPv6 link-local address.
* アドレスがIPv6アドレスの場合、[RFC4193]で定義されているように、グローバルユニキャストまたはユニークなサイトローカルアドレスです。つまり、IPv6 Link-Localアドレスではありません。
* The address and interface is acceptable for sending and receiving traffic according to a local policy.
* 住所とインターフェイスは、ローカルポリシーに従ってトラフィックを送信および受信するために受け入れられます。
This definition is taken from [WIP-Ark06] and adapted for the MOBIKE context.
この定義は[WIP-ARK06]から取得され、Mobikeコンテキストに適合しています。
Locally operational address
ローカルで動作するアドレス
An address is said to be locally operational if it is available and its use is locally known to be possible and permitted. This definition is taken from [WIP-Ark06].
住所は、利用可能であり、その使用が可能であり、許可されていることがローカルに知られている場合、ローカルで動作すると言われています。この定義は[wip-ark06]から取得されます。
Operational address pair
運用アドレスペア
A pair of operational addresses are said to be an operational address pair if and only if bidirectional connectivity can be shown between the two addresses. Note that sometimes it is necessary to consider connectivity on a per-flow level between two endpoints. This differentiation might be necessary to address certain Network Address Translation types or specific firewalls. This definition is taken from [WIP-Ark06] and adapted for the MOBIKE context. Although it is possible to further differentiate unidirectional and bidirectional operational address pairs, only bidirectional connectivity is relevant to this document, and unidirectional connectivity is out of scope.
一対の運用アドレスは、2つのアドレス間に双方向接続を表示できる場合にのみ、運用アドレスペアであると言われます。2つのエンドポイント間のフローごとのレベルでの接続を考慮する必要がある場合があることに注意してください。この区別は、特定のネットワークアドレス変換タイプまたは特定のファイアウォールに対処するために必要になる場合があります。この定義は[WIP-ARK06]から取得され、Mobikeコンテキストに適合しています。単方向および双方向の動作アドレスペアをさらに区別することは可能ですが、双方向の接続のみがこのドキュメントに関連しており、単方向接続は範囲外です。
Path
道
The sequence of routers traversed by the MOBIKE and IPsec packets exchanged between the two peers. Note that this path may be affected not only by the involved source and destination IP addresses, but also by the transport protocol. Since MOBIKE and IPsec packets have a different appearance on the wire, they might be routed along a different path, for example, due to load balancing. This definition is taken from [RFC2960] and adapted to the MOBIKE context.
2つのピア間で交換されたMobikeおよびIPSECパケットによって通過するルーターのシーケンス。このパスは、関連するソースおよび宛先IPアドレスだけでなく、輸送プロトコルによっても影響を受ける可能性があることに注意してください。MobikeとIpsecパケットはワイヤー上に異なる外観を持っているため、たとえば負荷分散のために、異なるパスに沿ってルーティングされる可能性があります。この定義は[RFC2960]から取得され、Mobikeコンテキストに適合しています。
Current path
現在のパス
The sequence of routers traversed by an IP packet that carries the default source and destination addresses is said to be the Current Path. This definition is taken from [RFC2960] and adapted to the MOBIKE context.
デフォルトのソースと宛先アドレスを運ぶIPパケットによって通過するルーターのシーケンスは、現在のパスであると言われています。この定義は[RFC2960]から取得され、Mobikeコンテキストに適合しています。
Preferred address
優先アドレス
The IP address of a peer to which MOBIKE and IPsec traffic should be sent by default. A given peer has only one active preferred address at a given point in time, except for the small time period where it switches from an old to a new preferred address. This definition is taken from [WIP-Nik06] and adapted to the MOBIKE context.
MobikeおよびIPSECトラフィックをデフォルトで送信するピアのIPアドレス。特定のピアは、特定の時点で1つのアクティブな優先アドレスしかありませんが、古いものから新しい優先アドレスに切り替える小さな期間を除きます。この定義は[wip-nik06]から取得され、Mobikeコンテキストに適合しています。
Peer address set
ピアアドレスセット
We denote the two peers of a MOBIKE session by peer A and peer B. A peer address set is the subset of locally operational addresses of peer A that is sent to peer B. A policy available at peer A indicates which addresses are included in the peer address set. Such a policy might be created either manually or automatically through interaction with other mechanisms that indicate new available addresses.
Bidirectional address pair
双方向のアドレスペア
The address pair, where traffic can be sent to both directions, simply by reversing the IP addresses. Note that the path of the packets going to each direction might be different.
IPアドレスを逆にするだけで、トラフィックを両方向に送信できるアドレスペア。各方向に行くパケットのパスは異なる場合があることに注意してください。
Unidirectional address pair
一方向のアドレスペア
The address pair, where traffic can only be sent in one direction, and reversing the IP addresses and sending reply back does not work.
トラフィックは一方向にのみ送信でき、IPアドレスを逆にして返信を送信するアドレスペアは機能しません。
For mobility-related terminology (e.g., Make-before-break or Break-before-make), see [RFC3753].
モビリティ関連の用語（たとえば、ブレイク前または壊れ前に壊れた後）については、[RFC3753]を参照してください。
In this section, we discuss three typical usage scenarios for the MOBIKE protocol.
このセクションでは、Mobikeプロトコルの3つの典型的な使用シナリオについて説明します。
Figure 1 shows a break-before-make mobility scenario where a mobile node (MN) changes its point of network attachment. Prior to the change, the mobile node had established an IPsec connection with a security gateway that offered, for example, access to a corporate network. The IKEv2 exchange that facilitated the setup of the IPsec SA(s) took place over the path labeled as 'old path'. The involved packets carried the MN's "old" IP address and were forwarded by the "old" access router (OAR) to the security gateway (GW).
図1は、モバイルノード（MN）がネットワーク添付ファイルのポイントを変更する侵入前のモビリティシナリオを示しています。変更の前に、モバイルノードは、たとえばコーポレートネットワークへのアクセスを提供するセキュリティゲートウェイとのIPSEC接続を確立していました。IPSEC SAのセットアップを容易にしたIKEV2交換は、「古いパス」とラベル付けされたパスを介して行われました。関係するパケットは、MNの「古い」IPアドレスを搭載し、「古い」アクセスルーター（OAR）によってセキュリティゲートウェイ（GW）に転送されました。
When the MN changes its point of network attachment, it obtains a new IP address using stateful or stateless address configuration. The goal of MOBIKE, in this scenario, is to enable the MN and the GW to continue using the existing SAs and to avoid setting up a new IKE SA. A protocol exchange, denoted by 'MOBIKE Address Update', enables the peers to update their state as necessary.
MNがネットワーク添付ファイルのポイントを変更すると、StatefulまたはStatelessアドレスの構成を使用して新しいIPアドレスを取得します。このシナリオでのMobikeの目標は、MNとGWが既存のSASの使用を継続できるようにし、新しいIKE SAのセットアップを避けることです。「Mobikeアドレスアップデート」で示されるプロトコル交換により、ピアは必要に応じて状態を更新できます。
Note that in a break-before-make scenario the MN obtains the new IP address after it can no longer be reached at the old IP address. In a make-before-break scenario, the MN is, for a given period of time, reachable at both the old and the new IP address. MOBIKE should work in both of the above scenarios.
侵入前のシナリオでは、MNは古いIPアドレスで到達できなくなった後に新しいIPアドレスを取得することに注意してください。ブレイク前のシナリオでは、MNは、特定の期間、古いIPアドレスと新しいIPアドレスの両方で到達可能です。Mobikeは、上記の両方のシナリオで機能するはずです。
(Initial IKEv2 Exchange)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v
Old IP +--+ +---+ v
address |MN|------> |OAR| -------------V v
+--+ +---+ Old path V v
. +----+ v>>>>> +--+
.move | R | -------> |GW|
. | | >>>>> | |
v +----+ ^ +--+
+--+ +---+ New path ^ ^
New IP |MN|------> |NAR|--------------^ ^
address +--+ +---+ ^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
(MOBIKE Address Update)
---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE)
...> = End host movement
Figure 1: Mobility Scenario
図1：モビリティシナリオ
Another MOBIKE usage scenario is depicted in Figure 2. In this scenario, the MOBIKE peers are equipped with multiple interfaces (and multiple IP addresses). Peer A has two interface cards with two IP addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1 and IP_B2. Each peer selects one of its IP addresses as the preferred address, which is used for subsequent communication. Various reasons (e.g., hardware or network link failures) may require a peer to switch from one interface to another.
別のMobike使用法のシナリオを図2に示します。このシナリオでは、Mobikeピアには複数のインターフェイス（および複数のIPアドレス）が装備されています。Peer Aには、IP_A1とIP_A2の2つのIPアドレスを持つ2つのインターフェイスカードがあり、Peer Bには2つのIPアドレス、IP_B1とIP_B2があります。各ピアは、その後の通信に使用される優先アドレスとしてIPアドレスの1つを選択します。さまざまな理由（ハードウェアまたはネットワークリンクの障害など）では、あるインターフェイスから別のインターフェイスに切り替えるためにピアが必要になる場合があります。
+------------+ +------------+
| Peer A | *~~~~~~~~~* | Peer B |
| |>>>>>>>>>> * Network *>>>>>>>>>>| |
| IP_A1 +-------->+ +--------->+ IP_B1 |
| | | | | |
| IP_A2 +********>+ +*********>+ IP_B2 |
| | * * | |
+------------+ *~~~~~~~~~* +------------+
---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE)
***> = Potential future path through the network
(if Peer A and Peer B change their preferred
address)
Figure 2: Multihoming Scenario
図2：マルチホームシナリオ
Note that MOBIKE does not aim to support load balancing between multiple IP addresses. That is, each peer uses only one of the available address pairs at a given point in time.
Mobikeは、複数のIPアドレス間の負荷分散をサポートすることを目的としていないことに注意してください。つまり、各ピアは、特定の時点で利用可能なアドレスペアの1つのみを使用します。
The third scenario we consider is about a laptop that has multiple interface cards and therefore several ways to connect to the network. It may, for example, have a fixed Ethernet card, a WLAN interface, a General Packet Radio Service (GPRS) adaptor, a Bluetooth interface, or USB hardware. Not all interfaces are used for communication all the time for a number of reasons (e.g., cost, network availability, user convenience). The policies that determine which interfaces are connected to the network at any given point in time is outside the scope of the MOBIKE protocol and, as such, this document. However, as the laptop changes its point of attachment to the network, the set of IP addresses under which the laptop is reachable changes too.
私たちが考慮する3番目のシナリオは、複数のインターフェイスカードを備えたラップトップ、したがってネットワークに接続するいくつかの方法です。たとえば、固定イーサネットカード、WLANインターフェイス、一般的なパケットラジオサービス（GPRS）アダプター、Bluetoothインターフェイス、またはUSBハードウェアがある場合があります。すべてのインターフェイスが常に多くの理由で通信に使用されているわけではありません（例：コスト、ネットワークの可用性、ユーザーの利便性）。特定の時点でどのインターフェイスがネットワークに接続されているかを決定するポリシーは、Mobikeプロトコルの範囲外であり、そのため、このドキュメント。ただし、ラップトップがネットワークへの添付ポイントを変更すると、ラップトップが到達可能な変更にも到達できるIPアドレスのセットが変更されます。
In all of these scenarios, even if IP addresses change due to interface switching or mobility, the IP address obtained via the configuration payloads within IKEv2 remain unaffected. The IP address obtained via the IKEv2 configuration payloads allow the configuration of the inner IP address of the IPsec tunnel. As such, applications might not detect any change at all.
これらのすべてのシナリオで、IPアドレスがインターフェイスの切り替えまたはモビリティにより変更されたとしても、IKEV2内の構成ペイロードを介して取得されたIPアドレスは影響を受けません。IKEV2構成のペイロードを介して取得されたIPアドレスにより、IPSECトンネルの内部IPアドレスの構成が可能になります。そのため、アプリケーションは変更をまったく検出しない場合があります。
Getting mobility and multihoming actually working requires many different components to work together, including coordinating decisions between different layers, different mobility mechanisms, and IPsec/IKEv2. Most of those aspects are beyond the scope of MOBIKE: MOBIKE focuses only on what two peers need in order to agree at the IKEv2 level (like new message formats and some aspects of their processing) required for interoperability.
モビリティとマルチホミングの実際に機能するには、異なるレイヤー、異なるモビリティメカニズム、IPSEC/IKEV2間の決定を調整するなど、多くの異なるコンポーネントが協力する必要があります。これらの側面のほとんどは、Mobikeの範囲を超えています。Mobikeは、相互運用性に必要なIKEV2レベル（新しいメッセージ形式や処理のいくつかの側面など）で同意するために2人のピアが必要とするものにのみ焦点を当てています。
The MOBIKE protocol is not trying to be a full mobility protocol; there is no support for simultaneous movement or rendezvous mechanism, and there is no support for route optimization, etc. The design document focuses on tunnel mode; everything going inside the tunnel is unaffected by the changes in the tunnel header IP address, and this is the mobility feature provided by the MOBIKE. That is, applications running inside the MOBIKE-controlled IPsec tunnel might not detect the movement since their IP addresses remain constant.
Mobikeプロトコルは、完全なモビリティプロトコルになろうとはしていません。同時動きやランデブーのメカニズムをサポートすることはなく、ルートの最適化などをサポートすることもありません。設計ドキュメントはトンネルモードに焦点を当てています。トンネル内に入るすべては、トンネルヘッダーIPアドレスの変更の影響を受けません。これは、Mobikeが提供するモビリティ機能です。つまり、IPアドレスが一定のままであるため、Mobike-Controlled Ipsecトンネル内で実行されるアプリケーションは動きを検出しない可能性があります。
The MOBIKE protocol should be able to perform the following operations (not all of which are done explicitly by the current protocol):
Mobikeプロトコルは、次の操作を実行できる必要があります（現在のプロトコルによってすべてが明示的に行われているわけではありません）：
o Inform the other peer about the peer address set
o 他のピアにピアアドレスセットについて通知します
o Inform the other peer about the preferred address
o 他のピアに優先アドレスについて通知します
o Test connectivity along a path and thereby detect an outage situation
o パスに沿った接続性をテストし、それによって停止状況を検出する
o Change the preferred address
o 優先アドレスを変更します
o Change the peer address set
o ピアアドレスセットを変更します
o Ability to deal with Network Address Translation devices
o ネットワークアドレス翻訳デバイスを処理する機能
Figure 3 shows an example protocol interaction between a pair of MOBIKE peers. MOBIKE interacts with the packet processing module of the IPsec implementation using an internal API (such as those based on PF_KEY [RFC2367]). Using this API, the MOBIKE module can create entries in the Security Association (SAD) and Security Policy Databases (SPD). The packet processing module of the IPsec implementation may also interact with IKEv2 and MOBIKE module using this API. The content of the Security Policy and Security Association Databases determines what traffic is protected with IPsec in which fashion. MOBIKE, on the other hand, receives information from a number of sources that may run both in kernel-mode and in user-mode. These sources form the basis on which MOBIKE makes decisions regarding the set of available addresses, the peer address set, and the preferred address. Policies may also affect the selection process.
図3は、一対のMobikeピア間のプロトコル相互作用の例を示しています。Mobikeは、内部API（PF_KEY [RFC2367]に基づくものなど）を使用してIPSEC実装のパケット処理モジュールと相互作用します。このAPIを使用して、Mobikeモジュールは、セキュリティ協会（SAD）およびセキュリティポリシーデータベース（SPD）にエントリを作成できます。IPSEC実装のパケット処理モジュールは、このAPIを使用してIKEV2およびMobikeモジュールと相互作用する場合があります。セキュリティポリシーおよびセキュリティ協会のデータベースのコンテンツは、どのようなトラフィックが保護されているかを決定します。一方、Mobikeは、カーネルモードとユーザーモードの両方で実行される可能性のある多くのソースから情報を受け取ります。これらのソースは、Mobikeが利用可能なアドレスのセット、ピアアドレスセット、および優先アドレスに関して決定を下す根拠を形成します。ポリシーは、選択プロセスにも影響を与える可能性があります。
The peer address set and the preferred address needs to be made available to the other peer. In order to address certain failure cases, MOBIKE should perform connectivity tests between the peers (potentially over a number of different paths). Although a number of address pairs may be available for such tests, the most important is the pair (source address, destination address) of the current path. This is because this pair is selected for sending and receiving MOBIKE signaling and IPsec traffic. If a problem along this current path is detected (e.g., due to a router failure), it is necessary to switch to a new current path. In order to be able to do so quickly, it may be helpful to perform connectivity tests of other paths periodically. Such a technique would also help identify previously disconnected paths that become operational again.
ピアアドレスセットと優先アドレスを他のピアが利用できるようにする必要があります。特定の障害のケースに対処するために、Mobikeはピア間で接続性テストを実行する必要があります（潜在的に多くの異なるパスを超えて）。このようなテストでは多くのアドレスペアが利用可能になる場合がありますが、最も重要なのは現在のパスのペア（ソースアドレス、宛先アドレス）です。これは、このペアがMobike SignalingとIPSECトラフィックの送信と受信に選択されているためです。この現在のパスに沿った問題が検出された場合（例えば、ルーターの故障による）、新しい電流パスに切り替える必要があります。迅速にできるようにするには、定期的に他のパスの接続テストを実行すると役立つ場合があります。このような手法は、再び動作するようになる以前に切断されたパスを特定するのにも役立ちます。
+---------------------+ +----------------+
| User-space | | |
| Protocols and | | MOBIKE and |
| Functions Relevant |<---------->| IKEv2 Module |
| MOBIKE (e.g., DHCP, | | |
| policies) | +----------------+
+---------------------+ ^
^ |
| | User space
++++++++++API++++++++++++++++++++++++++++PF_KEY+++++++++++++++
| | Kernel space
| v
| +----------------+
v | |
+---------------------+ | IPsec engine |
| Kernel-space |<---------->| (and databases)|
| Protocols | | |
| Relevant for | +----------------+
| MOBIKE (e.g., ND, | ^
| DNA, L2) |<---------------+ |
+---------------------+ v v
|| +----------------+
\/ | |
Inter- =====================>| IP forwarding, |
faces <=====================|input and output|
| |
+----------------+
===> = IP packets arriving/leaving a MOBIKE node
<-> = control and configuration operations
Figure 3: Framework
Please note that Figure 3 illustrates an example of how a MOBIKE implementation could work. It serves illustrative purposes only.
図3は、Mobikeの実装がどのように機能するかの例を示していることに注意してください。説明のみに役立ちます。
This section discusses aspects affecting the design of the MOBIKE protocol.
このセクションでは、Mobikeプロトコルの設計に影響する側面について説明します。
One of the core aspects of the MOBIKE protocol is the selection of the address for the IPsec packets we send. Choosing addresses for the IKEv2 request is a somewhat separate problem. In many cases, they will be the same (and in some design choice they will always be the same and could be forced to be the same by design).
Mobikeプロトコルの中心的な側面の1つは、送信するIPSECパケットのアドレスの選択です。IKEV2リクエストのアドレスを選択することは、やや個別の問題です。多くの場合、それらは同じになります（そして、設計の選択では、それらは常に同じであり、設計によって同じように強制される可能性があります）。
How address changes are triggered is largely beyond the scope of MOBIKE. The triggers can include changes in the set of addresses, various link-layer indications, failing dead peer detection, and changes in preferences and policies. Furthermore, there may be less reliable sources of information (such as lack of IPsec packets and incoming ICMP packets) that do not trigger any changes directly, but rather cause Dead Peer Detection (DPD) to be scheduled earlier and, if it fails, it might cause a change of the preferred address.
アドレスの変更がどのようにトリガーされるかは、ほとんどMobikeの範囲を超えています。トリガーには、アドレスのセットの変更、さまざまなリンク層指標、死んだピア検出の失敗、および好みとポリシーの変更を含めることができます。さらに、変更を直接トリガーしないが、死んだピア検出（DPD）が早期にスケジュールされ、失敗した場合、それが失敗した場合、信頼性の低い情報源（IPSECパケットの不足やICMPパケットの入力など）が少ない場合があります。優先アドレスの変更を引き起こす可能性があります。
These triggers are largely the same as for other mobility protocols such as Mobile IP, and they are beyond the scope of MOBIKE.
これらのトリガーは、モバイルIPなどの他のモビリティプロトコルとほぼ同じであり、Mobikeの範囲を超えています。
There can be two kinds of connectivity "failures": local failures and path failures. Local failures are problems locally at a MOBIKE peer (e.g., an interface error). Path failures are a property of an address pair and failures of nodes and links along this path. MOBIKE does not support unidirectional address pairs. Supporting them would require abandoning the principle of sending an IKEv2 reply to the address from which the request came. MOBIKE decided to deal only with bidirectional address pairs. It does consider unidirectional address pairs as broken and does not use them, but the connection between peers will not break even if unidirectional address pairs are present, provided there is at least one bidirectional address pair MOBIKE can use.
「障害」という2種類の接続性があります。局所的な障害とパス障害です。局所的な障害は、Mobike Peerの局所的な問題です（たとえば、インターフェイスエラーなど）。パス障害は、アドレスペアのプロパティであり、このパスに沿ったノードとリンクの障害です。Mobikeは、単方向のアドレスペアをサポートしていません。それらをサポートするには、リクエストが来た住所へのIKEV2の返信を送信する原則を放棄する必要があります。Mobikeは、双方向のアドレスペアのみを扱うことにしました。単方向のアドレスペアは壊れており、それらを使用していないと考えていますが、少なくとも1つの双方向のアドレスペアが使用できる場合、単方向のアドレスペアが存在する場合でも、ピア間の接続は壊れません。
Note that MOBIKE is not concerned about the actual path used; it cannot even detect if some path is unidirectionally operational if the same address pair has some other unidirectional path back. Ingress filters might still cause such path pairs to be unusable, and in that case MOBIKE will detect that there is no operational address pair.
Mobikeは、実際のパスを心配していないことに注意してください。同じアドレスペアが他の単方向パスを持っている場合、何らかのパスが一方向的に動作しているかどうかを検出することさえできません。Ingressフィルターは、そのようなパスペアが使用できなくなる可能性があり、その場合、Mobikeは運用上のアドレスペアがないことを検出します。
In a sense having both an IPv4 and an IPv6 address is basically a case of partial connectivity (putting both an IPv4 and an IPv6 address in the same IP header does not work). The main difference is that it is known beforehand; there is no need to discover that an IPv4/IPv6 combination does not work.
ある意味では、IPv4とIPv6アドレスの両方を持つことは、基本的に部分的な接続の場合です（同じIPヘッダーにIPv4とIPv6アドレスの両方を置くことは機能しません）。主な違いは、事前に知られていることです。IPv4/IPv6の組み合わせが機能しないことを発見する必要はありません。
To detect connectivity, the MOBIKE protocol needs to have a mechanism to test connectivity. If a MOBIKE peer receives a reply, it can be sure about the existence of a working (bidirectional) address pair. If a MOBIKE peer does not see a reply after multiple retransmissions, it may assume that the tested address pair is broken.
接続性を検出するには、Mobikeプロトコルには接続性をテストするメカニズムが必要です。Mobike Peerが返信を受け取った場合、作業（双方向）アドレスペアの存在について確信できます。Mobike Peerが複数の再送信後に返信が表示されない場合、テストされたアドレスペアが壊れていると仮定する場合があります。
The connectivity tests require congestion problems to be taken into account because the connection failure might be caused by congestion. The MOBIKE protocol should not make the congestion problem worse by sending many DPD packets.
接続の障害が渋滞によって引き起こされる可能性があるため、接続テストでは混雑の問題を考慮する必要があります。Mobikeプロトコルは、多くのDPDパケットを送信しても、混雑の問題を悪化させるべきではありません。
One of the main questions in designing the MOBIKE protocol was who makes the decisions how to fix a situation when failure is detected, e.g., symmetry vs. asymmetry in decision making. Symmetric decision making (i.e., both peers can make decisions) may cause the different peers to make different decisions, thus causing asymmetric upstream/ downstream traffic. In the mobility case, it is desirable that the mobile peer can move both upstream and downstream traffic to some particular interface, and this requires asymmetric decision making (i.e. only one peer makes decisions).
Mobikeプロトコルを設計する際の主な質問の1つは、意思決定における対称性と非対称性など、障害が検出されたときに状況を修正する方法を決定することでした。対称的な意思決定（つまり、両方のピアが決定を下すことができます）は、異なるピアが異なる決定を下す可能性があり、したがって、非対称の上流/下流のトラフィックを引き起こす可能性があります。モビリティの場合、モバイルピアが特定のインターフェイスに上流と下流のトラフィックの両方を移動できることが望ましいため、非対称の意思決定が必要です（つまり、1つのピアが決定を下すのは1つだけです）。
Working with stateful packet filters and NATs is easier if the same address pair is used in both upstream and downstream directions. Also, in common cases, only the peer behind NAT can actually perform actions to recover from the connectivity problems, as the other peer might not be able to initiate any connections to the peer behind NAT.
Stateful Packet FiltersとNATを使用すると、同じアドレスペアが上流方向と下流方向の両方で使用される場合は簡単です。また、一般的な場合、他のピアがNATの後ろのピアへの接続を開始できない可能性があるため、NATの後ろのピアのみが接続の問題から回復するためのアクションを実行できます。
The working group decided to select a method whereby the initiator will decide which addresses are used. As a consequence, the outcome is always the same for both parties. It also works best with NATs, as the initiator is most likely the node that is located behind a NAT.
ワーキンググループは、イニシエーターが使用されるアドレスを決定する方法を選択することを決定しました。結果として、結果は常に両当事者で同じです。また、イニシエーターはNATの後ろにあるノードである可能性が高いため、NATで最適に機能します。
Another core aspect of MOBIKE is the treatment of different NATs and Network Address Port Translations (NAPTs). In IKEv2 the tunnel header IP addresses are not sent inside the IKEv2 payloads, and thus there is no need to do unilateral self-address fixing (UNSAF
Mobikeのもう1つのコア側面は、さまざまなNATとネットワークアドレスポート翻訳（NAPTS）の処理です。IKEV2では、トンネルヘッダーIPアドレスはIKEV2ペイロード内に送信されないため、一方的な自己アドレス固定を行う必要はありません（UNSAF
[RFC3424]). The tunnel header IP addresses are taken from the outer IP header of the IKE packets; thus, they are already processed by the NAT.
[RFC3424]）。トンネルヘッダーIPアドレスは、IKEパケットの外側IPヘッダーから取得されます。したがって、それらはすでにNATによって処理されています。
The NAT detection payloads are used to determine whether the addresses in the IP header were modified by a NAT along the path. Detecting a NAT typically requires UDP encapsulation of IPsec ESP packets to be enabled, if desired. MOBIKE is not to change how IKEv2 NAT-T works in particular, any kind of UNSAF or explicit interaction with NATs (e.g., MIDCOM [RFC3303] or NSIS NATFW NSLP [WIP-Sti06]) is beyond the scope of the MOBIKE protocol. The MOBIKE protocol will need to define how MOBIKE and NAT-T are used together.
NAT検出ペイロードは、IPヘッダーのアドレスがパスに沿ったNATによって変更されたかどうかを判断するために使用されます。NATを検出するには、通常、必要に応じてIPSEC ESPパケットのUDPカプセル化を有効にする必要があります。Mobikeは、特にIKEV2 NAT-Tがどのように機能するか、NATとのあらゆる種類の不活性または明示的な相互作用（Midcom [RFC3303]またはNSIS NATFW NSLP [WIP-STI06]）との相互作用を変更することではありません。Mobikeプロトコルは、MobikeとNat-Tがどのように使用されるかを定義する必要があります。
The NAT-T support should also be optional. If the IKEv2 implementation does not implement NAT-T, as it is not required in some particular environment, implementing MOBIKE should not require adding support for NAT-T either.
The property of being behind NAT is actually a property of the address pair and thereby of the path taken by a packet. Thus, one peer can have multiple IP addresses, and some of those might be behind NAT and some might not.
NATの背後にいるという特性は、実際にはアドレスペアのプロパティであり、それによってパケットがとるパスのプロパティです。したがって、1人のピアに複数のIPアドレスを持つことができ、それらのいくつかはNATの背後にあり、一部はそうでないかもしれません。
There are some cases that cannot be carried out within MOBIKE. One of those cases is when the party "outside" a symmetric NAT changes its address to something not known by the other peer (and the old address has stopped working). It cannot send a packet containing the new addresses to the peer because the NAT does not contain the necessary state. Furthermore, since the party behind the NAT does not know the new IP address, it cannot cause the NAT state to be created.
Mobike内では実行できない場合があります。これらのケースの1つは、パーティーが「外部」である党が対称NATが他のピアに知られていないものにその住所を変更するときです（そして、古い住所は機能しなくなりました）。NATには必要な状態が含まれていないため、新しいアドレスを含むパケットをピアに送信することはできません。さらに、NATの後ろのパーティーは新しいIPアドレスを知らないため、NAT状態を作成することはできません。
This case could be solved using some rendezvous mechanism outside IKEv2, but that is beyond the scope of MOBIKE.
このケースは、IKEV2以外のいくつかのランデブーメカニズムを使用して解決できますが、それはMobikeの範囲を超えています。
The MOBIKE protocol should provide a mechanism whereby a peer that is initially not behind a NAT can move behind NAT when a new preferred address is selected. The same effect might be accomplished with the change of the address pair if more than one path is available (e.g., in the case of a multi-homed host). An impact for the MOBIKE protocol is only caused when the currently selected address pair causes MOBIKE packets to traverse a NAT.
Mobikeプロトコルは、新しい優先アドレスが選択されたときに最初にNATの背後にないピアがNATの後ろに移動できるメカニズムを提供する必要があります。複数のパスが利用可能な場合（たとえば、マルチホームのホストの場合）、アドレスペアの変更で同じ効果が達成される可能性があります。Mobikeプロトコルへの影響は、現在選択されているアドレスペアがMobikeパケットをNATを横断させる場合にのみ発生します。
Similarly, the MOBIKE protocol provides a mechanism to detect when a NATed path is changed to a non-NATed path with the change of the address pair.
As we only use one address pair at time, effectively the MOBIKE peer is either behind NAT or not behind NAT, but each address change can change this situation. Because of this, and because the initiator always chooses the addresses, it is enough to send keepalive packets only to that one address pair.
時間に1つのアドレスペアのみを使用するため、事実上、Mobike PeerはNATの背後にあるか、NATの背後にいませんが、各アドレスの変更はこの状況を変える可能性があります。このため、イニシエーターは常にアドレスを選択しているため、その1つのアドレスペアにのみKeepAliveパケットを送信するだけで十分です。
Enabling NAT-T involves a few different things. One is to enable the UDP encapsulation of ESP packets. Another is to change the IKE SA ports from port 500 to port 4500. We do not want to do unnecessary UDP encapsulation unless there is really a NAT between peers, i.e., UDP encapsulation should only be enabled when we actually detect NAT. On the other hand, as all implementations supporting NAT-T must be able to respond to port 4500 all the time, it is simpler from the protocol point of view to change the port numbers from 500 to 4500 immediately upon detecting that the other end supports NAT-T. This way it is not necessary to change ports after we later detected NAT, which would have caused complications to the protocol.
Nat-Tを有効にするには、いくつかの異なるものが含まれます。1つは、ESPパケットのUDPカプセル化を有効にすることです。もう1つは、IKE SAポートをポート500からポート4500に変更することです。ピア間に実際にNATがある場合を除き、不必要なUDPカプセル化を行いたくありません。つまり、UDPカプセル化は実際にNATを検出した場合にのみ有効にする必要があります。一方、NAT-Tをサポートするすべての実装は常にポート4500に応答できる必要があるため、プロトコルの観点からは、ポート番号をすぐに500から4500に変更することが簡単です。nat-t。このようにして、後にNATを検出した後、ポートを変更する必要はありません。
If we changed the port only after we detected NAT, then the responder would not be able to use the IKE and IPsec SAs immediately after their address is changed to be behind NAT. Instead, it would need to wait for the next packet from the initiator to see what IP and port numbers are used after the initiator changed its port from 500 to 4500. The responder would also not be able to send anything to the initiator before the initiator sent something to the responder. If we do the port number changing immediately after the IKE_SA_INIT and before IKE_AUTH phase, then we get the rid of this problem.
NATを検出した後にのみポートを変更した場合、レスポンダーは、住所がNATの背後にあるように変更された直後にIKEとIPSEC SASを使用できません。代わりに、イニシエーターから次のパケットがイニシエーターがポートを500から4500に変更した後に使用されるIPとポート番号を確認する必要があります。レスポンダーに何かを送りました。IKE_SA_INITの直後とIKE_AUTHフェーズの直前にポート番号が変更された場合、この問題を取り除きます。
MOBIKE can work in cases where the responder is behind a static NAT, but the initiator would need to know all the possible addresses to which the responder can move. That is, the responder cannot move to an address which is not known by the initiator, in case initiator also moves behind NAT.
Mobikeは、レスポンダーが静的NATの背後にある場合に機能しますが、イニシエーターは、レスポンダーが移動できるすべての可能なアドレスを知る必要があります。つまり、イニシエーターもNATの後ろに移動した場合に備えて、イニシエーターが知らないアドレスにレスポンダーが移動することはできません。
If the responder is behind a NAPT, then it might need to communicate with the NAT to create a mapping so the initiator can connect to it. Those external firewall pinhole opening mechanisms are beyond the scope of MOBIKE.
レスポンダーがNAPTの背後にある場合、イニシエーターがそれに接続できるようにマッピングを作成するためにNATと通信する必要がある場合があります。これらの外部ファイアウォールのピンホールオープニングメカニズムは、Mobikeの範囲を超えています。
In case the responder is behind NAPT, then finding the port numbers used by the responder is outside the scope of MOBIKE.
レスポンダーがNAPTの背後にある場合、レスポンダーが使用するポート番号がMobikeの範囲外であることがわかります。
One new feature created by MOBIKE is NAT prevention. If we detect NAT between the peers, we do not allow that address pair to be used. This can be used to protect IP addresses in cases where the configuration knows that there is no NAT between the nodes (for example IPv6, or fixed site-to-site VPN). This avoids any possibility of on-path attackers modifying addresses in headers. This feature means that we authenticate the IP address and detect if they were changed. As this is done on purpose to break the connectivity if NAT is detected, and decided by the configuration, there is no need to do UNSAF processing.
Mobikeによって作成された新しい機能の1つは、NAT予防です。ピア間でNATを検出した場合、そのアドレスペアの使用を許可しません。これは、構成がノードの間にNATがないことを知っている場合にIPアドレスを保護するために使用できます（たとえば、IPv6、または固定されたサイトからサイトへのVPN）。これにより、ヘッダーのアドレスを変更するパス攻撃者の可能性が回避されます。この機能は、IPアドレスを認証し、変更されたかどうかを検出することを意味します。これは、NATが検出され、構成によって決定された場合に接続性を破るために意図的に行われているため、UNSAF処理を行う必要はありません。
The working group decided that MOBIKE uses NAT-T mechanisms from the IKEv2 protocol as much as possible, but decided to change the dynamic address update (see [RFC4306], Section 2.23, second to last paragraph) for IKEv2 packets to "MUST NOT" (it would break path testing using IKEv2 packets; see Section 6.2). The working group also decided only to send keepalives to the current address pair.
Most sections of this document discuss design considerations for updating and maintaining addresses in the database entries that relate to an IKE SA. However, changing the preferred address also affects the entries of the IPsec SA database. The outer tunnel header addresses (source and destination IP addresses) need to be modified according to the current path to allow the IPsec protected data traffic to travel along the same path as the MOBIKE packets. If the MOBIKE messages and the IPsec protected data traffic travel along a different path, then NAT handling is severely complicated.
このドキュメントのほとんどのセクションでは、IKE SAに関連するデータベースエントリのアドレスを更新および維持するための設計上の考慮事項について説明しています。ただし、優先アドレスを変更すると、IPSEC SAデータベースのエントリにも影響します。外側のトンネルヘッダーアドレス（ソースおよび宛先IPアドレス）は、現在のパスに従って変更する必要があります。IPSEC保護されたデータトラフィックがMobikeパケットと同じパスに沿って移動できるようにします。MobikeメッセージとIPSECが保護されたデータトラフィックが異なるパスに沿って移動する場合、NATハンドリングは非常に複雑です。
The basic question is then how the IPsec SAs are changed to use the new address pair (the same address pair as the MOBIKE signaling traffic). One option is that when the IKE SA address is changed, all IPsec SAs associated with it are automatically moved along with it to a new address pair. Another option is to have a separate exchange to move the IPsec SAs separately.
基本的な質問は、IPSEC SASがどのように変更されて新しいアドレスペア（Mobike Signaling Trafficと同じアドレスペア）を使用するかです。1つのオプションは、IKE SAアドレスが変更された場合、それに関連付けられたすべてのIPSEC SASが新しいアドレスペアに自動的に移動されることです。別のオプションは、IPSEC SASを個別に移動するための個別の交換を行うことです。
If IPsec SAs should be updated separately, then a more efficient format than the Notify payload is needed to preserve bandwidth. A Notify payload can only store one Security Parameter Index (SPI) per payload. A separate payload could have a list of IPsec SA SPIs and the new preferred address. If there is a large number of IPsec SAs, those payloads can be quite large unless list of ranges of SPI values are supported. If we automatically move all IPsec SAs when the IKE SA moves, then we only need to keep track of which IKE SA was used to create the IPsec SA, and fetch the IP addresses from the IKE SA, i.e., there is no need to store IP addresses per IPsec SA. Note that IKEv2 [RFC4306] already requires the implementations to keep track of which IPsec SAs are created using which IKE SA.
IPSEC SASを個別に更新する必要がある場合、帯域幅を保持するために通知ペイロードよりも効率的な形式が必要です。通知ペイロードは、ペイロードごとに1つのセキュリティパラメーターインデックス（SPI）のみを保存できます。個別のペイロードには、IPSEC SA SPISと新しい優先アドレスのリストがあります。多数のIPSEC SASがある場合、SPI値の範囲のリストがサポートされない限り、これらのペイロードは非常に大きくなる可能性があります。IKE SAが移動したときにすべてのIPSEC SASを自動的に移動する場合、IKESAがIPSEC SAを作成するために使用され、IKE SAからIPアドレスを取得したことを追跡する必要があります。つまり、保存する必要はありません。IPSEC SAあたりのIPアドレス。IKEV2 [RFC4306]は、IKESAを使用して作成されたIPSEC SASを追跡するために実装を既に要求していることに注意してください。
If we do allow the address set of each IPsec SA to be updated separately, then we can support scenarios where the machine has fast and/or cheap connections and slow and/or expensive connections and wants to allow moving some of the SAs to the slower and/or more expensive connection, and prevent the move, for example, of the news video stream from the WLAN to the GPRS link.
各IPSEC SAのアドレスセットを個別に更新できる場合は、マシンに高速および/または安価な接続があり、遅い接続および/または高価な接続があり、SASの一部を遅くすることができるシナリオをサポートできます。より高価な接続、およびたとえば、WLANからGPRSリンクへのニュースビデオストリームの移動を防ぎます。
On the other hand, even if we tie the IKE SA update to the IPsec SA update, we can create separate IKE SAs for this scenario. For example, we create one IKE SA that has both links as endpoints, and it is used for important traffic; then we create another IKE SA which has only the fast and/or cheap connection, which is used for that kind of bulk traffic.
一方、Ike SAアップデートをIPSEC SAアップデートに結び付けたとしても、このシナリオ用に個別のIKE SASを作成できます。たとえば、両方のリンクをエンドポイントとして持つIKE SAを1つ作成し、重要なトラフィックに使用されます。次に、そのようなバルクトラフィックに使用される高速および/または安価な接続のみを備えた別のIKESAを作成します。
The working group decided to move all IPsec SAs implicitly when the IKE SA address pair changes. If more granular handling of the IPsec SA is required, then multiple IKE SAs can be created one for each set of IPsec SAs needed.
ワーキンググループは、IKE SAアドレスペアが変更されたときに、すべてのIPSEC SASを暗黙的に移動することを決定しました。IPSEC SAのより粒状の取り扱いが必要な場合は、IPSEC SASのセットごとに複数のIKE SASを作成できます。
One of the features that is potentially useful is for the peer to announce that it will now disconnect for some time, i.e., it will not be reachable at all. For instance, a laptop might go to suspend mode. In this case, it could send address notification with zero new addresses, which would mean that it will not have any valid addresses anymore. The responder would then acknowledge that notification and could then temporarily disable all SAs and therefore stop sending traffic. If any of the SAs get any packets, they are simply dropped. This could also include some kind of ACK spoofing to keep the TCP/IP sessions alive (or simply setting the TCP/IP keepalives and timeouts large enough not to cause problems), or it could simply be left to the applications, e.g., allow TCP/IP sessions to notice if the link is broken.
潜在的に有用な機能の1つは、ピアがしばらく切断されるようになることを発表することです。つまり、まったく到達できないことです。たとえば、ラップトップはサスペンドモードに移動する場合があります。この場合、新しいアドレスがゼロでアドレス通知を送信する可能性があります。これは、有効なアドレスがなくなることを意味します。その後、レスポンダーはその通知を認め、その後、すべてのSASを一時的に無効にして、トラフィックの送信を停止する可能性があります。SASのいずれかがパケットを取得した場合、それらは単純にドロップされます。これには、TCP/IPセッションを生かし続けるためのある種のACKスプーフィングが含まれます（または、問題を引き起こさないようにTCP/IP KeepAlivesとタイムアウトを十分に大きく設定するか、単にアプリケーションに任せられる可能性があります。たとえば、TCPを許可します。/リンクが壊れているかどうかに注意するIPセッション。
The local policy could then indicate how long the peer should allow remote peers to remain disconnected.
その後、ローカルポリシーは、ピアがリモートピアが切断されたままになる期間を示している可能性があります。
From a technical point of view, this would provide following two features: o There is no need to transmit IPsec data traffic. IPsec-protected data can be dropped, which saves bandwidth. This does not provide a functional benefit, i.e., nothing breaks if this feature is not provided.
o MOBIKE signaling messages are also ignored. The IKE SA must not be deleted, and the suspend functionality (realized with the zero address set) may require the IKE SA to be tagged with a lifetime value since the IKE SA should not be kept alive for an undefined period of time. Note that IKEv2 does not require that the IKE SA has a lifetime associated with it. In order to prevent the IKE SA from being deleted, the dead-peer detection mechanism needs to be suspended as well.
o Mobike Signalingメッセージも無視されます。IKE SAを削除する必要はなく、サスペンド機能（ゼロアドレスセットで実現）は、IKE SAを未定義の期間生存しておくべきではないため、IKE SAの生涯値でタグ付けする必要がある場合があります。IKEV2は、IKE SAがそれに関連する寿命を持っていることを必要としないことに注意してください。IKE SAが削除されるのを防ぐために、デッドピア検出メカニズムも同様に停止する必要があります。
Due to its complexity and no clear requirement for it, it was decided that MOBIKE does not support this feature.
その複雑さとその明確な要件のために、Mobikeはこの機能をサポートしていないことが決定されました。
Changing the preferred address and subsequently using it for communication is associated with an authorization decision: Is a peer allowed to use this address? Does this peer own this address? Two mechanisms have been proposed in the past to allow a peer to determine the answer to these questions:
優先アドレスを変更し、その後通信に使用することは、承認決定に関連付けられています。ピアはこのアドレスを使用することを許可されていますか？このピアはこの住所を所有していますか？過去に2つのメカニズムが提案されており、ピアがこれらの質問に対する答えを決定できるようにしています。
o The addresses a peer is using are part of a certificate. [RFC3554] introduced this approach. If the other peer is, for example, a security gateway with a limited set of fixed IP addresses, then the security gateway may have a certificate with all the IP addresses appearing in the certificate.
o
o A return routability check is performed by the remote peer before the address is updated in that peer's Security Association Database. This is done in order to provide a certain degree of confidence to the remote peer that the local peer is reachable at the indicated address.
o そのピアのセキュリティ協会データベースでアドレスが更新される前に、リモートピアによって返品ルー上のチェックが実行されます。これは、指定されたアドレスで地元のピアが到達できるというリモートピアにある程度の信頼性を提供するために行われます。
Without taking an authorization decision, a malicious peer can redirect traffic towards a third party or a black hole.
承認の決定を下さずに、悪意のあるピアはトラフィックをサードパーティまたはブラックホールにリダイレクトできます。
A MOBIKE peer should not use an IP address provided by another MOBIKE peer as a current address without computing the authorization decision. If the addresses are part of the certificate, then it is not necessary to execute the return routability check. The return routability check is a form of authorization check, although it provides weaker guarantees than the inclusion of the IP address as a part of a certificate. If multiple addresses are communicated to the remote peer, then some of these addresses may be already verified.
Finally, it would be possible not to execute return routability checks at all. In case of indirect change notifications (i.e., something we notice from the network, not from the peer directly), we only move to the new preferred address after successful dead-peer detection (i.e., a response to a DPD test) on the new address, which is already a return routability check. With a direct notification (i.e., notification from the other end directly) the authenticated peer may have provided an authenticated IP address (i.e., inside IKE encrypted and authenticated payload; see Section 5.2.5). Thus, it is would be possible simply to trust the MOBIKE peer to provide a proper IP address. In this case, a protection against an internal attacker (i.e., the authenticated peer forwarding its traffic to the new address) would not provided. On the other hand, we know the identity of the peer in that case. There might be problems when extensions are added to IKEv2 that do not require authentication of end points (e.g., opportunistic security using anonymous Diffie-Hellman).
最後に、返品性のルー上のチェックをまったく実行しない可能性があります。間接的な変更通知（つまり、ピアからではなくネットワークから気づくもの）の場合、新しいデッドピア検出（つまり、DPDテストへの応答）が新しい希望のアドレスに移動するのは、新しいものでのみ移動します。アドレス。これはすでに返品ルー上のチェックです。直接通知（つまり、反対側からの直接通知）を使用すると、認証されたピアが認証されたIPアドレスを提供している可能性があります（つまり、IKE暗号化および認証されたペイロード内;セクション5.2.5を参照）。したがって、単にMobike Peerが適切なIPアドレスを提供することを信頼することが可能です。この場合、内部攻撃者に対する保護（つまり、認証されたピアのトラフィックを新しいアドレスに転送する）は提供されません。一方、その場合のピアの身元を知っています。拡張機能がIKEV2に追加された場合、エンドポイントの認証を必要としない問題がある可能性があります（たとえば、匿名のdiffie-hellmanを使用した日和見的セキュリティ）。
There is also a policy issue of when to schedule a return routability check. Before moving traffic? After moving traffic?
また、返品ルー上のチェックをスケジュールする時期のポリシーの問題もあります。トラフィックを移動する前に？トラフィックを移動した後？
The basic format of the return routability check could be similar to dead-peer detection, but potential attacks are possible if a return routability check does not include some kind of a nonce. In these attacks, the valid end point could send an address update notification for a third party, trying to get all the traffic to be sent there, causing a denial-of-service attack. If the return routability check does not contain any nonce or other random information not known to the other peer, then the other peer could reply to the return routability checks even when it cannot see the request. This might cause a peer to move the traffic to a location where the original recipient cannot be reached.
返品ルー上のチェックの基本的な形式はデッドピア検出に似ている可能性がありますが、返品ルー上のチェックに何らかのNONCEが含まれていない場合、潜在的な攻撃が可能です。これらの攻撃では、有効なエンドポイントが第三者のアドレス更新通知を送信し、すべてのトラフィックをそこに送信しようとして、サービス拒否攻撃を引き起こす可能性があります。返品ルー上のチェックに他のピアに知られていないNonCEまたはその他のランダム情報が含まれていない場合、他のピアは、リクエストが表示されない場合でも、返品性のルー上のチェックに返信できます。これにより、ピアがトラフィックを元の受信者に到達できない場所に移動する可能性があります。
The IKEv2 NAT-T mechanism does not perform return routability checks. It simply uses the last seen source IP address used by the other peer as the destination address to which response packets are to be sent. An adversary can change those IP addresses and can cause the response packets to be sent to a wrong IP address. The situation is self-fixing when the adversary is no longer able to modify packets and the first packet with an unmodified IP address reaches the other peer. Mobility environments make this attack more difficult for an adversary since the attack requires the adversary to be located somewhere on the individual paths ({CoA1, ..., CoAn} towards the destination IP address), to have a shared path, or, if the adversary is located near the MOBIKE client, to follow the user mobility patterns. With IKEv2 NAT-T, the genuine client can cause third-party bombing by redirecting all the traffic pointed to him to a third party. As the MOBIKE protocol tries to provide equal or better security than IKEv2 NAT-T mechanism, it should protect against these attacks.
IKEV2 NAT-Tメカニズムは、Returability Checksを実行しません。他のピアで使用されている最後に見たソースIPアドレスを、応答パケットを送信する宛先アドレスとして使用するだけです。敵はこれらのIPアドレスを変更し、応答パケットを間違ったIPアドレスに送信する可能性があります。敵がパケットを変更できなくなり、変更されていないIPアドレスを使用して最初のパケットが他のピアに到達すると、状況は自己固定です。モビリティ環境では、攻撃は個々のパス（{coa1、...、coan}宛先IPアドレスに向かって）のどこかに敵を配置する必要があるため、敵を攻撃者にとってより困難にします。敵は、ユーザーのモビリティパターンに従うために、Mobikeクライアントの近くにあります。IKEV2 NAT-Tを使用すると、本物のクライアントは、彼に向けられたすべてのトラフィックを第三者にリダイレクトすることにより、サードパーティの爆撃を引き起こす可能性があります。Mobikeプロトコルは、IKEV2 NAT-Tメカニズムよりも平等またはより良いセキュリティを提供しようとするため、これらの攻撃から保護する必要があります。
There may be return routability information available from the other parts of the system too (as shown in Figure 3), but the checks done may have a different quality. There are multiple levels for return routability checks:
o None; no tests.
o なし;テストはありません。
o A party willing to answer the return routability check is located along the path to the claimed address. This is the basic form of return routability check.
o 返品ルー上のチェックに応答する意思のある当事者は、請求された住所へのパスに沿って配置されます。これは、返品ルー上のチェックの基本的な形式です。
o There is an answer from the tested address, and that answer was authenticated and integrity- and replay-protected.
o テストされたアドレスからの答えがあり、その答えは認証され、整合性であり、リプレイで保護されていました。
o There was an authenticated and integrity- and replay-protected answer from the peer, but it is not guaranteed to originate at the tested address or path to it (because the peer can construct a response without seeing the request).
o ピアからの認証された整合性とリプレイで保護された回答がありましたが、テストされたアドレスやそれへのパスで発生することは保証されていません（ピアはリクエストを表示せずに応答を構築できるため）。
The return routability checks do not protect against third-party bombing if the attacker is along the path, as the attacker can forward the return routability checks to the real peer (even if those packets are cryptographically authenticated).
攻撃者がパスに沿っている場合、攻撃者がパスに沿っている場合、返品ルー上のチェックはサードパーティの爆撃から保護しません。攻撃者はリターンルー上のチェックを実際のピアに転送できます（これらのパケットが暗号化されている場合でも）。
If the address to be tested is carried inside the MOBIKE payload, then the adversary cannot forward packets. Thus, third-party bombings are prevented (see Section 5.2.5).
テストするアドレスがMobikeペイロード内で運ばれる場合、敵はパケットを転送できません。したがって、サードパーティの爆撃は防止されます（セクション5.2.5を参照）。
If the reply packet can be constructed without seeing the request packet (for example, if there is no nonce, challenge, or similar mechanism to show liveness), then the genuine peer can cause third-party bombing, by replying to those requests without seeing them at all.
リクエストパケットをリクエストパケットを表示せずに構築できる場合（たとえば、快適さを示すために非CE、課題、または同様のメカニズムがない場合）、本物のピアは、それらのリクエストに表示せずに返信することにより、サードパーティの爆撃を引き起こす可能性があります。それらはまったく。
Other levels might only provide a guarantee that there is a node at the IP address that replied to the request. There is no indication as to whether or not the reply is fresh or whether or not the request may have been transmitted from a different source address.
If MOBIKE has learned about new locations or verified the validity of a remote address through a return routability check, can this information be useful for other protocols? When the basic MOBIKE VPN scenario is considered, the answer is no. Transport and application layer protocols running inside the VPN tunnel are unaware of the outer addresses or their status.
Mobikeが新しい場所について学んだか、返品ルー上のチェックを通じてリモートアドレスの有効性を確認した場合、この情報は他のプロトコルに役立つことができますか？基本的なMobike VPNシナリオを考慮すると、答えはノーです。VPNトンネル内で実行される輸送およびアプリケーション層プロトコルは、外側のアドレスまたはそのステータスに気付いていません。
Similarly, IP-layer tunnel termination at a gateway rather than a host endpoint limits the benefits for "other protocols" that could be informed -- all application protocols at the other side are unaware of IPsec, IKE, or MOBIKE.
同様に、ホストのエンドポイントではなくゲートウェイでのIP層トンネル終端により、通知できる「他のプロトコル」の利点が制限されます。
However, it is conceivable that future uses or extensions of the MOBIKE protocol make such information distribution useful. For instance, if transport mode MOBIKE and SCTP were made to work together, it would potentially be useful for SCTP dynamic address reconfiguration [WIP-Ste06] to learn about the new addresses at the same time as MOBIKE. Similarly, various IP-layer mechanisms may make use of the fact that a return routability check of a specific type has been performed. However, care should be exercised in all these situations.
ただし、将来のMobikeプロトコルの使用または拡張により、このような情報配信が役立つと考えられます。たとえば、輸送モードのMobikeとSCTPが一緒に動作するように作られた場合、SCTP動的アドレス再構成[WIP-STE06]がMobikeと同時に新しいアドレスについて学ぶことが役立つ可能性があります。同様に、さまざまなIP層メカニズムが、特定のタイプの返品ルー上のチェックが実行されているという事実を利用する可能性があります。ただし、これらすべての状況で注意を払う必要があります。
[WIP-Cro04] discusses the use of common locator information pools in a IPv6 multi-homing context; it assumes that both transport and IP-layer solutions are used in order to support multi-homing, and that it would be beneficial for different protocols to coordinate their results in some way, for instance, by sharing throughput information of address pairs. This may apply to MOBIKE as well, assuming it coexists with non-IPsec protocols that are faced with the same or similar multi-homing choices.
[WIP-Cro04]は、IPv6マルチホミングコンテキストでの一般的なロケーター情報プールの使用について説明します。マルチホミングをサポートするために輸送ソリューションとIP層ソリューションの両方が使用されており、例えば、アドレスペアのスループット情報を共有することにより、さまざまなプロトコルが何らかの方法で結果を調整することが有益であると想定しています。これは、Mobikeにも適用される場合があります。これは、同じまたは類似のマルチホームの選択に直面している非IPSECプロトコルと共存すると仮定します。
Nevertheless, all of this is outside the scope of the current MOBIKE base protocol design and may be addressed in future work.
それにもかかわらず、これはすべて現在のMobike Base Protocol Designの範囲外であり、将来の仕事で対処される可能性があります。
If the return routability check fails, we need to tear down the IKE SA if we are using IKEv2 INFORMATIONAL exchanges to send return routability checks. On the other hand, return routability checks can only fail permanently if there was an attack by the other end; thus, tearing down the IKE SA is a suitable action in that case.
Returnabability Checkが失敗した場合、IKEV2情報交換を使用してReturn Rusabilityチェックを送信する場合、IKE SAを取り壊す必要があります。一方、RETURNルーティング可能性チェックは、反対側から攻撃があった場合にのみ永久に失敗する可能性があります。したがって、Ike SAを取り壊すことは、その場合に適切なアクションです。
There are some cases, where the return routability check temporarily fails, that need to be considered here. In the first case, there is no attacker, but the selected address pair stops working immediately after the address update, before the return routability check.
ここで考慮する必要がある場合、返品ルーティング可能性チェックが一時的に失敗する場合があります。最初のケースでは、攻撃者はいませんが、選択されたアドレスペアは、アドレスの更新後、返品ルーティング可能性チェックの直前に動作しなくなります。
What happens is that the initiator performs the normal address update; it succeeds, and then the responder starts a return routability check. If the address pair has broken down before that, the responder will never get back the reply to the return routability check. The responder might still be using the old IP address pair, which could still work.
何が起こるかは、イニシエーターが通常のアドレスアップデートを実行することです。それは成功し、その後、レスポンダーは返品ルー上のチェックを開始します。その前にアドレスペアが分解された場合、Responderが返品ルーティング可能性チェックへの返信を返すことはありません。レスポンダーはまだ古いIPアドレスペアを使用している可能性がありますが、これは機能する可能性があります。
The initiator might be still seeing traffic from the responder, but using the old address pair. The initiator should detect that this traffic is not using the latest address pair, and after a while it should start dead peer detection on the current address pair. If that fails, then it should find a new working address pair and update addresses to that. The responder should notice that the address pair was updated after the return routability check was started and change the ongoing return routability check to use the new address pair. The result of that return routability check needs to be discarded as it cannot be trusted; the packets were retransmitted to a different IP address. So normally the responder starts a new return routability check afterward with the new address pair.
イニシエーターは、レスポンダーからのトラフィックがまだ表示されている可能性がありますが、古いアドレスペアを使用しています。イニシエーターは、このトラフィックが最新のアドレスペアを使用していないことを検出する必要があり、しばらくすると、現在のアドレスペアで死んだピア検出を開始する必要があります。それが失敗した場合、新しい作業アドレスペアとそれを更新するアドレスを見つけてください。レスポンダーは、返品ルー上のチェックが開始された後にアドレスペアが更新されたことに気付き、継続的な返品ルーティング可能性チェックを変更して新しいアドレスペアを使用します。その返品ルー上のチェックの結果は、信頼できないため、破棄する必要があります。パケットは別のIPアドレスに再送信されました。したがって、通常、レスポンダーは新しいアドレスペアで新しい返品ルーティング可能性チェックを開始します。
The second case is where there is an attacker along the path modifying the IP addresses. The peers will detect this as NAT and will enable NAT-T recovery of changes in the NAT mappings. If the attacker is along the path long enough for the return routability check to succeed, then the normal recovery of changes in the NAT mappings will take care of the problem. If the attacker disappears before return routability check is finished, but after the update, we have a case similar to the last. The only difference is that now the dead peer detection started by the initiator will succeed because the responder will reply to the addresses in the headers, not the current address pair. The initiator will then detect that the NAT mappings are changed, and it will fix the situation by doing an address update.
2番目のケースは、IPアドレスを変更するパスに沿って攻撃者がいる場合です。ピアはこれをNATとして検出し、NATマッピングの変化のNAT-T回復を可能にします。攻撃者が返品ルーティング可能性チェックが成功するのに十分な長さのパスに沿っている場合、NATマッピングの変更の通常の回復が問題を処理します。返品可能性チェックが終了する前に攻撃者が消えた場合、更新後、最後に似たケースがあります。唯一の違いは、現在のアドレスペアではなく、レスポンダーがヘッダーのアドレスに返信するため、イニシエーターによって開始された死んだピア検出が成功することです。イニシエーターは、NATマッピングが変更されることを検出し、アドレスの更新を行うことで状況を修正します。
The important thing for both of these cases is that the initiator needs to see that the responder is both alive and synchronized with initiator address pair updates. That is, it is not enough that the responder is sending traffic to an initiator; it must also be using the correct IP addresses before the initiator can believe it is alive and synchronized. From the implementation point of view, this means that the initiator must not consider packets having wrong IP addresses as packets that prove the other end is alive, i.e., they do not reset the dead peer detection timers.
The working group selected to use IKEv2 INFORMATIONAL exchanges as a return routability check, but included a random cookie to prevent redirection by an authenticated attacker. Return routability checks are performed by default before moving the traffic. However, these tests are optional. Nodes may also perform these tests upon their own initiative at other times.
It is worth noting that the return routability check in MOBIKE is different from Mobile IPv6 [RFC3775], which does not perform return routability operations between the mobile node and its home agent at all.
Mobikeの返品ルー上のチェックは、モバイルノードとそのホームエージェント間の返品性操作をまったく実行しないモバイルIPv6 [RFC3775]とは異なることに注意してください。
The current MOBIKE design is focused only on the VPN type usage and tunnel mode. Transport mode behavior would also be useful and might be discussed in future documents.
現在のMobike Designは、VPNタイプの使用法とトンネルモードにのみ焦点を当てています。輸送モードの動作も有用であり、将来の文書で議論される可能性があります。
In order for MOBIKE to function, both peers must implement the MOBIKE extension of IKEv2. If one of the peers does not support MOBIKE, then, whenever an IP address changes, IKEv2 will have to be re-run in order to create a new IKE SA and the respective IPsec SAs. In MOBIKE, a peer needs to be confident that its address change messages are understood by the other peer. If these messages are not understood, it is possible that connectivity between the peers is lost.
Mobikeが機能するためには、両方のピアがIKEV2のMobike Extensionを実装する必要があります。ピアの1人がMobikeをサポートしていない場合、IPアドレスが変更されるたびに、新しいIKE SAとそれぞれのIPSEC SASを作成するためにIKEV2を再実行する必要があります。Mobikeでは、ピアはそのアドレス変更メッセージが他のピアによって理解されると確信する必要があります。これらのメッセージが理解されていない場合、ピア間の接続性が失われる可能性があります。
One way to ensure that a peer receives feedback on whether its messages are understood by the other peer is to use IKEv2 messaging for MOBIKE and to mark some messages as "critical". According to the IKEv2 specification, either such messages have to be understood by the receiver, or an error message has to be returned to the sender.
ピアが他のピアによってそのメッセージが理解されているかどうかについてのフィードバックを確実に受信する1つの方法は、MobikeにIKEV2メッセージングを使用し、いくつかのメッセージを「クリティカル」としてマークすることです。IKEV2仕様によると、そのようなメッセージを受信機が理解する必要があるか、エラーメッセージを送信者に返す必要があります。
A second way to ensure receipt of the above-mentioned feedback is by using Vendor ID payloads that are exchanged during the initial IKEv2 exchange. These payloads would then indicate whether or not a given peer supports the MOBIKE protocol.
上記のフィードバックを確保する2番目の方法は、最初のIKEV2交換中に交換されるベンダーIDペイロードを使用することです。これらのペイロードは、特定のピアがMobikeプロトコルをサポートするかどうかを示します。
A third approach would use the Notify payload to indicate support of MOBIKE extension. Such Notify payloads are also used for indicating NAT traversal support (via NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads).
3番目のアプローチでは、Notifyペイロードを使用して、Mobike Extensionのサポートを示します。このような通知ペイロードは、NATトラバーサルサポートを示すためにも使用されます（NAT_DETECTION_SOURCE_IPおよびNAT_DETECTION_DESTINATION_IPペイロード）。
Both a Vendor ID and a Notify payload may be used to indicate the support of certain extensions.
ベンダーIDと通知ペイロードの両方を使用して、特定の拡張機能のサポートを示すことができます。
Note that a MOBIKE peer could also attempt to execute MOBIKE opportunistically with the critical bit set when an address change has occurred. The drawback of this approach is, however, that an unnecessary message exchange is introduced.
Mobike Peerは、アドレスの変更が発生したときにクリティカルビットセットを使用してMobikeを日和見的に実行しようとすることもできます。ただし、このアプローチの欠点は、不必要なメッセージ交換が導入されていることです。
Although Vendor ID payloads and Notify payloads are technically equivalent, Notify payloads are already used in IKEv2 as a capability negotiation mechanism. Hence, Notify payloads are used in MOBIKE to indicate support of MOBIKE protocol.
Also, as the information of the support of MOBIKE is not needed during the IKE_SA_INIT exchange, the indication of the support is done inside the IKE_AUTH exchange. The reason for this is the need to keep the IKE_SA_INIT messages as small as possible so that they do not get fragmented. IKEv2 allows that the responder can do stateless processing of the first IKE_SA_INIT packet and request a cookie from the other end if it is under attack. To mandate the responder to be able to reassemble initial IKE_SA_INIT packets would not allow fully stateless processing of the initial IKE_SA_INIT packets.
また、IKE_SA_INIT Exchangeでは、Mobikeのサポートの情報は必要ないため、サポートの表示はIKE_AUTH Exchange内で行われます。この理由は、IKE_SA_INITメッセージを断片化しないようにできるだけ小さくする必要があるためです。IKEV2を使用すると、Responderが最初のIKE_SA_INITパケットのステートレス処理を行い、攻撃を受けている場合は反対側からCookieを要求できます。Responderに初期のIKE_SA_INITパケットを再組み立てることができるように義務付けても、初期のIKE_SA_INITパケットの完全なステートレス処理は許可されません。
As IKEv2 has a window of outgoing messages, and the sender is not allowed to violate that window (meaning that if the window is full, then the sender cannot send packets), it can cause some complications to path testing. Another complication created by IKEv2 is that once the message is created and sent to the other end, it cannot be modified in its future retransmissions. This makes it impossible to know what packet actually reached the other end first. We cannot use IP headers to find out which packet reached the other end first because if the responder gets retransmissions of the packet it has already processed and replied to (and those replies might have been lost due unidirectional address pair), it will retransmit the previous reply using the new address pair of the request. Because of this, it might be possible that the responder has already used the IP address information from the header of the previous packet, and the reply packet ending up at the initiator has a different address pair.
ikev2には発信メッセージのウィンドウがあり、送信者はそのウィンドウに違反することを許可されていないため（ウィンドウがいっぱいの場合、送信者はパケットを送信できないことを意味します）、パステストに合併症を引き起こす可能性があります。IKEV2によって作成されたもう1つの複雑さは、メッセージが作成されて反対側に送信されると、将来の再送信で変更できないことです。これにより、最初にどのパケットが反対側に到達したかを知ることが不可能になります。IPヘッダーを使用して最初に反対側に到達したパケットを見つけることはできません。レスポンダーが既に処理および返信したパケットの再送信を取得した場合（およびそれらの返信が一方向のアドレスペアが失われた可能性があるため）、以前のものを再送信します。リクエストの新しいアドレスペアを使用して返信します。このため、レスポンダーが以前のパケットのヘッダーからのIPアドレス情報を既に使用している可能性があり、イニシエーターで終わる返信パケットのアドレスペアは異なります。
Another complication comes from NAT-T. The current IKEv2 document says that if NAT-T is enabled, the node not behind NAT SHOULD detect if the IP address changes in the incoming authenticated packets and update the remote peers' addresses accordingly. This works fine with NAT-T, but it causes some complications in MOBIKE, as MOBIKE needs the ability to probe other address pairs without breaking the old one.
別の合併症はNat-Tから来ています。現在のIKEV2ドキュメントには、NAT-Tが有効になっている場合、NATの背後にないノードは、IPアドレスが着信パケットで変更され、それに応じてリモートピアアドレスを更新するかどうかを検出する必要があると述べています。これはNat-Tで正常に動作しますが、Mobikeは古いものを壊さずに他のアドレスペアを調べる能力を必要とするため、Mobikeにいくつかの合併症を引き起こします。
One approach to fix this would be to add a completely new protocol that is outside the IKE SA message id limitations (window code), outside identical retransmission requirements, and outside the dynamic address updating of NAT-T.
Another approach is to make the protocol so that it does not violate window restrictions and does not require changing the packet on retransmissions, and change the dynamic address updating of NAT-T to "MUST NOT" for IKE SA packets if MOBIKE is used. In order not to violate window restrictions, the addresses of the currently ongoing exchange need to be changed to test different paths. In order not to require that the packet be changed after it is first sent requires that the protocol restart from the beginning in case the packet was retransmitted to different addresses (because the sender does not know which packet the responder got first, i.e., which IP addresses it used).
別のアプローチは、ウィンドウの制限に違反しないようにプロトコルを作成し、再送信時にパケットを変更する必要がないようにし、Mobikeが使用されている場合はIke SAパケットの動的アドレスの更新をIKE SAパケットの「不可能」に変更することです。窓の制限に違反しないために、現在進行中の交換のアドレスを異なるパスをテストするために変更する必要があります。パケットが最初に送信された後に変更されることを要求しないようにするために、パケットが異なるアドレスに再送信された場合に備えて、プロトコルが最初からプロトコルを再起動する必要があります（送信者は、どのパケットが最初になったか、つまりどのIP IPを取得したかを知らないため使用したアドレス）。
The working group decided to use normal IKEv2 exchanges for path testing and decided to change the dynamic address updating of NAT-T to MUST NOT for IKE SA packets; a new protocol outside of IKEv2 was not adopted.
ワーキンググループは、パステストのために通常のIKEV2交換を使用することを決定し、IKE SAパケットに対してNAT-Tの動的アドレス更新を変更することを決定しました。IKEV2以外の新しいプロトコルは採用されていません。
The IP address change notifications can be sent either via an informational exchange already specified in IKEv2, or via a MOBIKE-specific message exchange. Using an informational exchange has the main advantage that it is already specified in the IKEv2 protocol and implementations can already incorporate the functionality.
IPアドレスの変更通知は、IKEV2で既に指定されている情報交換、またはMobike固有のメッセージ交換を介して送信できます。情報交換を使用するには、IKEV2プロトコルで既に指定されている主な利点があり、実装は機能を既に組み込むことができます。
Another question is the format of the address update notifications. The address update notifications can include multiple addresses, of which some may be IPv4 and some IPv6 addresses. The number of addresses is most likely going to be limited in typical environments (with less than 10 addresses). The format may need to indicate a preference value for each address. The format could either contain a preference number that determines the relative order of the addresses or could simply be an ordered list of IP addresses. If using preference numbers, then two addresses can have the same preference value; an ordered list avoids this situation.
別の質問は、アドレス更新通知の形式です。アドレス更新通知には、複数のアドレスを含めることができます。その一部はIPv4および一部のIPv6アドレスである場合があります。アドレスの数は、典型的な環境では限られている可能性が最も高くなります（10個未満のアドレスがあります）。フォーマットは、各アドレスの優先値を示す必要がある場合があります。この形式には、アドレスの相対順序を決定する優先番号を含めるか、単にIPアドレスの順序付けられたリストになる可能性があります。優先番号を使用する場合、2つのアドレスが同じ優先値を持つことができます。順序付けられたリストは、この状況を回避します。
Load balancing is currently outside the scope of MOBIKE; however, future work might include support for it. The selected format needs to be flexible enough to include additional information in future versions of the protocol (e.g., to enable load balancing). This may be realized with an reserved field, which can later be used to store additional information. As other information may arise that may have to be tied to an address in the future, a reserved field seems like a prudent design in any case.
There are two basic formats that place IP address lists into a message. One includes each IP address as separate payload (where the payload order indicates the preference order, or the payload itself might include the preference number). Alternatively, we can put the IP address list as one payload to the exchange, and that one payload will then have an internal format that includes the list of IP addresses.
Having multiple payloads, each one carrying one IP address, makes the protocol probably easier to parse, as we can already use the normal IKEv2 payload parsing procedures. It also offers an easy way for the extensions, as the payload probably contains only the type of the IP address (or the type is encoded to the payload type), and the IP address itself. As each payload already has a length field associated to it, we can detect if there is any extra data after the IP address. Some implementations might have problems parsing more than a certain number of IKEv2 payloads, but if the sender sends them in the most preferred first, the receiver can only use the first addresses it was willing to parse.
複数のペイロードがあり、それぞれが1つのIPアドレスを運ぶと、通常のIKEV2ペイロード解析手順を既に使用できるため、プロトコルをおそらく解析しやすくなります。また、ペイロードにはIPアドレスのタイプのみ（またはタイプがペイロードタイプにエンコードされている）とIPアドレス自体のみが含まれるため、拡張機能に簡単な方法を提供します。各ペイロードにはすでに関連付けられた長さフィールドがあるため、IPアドレスの後に追加のデータがあるかどうかを検出できます。いくつかの実装には、特定の数のIKEV2ペイロードよりも多くの解析に問題がある場合がありますが、送信者が最初に最も優先されるものでそれらを送信する場合、受信者は解析する意思がある最初のアドレスのみを使用できます。
Having all IP addresses in one big MOBIKE-specified internal format provides more compact encoding and keeps the MOBIKE implementation more concentrated to one module.
すべてのIPアドレスを1つの大きなMobike指定内部形式に配置すると、よりコンパクトなエンコードが可能になり、Mobikeの実装が1つのモジュールにより濃縮されます。
Another choice is which type of payloads to use. IKEv2 already specifies a Notify payload. It includes some extra fields (SPI size, SPI, protocol, etc.), which gives 4 bytes of the extra overhead, and there is the notification data field, which could include the MOBIKE-specific data.
別の選択肢は、どのタイプのペイロードを使用するかです。IKEV2は既にNotifyペイロードを指定しています。これには、追加のフィールド（SPIサイズ、SPI、プロトコルなど）が含まれており、4バイトの追加オーバーヘッドが得られ、Mobike固有のデータを含めることができる通知データフィールドがあります。
Another option would be to have a custom payload type, which would then include the information needed for the MOBIKE protocol.
別のオプションは、カスタムペイロードタイプを持つことです。これには、Mobikeプロトコルに必要な情報が含まれます。
The working group decided to use IKEv2 Notify payloads, and put only one data item per notify. There will be one Notify payload for each item to be sent.
ワーキンググループは、IKEV2がペイロードを通知することを使用することを決定し、Notifyごとに1つのデータ項目のみを配置することにしました。各アイテムが送信されるように、通知のペイロードが1つあります。
Because the initiator decides all address updates, the initiator needs to know all the addresses used by the responder. The responder also needs that list in case it happens to move to an address not known by the initiator, and it needs to send an address update notification to the initiator. It might need to try different addresses for the initiator.
イニシエーターはすべてのアドレスの更新を決定するため、イニシエーターはレスポンダーが使用するすべてのアドレスを知る必要があります。また、Responderは、イニシエーターが知らないアドレスに移動した場合にそのリストを必要とし、アドレス更新通知をイニシエーターに送信する必要があります。イニシエーターのさまざまなアドレスを試す必要があるかもしれません。
MOBIKE could send the whole peer address list every time any of the IP addresses change (addresses are added or removed, the order changes, or the preferred address is updated) or an incremental update. Sending incremental updates provides more compact packets (meaning we can support more IP addresses), but on the other hand this approach has more problems in the synchronization and packet reordering cases. That is, incremental updates must be processed in order, but for full updates we can simply use the most recent one and ignore old ones, even if they arrive after the most recent one (IKEv2 packets have a message ID that is incremented for each packet; thus, it is easy to know the sending order).
Mobikeは、IPアドレスが変更されるたびにピアアドレスリスト全体を送信することができます（アドレスが追加または削除されるか、注文の変更、または優先アドレスが更新されます）またはインクリメンタル更新を行うことができます。インクリメンタルアップデートを送信すると、よりコンパクトなパケットが提供されます（より多くのIPアドレスをサポートできることを意味します）が、一方で、このアプローチは同期とパケットの並べ替えケースにさらに問題があります。つまり、増分更新は順番に処理する必要がありますが、完全な更新のために、最新のものを使用して古いものを無視することができます。;したがって、送信順序を簡単に知ることができます）。
The working group decided to use a protocol format where both ends send a full list of their addresses to the other end, and that list overwrites the previous list. To support NAT-T, the IP addresses of the received packet are considered as one address of the peer, even when they are not present in the list.
ワーキンググループは、プロトコル形式を使用することを決定しました。ここでは、両端がアドレスの完全なリストをもう一方の端に送信し、そのリストは前のリストを上書きします。NAT-Tをサポートするために、受信したパケットのIPアドレスは、リストに存在しない場合でも、ピアの1つのアドレスと見なされます。
As all the packets are already authenticated by IKEv2, there is no risk that any attackers would undetectedly modify the contents of the packets. The IP addresses in the IP header of the packets are not authenticated; thus, the protocol defined must take care that they are only used as an indication that something might be different, and that they do not cause any direct actions, except when doing NAT traversal.
すべてのパケットはすでにIKEV2によって認証されているため、攻撃者がパケットの内容を検出されなく変更するリスクはありません。パケットのIPヘッダーのIPアドレスは認証されていません。したがって、定義されたプロトコルは、それらが何かが異なる可能性があること、およびNATトラバーサルを行う場合を除き、直接的なアクションを引き起こさないことを示すものとしてのみ使用されることに注意する必要があります。
An attacker can also spoof ICMP error messages in an effort to confuse the peers about which addresses are not working. At worst, this causes denial of service and/or the use of non-preferred addresses.
One type of attack that needs to be taken care of in the MOBIKE protocol is the bombing attack type. See [RFC4225] and [Aur02] for more information about flooding attacks.
Mobikeプロトコルで世話をする必要がある攻撃の1つは、爆撃攻撃タイプです。洪水攻撃の詳細については、[RFC4225]および[AUR02]を参照してください。
See the security considerations section of [RFC4555] for more information about security considerations of the actual protocol.
実際のプロトコルのセキュリティに関する考慮事項の詳細については、[RFC4555]のセキュリティに関する考慮事項セクションを参照してください。
This document is the result of discussions in the MOBIKE working group. The authors would like to thank Jari Arkko, Pasi Eronen, Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld, James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch, Udo Schilcher, Tom Henderson, Andreas Pashalidis, and Maureen Stillman for their input.
We would like to particularly thank Pasi Eronen for tracking open issues on the MOBIKE mailing list. He helped us make good progress on the document.
Mobikeメーリングリストのオープンな問題を追跡してくれたPasi Eronenに特に感謝します。彼は私たちが文書で良い進歩を遂げるのを助けました。
[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月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[Aur02] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", In Proc. 18th Annual Computer Security Applications Conference, pages 78-87, Las Vegas, NV USA, December 2002.
[AUR02] Aura、T.、Roe、M。、およびJ. Arkko、「インターネットロケーション管理のセキュリティ」、Proc。第18回年次コンピューターセキュリティアプリケーション会議、78〜87ページ、ラスベガス、NV米国、2002年12月。
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367] McDonald、D.、Metz、C。、およびB. Phan、「PF_KEY Key Management API、バージョン2」、RFC 2367、1998年7月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[RFC3303] Srisuresh、P.、Kuthan、J.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「Middlebox Communication Architecture and Framework」、RFC 3303、2002年8月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424] Daigle、L。およびIAB、「ネットワークアドレス翻訳全体の一方的な自己アドレス固定（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[RFC3554] Bellovin、S.、Ioannidis、J.、Keromytis、A。、およびR. Stewart、「IPSECを使用したストリーム制御伝送プロトコル（SCTP）の使用」、RFC 3554、2003年7月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753] MANER、J。およびM. Kojo、「Mobility関連用語」、RFC 3753、2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[RFC4225] Nikander、P.、Arkko、J.、Aura、T.、Montenegro、G。、およびE. Nordmark、「モバイルIPバージョン6ルート最適化セキュリティデザイン背景」、RFC 4225、2005年12月。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.
[RFC4429]ムーア、N。、「IPv6の楽観的な重複アドレス検出（DAD）」、RFC 4429、2006年4月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555] Eronen、P。、「IKEV2モビリティおよびマルチホミングプロトコル（MOBIKE）」、RFC 4555、2006年6月。
[WIP-Ark06] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", Work in Progress, June 2006.
[WIP-ARK06] Arkko、J。およびI. Beijnum、「IPv6 Multihomingの障害検出およびロケーターペア探査プロトコル」、2006年6月、進行中の作業。
[WIP-Cro04] Crocker, D., "Framework for Common Endpoint Locator Pools", Work in Progress, February 2004.
[WIP-CRO04] Crocker、D。、「Common Endpoint Locator Poolsのフレームワーク」、2004年2月の作業進行中。
[WIP-Nik06] Nikander, P., "End-Host Mobility and Multihoming with the Host Identity Protocol", Work in Progress, June 2006.
[WIP-NIK06] Nikander、P。、「ホストIDプロトコルを使用したエンドホストモビリティとマルチホミング」、2006年6月、Work in Progress。
[WIP-Ste06] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", Work in Progress, June 2006.
[WIP-STE06] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M。、およびP. Conrad、「Stream Control Transmission Protocol（SCTP）動的アドレス再構成」、2006年6月の作業。
[WIP-Sti06] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, June 2006.
[WIP-STI06] Stiemerling、M.、Tschofenig、H.、Aoun、C。、およびE. Davies、「Nat/Firewall NSIS Signaling Layer Protocol（NSLP）」、2006年6月の作業。
Authors' Addresses
著者のアドレス
Tero Kivinen Safenet, Inc. Fredrikinkatu 47 HELSINKI FI-00100 FI
EMail: kivinen@safenet-inc.com
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich、Bavaria 81739ドイツ
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。