[要約] RFC 4555は、IKEv2 Mobility and Multihoming Protocol（MOBIKE）に関する規格です。MOBIKEは、モバイルデバイスの移動や複数のネットワーク接続に対応するためのプロトコルであり、セキュアな通信を維持することを目的としています。
Network Working Group P. Eronen, Ed.
Request for Comments: 4555 Nokia
Category: Standards Track June 2006
IKEv2 Mobility and Multihoming Protocol (MOBIKE)
IKEV2モビリティとマルチホミングプロトコル（Mobike）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change. A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working.
このドキュメントでは、Mobike Protocol、Movility and Multihoming Extension to Internet Key Exchange（IKEV2）について説明しています。Mobikeを使用すると、IKEV2およびトンネルモードIPSECセキュリティアソシエーションに関連付けられたIPアドレスを変更できます。モバイル仮想プライベートネットワーク（VPN）クライアントは、Mobikeを使用して、あるアドレスから別のアドレスに移動しながら、VPNゲートウェイとの接続をアクティブに保つことができます。同様に、マルチホームのホストは、Mobikeを使用して、現在使用されているものが機能している場合、トラフィックを別のインターフェイスに移動させることができます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 4
1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5
2.2. Example Protocol Exchanges . . . . . . . . . . . . . . . . 6
2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 9
3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 10
3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 10
3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 11
3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 11
3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 12
3.6. Updating Additional Addresses . . . . . . . . . . . . . . 15
3.7. Return Routability Check . . . . . . . . . . . . . . . . . 17
3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18
3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 19
3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20
3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 20
3.12. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 20
4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Notify Messages - Error Types . . . . . . . . . . . . . . 21
4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 24
5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 24
5.3. Denial-of-Service Attacks against Third Parties . . . . . 25
5.4. Spoofing Network Connectivity Indications . . . . . . . . 26
5.5. Address and Topology Disclosure . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Implementation Considerations . . . . . . . . . . . . 31
A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 31
A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 31
IKEv2 is used for performing mutual authentication, as well as establishing and maintaining IPsec Security Associations (SAs). In the base IKEv2 protocol [IKEv2], the IKE SAs and tunnel mode IPsec SAs are created implicitly between the IP addresses that are used when the IKE_SA is established. These IP addresses are then used as the outer (tunnel header) addresses for tunnel mode IPsec packets (transport mode IPsec SAs are beyond the scope of this document). Currently, it is not possible to change these addresses after the IKE_SA has been created.
IKEV2は、相互認証の実行、およびIPSECセキュリティ協会（SAS）の確立と維持に使用されます。ベースIKEV2プロトコル[IKEV2]では、IKE SASおよびトンネルモードIPSEC SASは、IKE_SAが確立されたときに使用されるIPアドレス間で暗黙的に作成されます。これらのIPアドレスは、トンネルモードIPSECパケットの外側（トンネルヘッダー）アドレスとして使用されます（トランスポートモードIPSEC SASは、このドキュメントの範囲を超えています）。現在、IKE_SAが作成された後、これらのアドレスを変更することはできません。
There are scenarios where these IP addresses might change. One example is mobility: a host changes its point of network attachment and receives a new IP address. Another example is a multihoming host that would like to change to a different interface if, for instance, the currently used interface stops working for some reason.
これらのIPアドレスが変更される可能性のあるシナリオがあります。1つの例はモビリティです。ホストはネットワーク添付ファイルのポイントを変更し、新しいIPアドレスを受け取ります。別の例は、たとえば現在使用されているインターフェイスが何らかの理由で動作しなくなった場合、異なるインターフェイスに変更したいマルチホームホストです。
Although the problem can be solved by creating new IKE and IPsec SAs when the addresses need to be changed, this may not be optimal for several reasons. In some cases, creating a new IKE_SA may require user interaction for authentication, such as entering a code from a token card. Creating new SAs often involves expensive calculations and possibly a large number of round-trips. For these reasons, a mechanism for updating the IP addresses of existing IKE and IPsec SAs is needed. The MOBIKE protocol described in this document provides such a mechanism.
アドレスを変更する必要がある場合、新しいIKEとIPSEC SASを作成することで問題を解決できますが、これはいくつかの理由で最適ではない場合があります。場合によっては、新しいIKE_SAを作成すると、トークンカードからコードを入力するなど、認証のためにユーザーインタラクションが必要になる場合があります。多くの場合、新しいSASを作成するには、高価な計算と多数のラウンドトリップが含まれます。これらの理由から、既存のIKEおよびIPSEC SASのIPアドレスを更新するメカニズムが必要です。このドキュメントで説明されているMobikeプロトコルは、そのようなメカニズムを提供します。
The main scenario for MOBIKE is enabling a remote access VPN user to move from one address to another without re-establishing all security associations with the VPN gateway. For instance, a user could start from fixed Ethernet in the office and then disconnect the laptop and move to the office's wireless LAN. When the user leaves the office, the laptop could start using General Packet Radio Service (GPRS); when the user arrives home, the laptop could switch to the home wireless LAN. MOBIKE updates only the outer (tunnel header) addresses of IPsec SAs, and the addresses and other traffic selectors used inside the tunnel stay unchanged. Thus, mobility can be (mostly) invisible to applications and their connections using the VPN.
Mobikeの主なシナリオは、VPNゲートウェイとのすべてのセキュリティ関連を再確立することなく、リモートアクセスVPNユーザーがあるアドレスから別のアドレスに移動できるようにすることです。たとえば、ユーザーはオフィスの固定イーサネットから開始してから、ラップトップを切断してオフィスのワイヤレスLANに移動できます。ユーザーがオフィスを離れると、ラップトップは一般的なパケットラジオサービス（GPRS）の使用を開始できます。ユーザーが家に到着すると、ラップトップはホームワイヤレスLANに切り替えることができました。Mobikeは、IPSEC SASの外側（トンネルヘッダー）アドレスのみを更新し、トンネル内で使用されるアドレスやその他のトラフィックセレクターは変更されません。したがって、モビリティは、（ほとんど）アプリケーションとVPNを使用した接続には見えない場合があります。
MOBIKE also supports more complex scenarios where the VPN gateway also has several network interfaces: these interfaces could be connected to different networks or ISPs, they may be a mix of IPv4 and IPv6 addresses, and the addresses may change over time. Furthermore, both parties could be VPN gateways relaying traffic for other parties.
Mobikeは、VPNゲートウェイにいくつかのネットワークインターフェイスもあるより複雑なシナリオをサポートしています。これらのインターフェイスは、異なるネットワークまたはISPに接続でき、IPv4とIPv6アドレスの組み合わせであり、アドレスが時間とともに変化する場合があります。さらに、両当事者は、他の当事者のトラフィックを中継するVPNゲートウェイである可能性があります。
This document focuses on the main scenario outlined above and supports only tunnel mode IPsec SAs.
このドキュメントは、上記で概説したメインシナリオに焦点を当て、トンネルモードIPSEC SASのみをサポートしています。
The mobility support in MOBIKE allows both parties to move, but does not provide a "rendezvous" mechanism that would allow simultaneous movement of both parties or discovery of the addresses when the IKE_SA is first established. Therefore, MOBIKE is best suited for situations where the address of at least one endpoint is relatively stable and can be discovered using existing mechanisms such as DNS (see Section 3.1).
Mobikeのモビリティサポートにより、両当事者は移動できますが、IKE_SAが最初に確立されたときに、両方の当事者の同時移動または住所の発見を可能にする「ランデブー」メカニズムを提供しません。したがって、Mobikeは、少なくとも1つのエンドポイントのアドレスが比較的安定しており、DNSなどの既存のメカニズムを使用して発見できる状況に最適です（セクション3.1を参照）。
MOBIKE allows both parties to be multihomed; however, only one pair of addresses is used for an SA at a time. In particular, load balancing is beyond the scope of this specification.
Mobikeは、両当事者をマルチホームにすることを許可します。ただし、一度にSAに使用されるアドレスは1つのアドレスのみです。特に、負荷分散はこの仕様の範囲を超えています。
MOBIKE follows the IKEv2 practice where a response message is sent to the same address and port from which the request was received. This implies that MOBIKE does not work over address pairs that provide only unidirectional connectivity.
Mobikeは、リクエストが受信された同じアドレスとポートに応答メッセージが送信されるIKEV2プラクティスに続きます。これは、Mobikeが単方向接続のみを提供するアドレスペアで機能しないことを意味します。
Network Address Translators (NATs) introduce additional limitations beyond those listed above. For details, refer to Section 2.3.
ネットワークアドレス翻訳者（NAT）は、上記のものを超えて追加の制限を導入します。詳細については、セクション2.3を参照してください。
The base version of the MOBIKE protocol does not cover all potential future use scenarios, such as transport mode, application to securing SCTP, or optimizations desirable in specific circumstances. Future extensions may be defined later to support additional requirements. Please consult the MOBIKE design document [Design] for further information and rationale behind these limitations.
Mobikeプロトコルのベースバージョンは、輸送モード、SCTPのセキュリティへの適用、または特定の状況で望ましい最適化など、すべての潜在的な将来の使用シナリオをカバーするものではありません。将来の拡張は、追加の要件をサポートするために後で定義することができます。これらの制限の背後にある詳細情報と根拠については、Mobike Design Document [Design]を参照してください。
When messages containing IKEv2 payloads are described, optional payloads are shown in brackets (for instance, "[FOO]"), and a plus sign indicates that a payload can be repeated one or more times (for instance, "FOO+"). To provide context, some diagrams also show what existing IKEv2 payloads would typically be included in the exchanges. These payloads are shown for illustrative purposes only; see [IKEv2] for an authoritative description.
IKEV2ペイロードを含むメッセージが記載されている場合、オプションのペイロードがブラケットに表示されます（たとえば、「[Foo]」」）。プラス記号は、ペイロードを1回以上繰り返すことができることを示します（たとえば、「Foo」）。コンテキストを提供するために、一部の図は、通常、取引所に既存のIKEV2ペイロードが含まれるものも示しています。これらのペイロードは、説明のみを目的としています。権威ある説明については、[IKEV2]を参照してください。
When this document describes updating the source/destination addresses of an IPsec SA, it means updating IPsec-related state so that outgoing Encapsulating Security Payload (ESP)/Authentication Header (AH) packets use those addresses in the tunnel header. Depending on how the nominal divisions between Security Association Database (SAD), Security Policy Database (SPD), and Peer Authorization Database (PAD) described in [IPsecArch] are actually implemented, an implementation can have several different places that have to be updated.
このドキュメントがIPSEC SAのソース/宛先アドレスの更新を説明する場合、IPSEC関連状態を更新して、発信カプセンシングセキュリティペイロード（ESP）/認証ヘッダー（AH）パケットがトンネルヘッダーでそれらのアドレスを使用することを意味します。[IPSecarch]で説明されているセキュリティ協会データベース（SAD）、セキュリティポリシーデータベース（SPD）、およびピア認証データベース（PAD）間の名目区分が実際に実装される方法に応じて、実装には更新する必要があるいくつかの異なる場所を実装できます。
In this document, the term "initiator" means the party who originally initiated the first IKE_SA (in a series of possibly several rekeyed IKE_SAs); "responder" is the other peer. During the lifetime of the IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA exchanges; in this case, the terms "exchange initiator" and "exchange responder" are used. The term "original initiator" (which in [IKEv2] refers to the party who started the latest IKE_SA rekeying) is not used in this document.
このドキュメントでは、「イニシエーター」という用語は、最初に最初のIKE_SAを開始した当事者を意味します（おそらくいくつかの再キーイングIKE_SAS）。「レスポンダー」は他のピアです。IKE_SAの寿命の間、両当事者は情報またはcreate_child_sa取引所を開始する場合があります。この場合、「Exchange Initiator」と「Exchange Responder」という用語が使用されます。「Original Initiator」（[IKEV2]では、最新のIKE_SAの再キーイングを開始した当事者を指します）という用語は、このドキュメントでは使用されていません。
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 [KEYWORDS].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[キーワード]で説明されていると解釈されます。
MOBIKE allows both parties to have several addresses, and there are up to N*M pairs of IP addresses that could potentially be used. The decision of which of these pairs to use has to take into account several factors. First, the parties may have preferences about which interface should be used due to, for instance, performance and cost reasons. Second, the decision is constrained by the fact that some of the pairs may not work at all due to incompatible IP versions, outages in the network, problems at the local link at either end, and so on.
Mobikeは、両当事者がいくつかのアドレスを持つことを許可し、使用できる可能性のあるIPアドレスの最大ペアがあります。使用するこれらのペアのどれがいくつかの要因を考慮に入れる必要があります。第一に、当事者は、たとえばパフォーマンスやコストの理由により、どのインターフェイスを使用すべきかについての好みを持っている場合があります。第二に、決定は、互換性のないIPバージョン、ネットワークの停止、両端のローカルリンクの問題など、一部のペアがまったく機能しない可能性があるという事実によって制約されます。
MOBIKE solves this problem by taking a simple approach: the party that initiated the IKE_SA (the "client" in a remote access VPN scenario) is responsible for deciding which address pair is used for the IPsec SAs and for collecting the information it needs to make this decision (such as determining which address pairs work or do not work). The other party (the "gateway" in a remote access VPN scenario) simply tells the initiator what addresses it has, but does not update the IPsec SAs until it receives a message from the initiator to do so. This approach applies to the addresses in the IPsec SAs; in the IKE_SA case, the exchange initiator can decide which addresses are used.
Mobikeは、簡単なアプローチを取ることでこの問題を解決します。IKE_SA（リモートアクセスVPNシナリオで「クライアント」）を開始したパーティーは、IPSEC SASに使用されるアドレスペアを決定し、必要な情報を収集する責任があります。この決定（どのアドレスペアが機能するか、または機能しないかなど）。他のパーティ（リモートアクセスVPNシナリオの「ゲートウェイ」）は、イニシエーターにどのようなアドレスを与えるかを単純に伝えますが、IPSEC SASはイニシエーターからメッセージを受信するまで更新しません。このアプローチは、IPSEC SASのアドレスに適用されます。IKE_SAの場合、Exchangeイニシエーターはどのアドレスを使用するかを決定できます。
Making the decision at the initiator is consistent with how normal IKEv2 works: the initiator decides which addresses it uses when contacting the responder. It also makes sense, especially when the initiator is a mobile node: it is in a better position to decide which of its network interfaces should be used for both upstream and downstream traffic.
イニシエーターで決定を下すことは、通常のIKEV2の仕組みと一致しています。イニシエーターは、レスポンダーに連絡するときに使用する対処方法を決定します。また、特にイニシエーターがモバイルノードである場合、それは理にかなっています。上流トラフィックとダウンストリームトラフィックの両方にネットワークインターフェイスを使用すべきかを決定する方が良い位置にあります。
The details of exactly how the initiator makes the decision, what information is used in making it, how the information is collected, how preferences affect the decision, and when a decision needs to be changed are largely beyond the scope of MOBIKE. This does not mean that these details are unimportant: on the contrary, they are likely to be crucial in any real system. However, MOBIKE is concerned with these details only to the extent that they are visible in IKEv2/IPsec messages exchanged between the peers (and thus need to be standardized to ensure interoperability).
イニシエーターが決定をどのように行うか、それを作成する際にどの情報が使用されるか、情報の収集方法、設定が決定にどのように影響するか、および決定を変更する必要がある時期は、Mobikeの範囲を大きく超えています。これは、これらの詳細が重要ではないことを意味するものではありません。それどころか、実際のシステムでは重要である可能性があります。ただし、Mobikeは、ピア間で交換されるIKEV2/IPSECメッセージで表示される範囲でのみ、これらの詳細に関心があります（したがって、相互運用性を確保するために標準化する必要があります）。
Many of these issues are not specific to MOBIKE, but are common with the use of existing hosts in dynamic environments or with mobility protocols such as Mobile IP [MIP4] [MIP6]. A number of mechanisms already exist or are being developed to deal with these issues. For instance, link-layer and IP-layer mechanisms can be used to track the status of connectivity within the local link [RFC2461]; movement detection is being specified for both IPv4 and IPv6 in [DNA4], [DNA6], and so on.
これらの問題の多くは、Mobikeに固有のものではありませんが、動的環境での既存のホストの使用やモバイルIP [MIP4] [MIP6]などのモビリティプロトコルによく見られます。これらの問題に対処するために、多くのメカニズムがすでに存在するか、開発されています。たとえば、リンク層とIP層のメカニズムを使用して、ローカルリンク内の接続の状態を追跡できます[RFC2461]。[DNA4]、[DNA6]などのIPv4とIPv6の両方に移動検出が指定されています。
Naturally, updating the addresses of IPsec SAs has to take into account several security considerations. MOBIKE includes two features designed to address these considerations. First, a "return routability" check can be used to verify the addresses provided by the peer. This makes it more difficult to flood third parties with large amounts of traffic. Second, a "NAT prohibition" feature ensures that IP addresses have not been modified by NATs, IPv4/IPv6 translation agents, or other similar devices. This feature is enabled only when NAT Traversal is not used.
当然、IPSEC SASのアドレスを更新すると、いくつかのセキュリティに関する考慮事項を考慮する必要があります。Mobikeには、これらの考慮事項に対処するために設計された2つの機能が含まれています。まず、「返品ルーティング可能性」チェックを使用して、ピアが提供するアドレスを確認できます。これにより、サードパーティが大量のトラフィックであふれることがより困難になります。第二に、「NAT禁止」機能により、IPアドレスがNAT、IPv4/IPv6翻訳エージェント、または他の同様のデバイスによって変更されていないことが保証されます。この機能は、NATトラバーサルが使用されない場合にのみ有効になります。
A simple MOBIKE exchange in a mobile scenario is illustrated below. The notation is based on [IKEv2], Section 1.2. In addition, the source/destination IP addresses and ports are shown for each packet: here IP_I1, IP_I2, IP_R1, and IP_R2 represent IP addresses used by the initiator and the responder.
モバイルシナリオでのシンプルなMobike Exchangeを以下に示します。表記は[IKEV2]、セクション1.2に基づいています。さらに、各パケットのソース/宛先IPアドレスとポートが表示されます。ここでは、IP_I1、IP_I2、IP_R1、およびIP_R2は、イニシエーターとレスポンダーが使用するIPアドレスを表します。
Initiator Responder
----------- -----------
1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
<-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
2) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } -->
<-- (IP_R1:4500 -> IP_I1:4500)
HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY),
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED) }
(Initiator gets information from lower layers that its attachment point and address have changed.)
（イニシエーターは、付着ポイントとアドレスが変更された下層レイヤーから情報を取得します。）
3) (IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
<-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
(Responder verifies that the initiator has given it a correct IP address.)
（Responderは、イニシエーターが正しいIPアドレスを与えたことを確認します。）
4) <-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(COOKIE2) }
(IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(COOKIE2) } -->
Step 1 is the normal IKE_INIT exchange. In step 2, the peers inform each other that they support MOBIKE. In step 3, the initiator notices a change in its own address, and informs the responder about this by sending an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification. The request is sent using the new IP address. At this point, it also starts to use the new address as a source address in its own outgoing ESP traffic. Upon receiving the UPDATE_SA_ADDRESSES notification, the responder records the new address and, if it is required by policy, performs a return routability check of the address. When this check (step 4) completes, the responder starts to use the new address as the destination for its outgoing ESP traffic.
ステップ1は、通常のIKE_INIT Exchangeです。ステップ2では、ピアは彼らがMobikeをサポートしていることを互いに通知します。ステップ3では、イニシエーターは独自のアドレスの変更に気付き、update_sa_addresses通知を含む情報リクエストを送信することにより、これについて応答者に通知します。リクエストは、新しいIPアドレスを使用して送信されます。この時点で、新しいアドレスを独自の発信ESPトラフィックのソースアドレスとして使用し始めます。update_sa_addresses通知を受信すると、Responderは新しいアドレスを記録し、ポリシーで要求されている場合は、アドレスのReturbability Checkを実行します。このチェック（ステップ4）が完了すると、Responderは、発信ESPトラフィックの宛先として新しいアドレスを使用し始めます。
Another protocol run in a multihoming scenario is illustrated below. In this scenario, the initiator has one address but the responder has two.
マルチホームシナリオで実行される別のプロトコルを以下に示します。このシナリオでは、イニシエーターには1つのアドレスがありますが、レスポンダーには2つあります。
Initiator Responder
----------- -----------
1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
<-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
2) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } -->
<-- (IP_R1:4500 -> IP_I1:4500)
HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY),
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED),
N(ADDITIONAL_IP4_ADDRESS) }
(The initiator suspects a problem in the currently used address pair
and probes its liveness.)
3) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
(IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
...
...
(Eventually, the initiator gives up on the current address pair and tests the other available address pair.)
（最終的に、イニシエーターは現在のアドレスペアを放棄し、他の利用可能なアドレスペアをテストします。）
4) (IP_I1:4500 -> IP_R2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
<-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
(This worked, and the initiator requests the peer to switch to new addresses.)
（これは機能し、イニシエーターはピアに新しいアドレスに切り替えるように要求します。）
5) (IP_I1:4500 -> IP_R2:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) } -->
<-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) }
In some MOBIKE scenarios, the network may contain NATs or stateful packet filters (for brevity, the rest of this document simply describes NATs). The NAT Traversal feature specified in [IKEv2] allows IKEv2 to work through NATs in many cases, and MOBIKE can leverage this functionality: when the addresses used for IPsec SAs are changed, MOBIKE can enable or disable IKEv2 NAT Traversal, as needed.
一部のMobikeシナリオでは、ネットワークにはNATまたはStatefulパケットフィルターが含まれる場合があります（簡潔にするために、このドキュメントの残りの部分は単にNATを説明します）。[IKEV2]で指定されているNATトラバーサル機能により、IKEV2は多くの場合NATを使用でき、Mobikeはこの機能を活用できます。IPSECSASに使用されるアドレスが変更されると、Mobikeは必要に応じてIKEV2 NAT Traversalを有効または無効にできます。
Nevertheless, there are some limitations because NATs usually introduce an asymmetry into the network: only packets coming from the "inside" cause state to be created. This asymmetry leads to restrictions on what MOBIKE can do. To give a concrete example, consider a situation where both peers have only a single address, and the initiator is behind a NAT. If the responder's address now changes, it needs to send a packet to the initiator using its new address. However, if the NAT is, for instance, of the common "restricted cone" type (see [STUN] for one description of different NAT types), this is not possible. The NAT will drop packets sent from the new address (unless the initiator has previously sent a packet to that address -- which it cannot do until it knows the address).
それにもかかわらず、NATは通常、ネットワークに非対称性を導入するため、いくつかの制限があります。「内側」からのパケットのみが作成されます。この非対称性は、Mobikeができることの制限につながります。具体的な例を示すには、両方のピアが単一のアドレスしか持っておらず、イニシエーターがNATの背後にある状況を検討してください。Responderのアドレスが変更された場合、新しいアドレスを使用してイニシエーターにパケットを送信する必要があります。ただし、たとえば、NATが一般的な「制限付きコーン」タイプのものである場合（異なるNATタイプの1つの説明については[STUN]を参照）、これは不可能です。NATは、新しいアドレスから送信されたパケットをドロップします（イニシエーターが以前にそのアドレスにパケットを送信した場合を除きます。アドレスを知るまではできません）。
For simplicity, MOBIKE does not attempt to handle all possible NAT-related scenarios. Instead, MOBIKE assumes that if NATs are present, the initiator is the party "behind" the NAT, and the case where the responder's addresses change is not fully supported (meaning that no special effort is made to support this functionality). Responders may also be unaware of NATs or specific types of NATs they are behind. However, when a change has occurred that will cause a loss of connectivity, MOBIKE responders will still attempt to inform the initiator of the change. Depending on, for instance, the exact type of NAT, it may or may not succeed. However, analyzing the exact circumstances when this will or will not work is not done in this document.
簡単にするために、Mobikeはすべての可能なNAT関連のシナリオを処理しようとしません。代わりに、Mobikeは、NATが存在する場合、イニシエーターはNATの「後ろ」のパーティであり、Responderのアドレス変更が完全にサポートされていない場合（この機能をサポートするための特別な努力は行われないことを意味します）。また、レスポンダーは、NATや後ろにいる特定の種類のNATに気付いていない場合があります。ただし、接続性の喪失を引き起こす変更が発生した場合、Mobike Responserはまだ変更を開始者に通知しようとします。たとえば、NATの正確なタイプに応じて、成功する場合と成功しない場合があります。ただし、これが機能する、または機能しない場合の正確な状況を分析することは、このドキュメントでは行われません。
The initiator is responsible for finding a working pair of addresses so that the initial IKE exchange can be carried out. Any information from MOBIKE extensions will only be available later, when the exchange has progressed far enough. Exactly how the addresses used for the initial exchange are discovered is beyond the scope of this specification; typical sources of information include local configuration and DNS.
イニシエーターは、最初のIKE交換を実行できるように、作業中のアドレスを見つける責任があります。Mobike Extensionsからの情報は、交換が十分に進歩した場合にのみ利用可能になります。最初の交換に使用されるアドレスが発見される方法は、この仕様の範囲を超えています。典型的な情報源には、ローカル構成とDNSが含まれます。
If either or both of the peers have multiple addresses, some combinations may not work. Thus, the initiator SHOULD try various source and destination address combinations when retransmitting the IKE_SA_INIT request.
どちらかまたは両方のピアに複数のアドレスがある場合、いくつかの組み合わせが機能しない場合があります。したがって、IKE_SA_INITリクエストを再送信するときに、イニシエーターはさまざまなソースと宛先アドレスの組み合わせを試す必要があります。
Implementations that wish to use MOBIKE for a particular IKE_SA MUST include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the message containing the SA payload).
特定のIKE_SAにMobikeを使用したい実装には、IKE_AUTH ExchangeにMobike_Supported通知を含める必要があります（SAペイロードを含むメッセージに複数のIKE_AUTH取引所の場合）。
The format of the MOBIKE_SUPPORTED notification is described in Section 4.
mobike_supported通知の形式については、セクション4で説明します。
When an IPsec SA is created, the tunnel header IP addresses (and port, if doing UDP encapsulation) are taken from the IKE_SA, not the IP header of the IKEv2 message requesting the IPsec SA. The addresses in the IKE_SA are initialized from the IP header of the first IKE_AUTH request.
IPSEC SAが作成されると、IPSEC SAを要求するIKEV2メッセージのIPヘッダーではなく、IKE_SAからトンネルヘッダーIPアドレス（およびポート）がIKE_SAから取得されます。IKE_SAのアドレスは、最初のIKE_AUTH要求のIPヘッダーから初期化されます。
The addresses are taken from the IKE_AUTH request because IKEv2 requires changing from port 500 to 4500 if a NAT is discovered. To simplify things, implementations that support both this specification and NAT Traversal MUST change to port 4500 if the correspondent also supports both, even if no NAT was detected between them (this way, there is no need to change the ports later if a NAT is detected on some other path).
IKEV2には、NATが発見された場合、IKEV2はポート500から4500に変更する必要があるため、アドレスはIKE_AUTHリクエストから取得されます。物事を簡素化するために、この仕様とNATトラバーサルの両方をサポートする実装は、特派員も両方をサポートしている場合、ポート4500に変更する必要があります。他のパスで検出されます）。
Both the initiator and responder MAY include one or more ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the message containing the SA payload). Here "ADDITIONAL_*_ADDRESS" means either an ADDITIONAL_IP4_ADDRESS or an ADDITIONAL_IP6_ADDRESS notification.
イニシエーターとレスポンダーの両方に、IKE_AUTH Exchangeの1つまたは複数の追加_IP4_ADDRESSおよび/またはADDATION_IP6_ADDRESS通知を含めることができます（SAペイロードを含むメッセージに複数のIKE_AUTH交換の場合）。ここでは、「追加_*_アドレス」とは、追加の_IP4_Addressまたは追加の_IP6_Address通知のいずれかを意味します。
Initiator Responder
----------- -----------
HDR, SK { IDi, [CERT], [IDr], AUTH,
[CP(CFG_REQUEST)]
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_*_ADDRESS)+] } -->
<-- HDR, SK { IDr, [CERT], AUTH,
[CP(CFG_REPLY)],
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED)
[N(ADDITIONAL_*_ADDRESS)+] }
The recipient stores this information, but no other action is taken at this time.
受信者はこの情報を保存しますが、現時点では他のアクションは取られていません。
Although both the initiator and responder maintain a set of peer addresses (logically associated with the IKE_SA), it is important to note that they use this information for slightly different purposes.
イニシエーターとレスポンダーの両方が一連のピアアドレスを維持していますが（論理的にIKE_SAに関連付けられています）、この情報をわずかに異なる目的で使用することに注意することが重要です。
The initiator uses the set of responder addresses as an input to its address selection policy; it may, at some later point, decide to move the IPsec traffic to one of these addresses using the procedure described in Section 3.5. The responder normally does not use the set of initiator addresses for anything: the addresses are used only when the responder's own addresses change (see Section 3.6).
イニシエーターは、アドレス選択ポリシーへの入力として、レスポンダーアドレスのセットを使用します。後の時点で、セクション3.5で説明した手順を使用して、IPSECトラフィックをこれらのアドレスのいずれかに移動することを決定する場合があります。レスポンダーは通常、イニシエーターアドレスのセットを何でも使用しません。アドレスは、レスポンダー自身のアドレスが変更された場合にのみ使用されます（セクション3.6を参照）。
The set of addresses available to the peers can change during the lifetime of the IKE_SA. The procedure for updating this information is described in Section 3.6.
ピアが利用できるアドレスのセットは、IKE_SAの寿命の間に変化する可能性があります。この情報を更新する手順は、セクション3.6で説明されています。
Note that if some of the initiator's interfaces are behind a NAT (from the responder's point of view), the addresses received by the responder will be incorrect. This means the procedure for changing responder addresses described in Section 3.6 does not fully work when the initiator is behind a NAT. For the same reason, the peers also SHOULD NOT use this information for any other purpose than what is explicitly described either in this document or a future specification updating it.
イニシエーターのインターフェイスの一部がNATの背後にある場合（レスポンダーの観点から）、レスポンダーが受け取ったアドレスが正しくないことに注意してください。これは、セクション3.6で説明されているレスポンダーアドレスを変更する手順が、イニシエーターがNATの背後にある場合、完全には機能しないことを意味します。同じ理由で、ピアは、このドキュメントまたは将来の仕様の更新で明示的に説明されていること以外の目的でこの情報を使用してはなりません。
In MOBIKE, the initiator decides what addresses are used in the IPsec SAs. That is, the responder does not normally update any IPsec SAs without receiving an explicit UPDATE_SA_ADDRESSES request from the initiator. (As described below, the responder can, however, update the IKE_SA in some circumstances.)
Mobikeでは、イニシエーターは、IPSEC SASで使用されるアドレスを決定します。つまり、レスポンダーは通常、イニシエーターから明示的なupdate_sa_addressesリクエストを受信せずにIPSEC SASを更新しません。（以下に説明するように、レスポンダーは状況によってIKE_SAを更新できます。）
The reasons why the initiator wishes to change the addresses are largely beyond the scope of MOBIKE. Typically, triggers include information received from lower layers, such as changes in IP addresses or link-down indications. Some of this information can be unreliable: for instance, ICMP messages could be spoofed by an attacker. Unreliable information SHOULD be treated only as a hint that there might be a problem, and the initiator SHOULD trigger Dead Peer Detection (that is, send an INFORMATIONAL request) to determine if the current path is still usable.
イニシエーターがアドレスを変更したい理由は、Mobikeの範囲を大きく超えています。通常、トリガーには、IPアドレスの変更やリンクダウン表示など、下層から受け取った情報が含まれます。この情報の一部は信頼できない場合があります。たとえば、ICMPメッセージは攻撃者によってスプーフィングされる可能性があります。信頼できない情報は、問題があるかもしれないというヒントとしてのみ扱われるべきであり、イニシエーターは、現在のパスがまだ使用可能かどうかを判断するために、死んだピア検出（つまり、情報リクエストを送信する）をトリガーする必要があります。
Changing addresses can also be triggered by events within IKEv2. At least the following events can cause the initiator to re-evaluate its local address selection policy, possibly leading to changing the addresses.
アドレスの変更は、IKEV2内のイベントによってトリガーされることもあります。少なくとも次のイベントにより、イニシエーターはローカルアドレス選択ポリシーを再評価し、住所の変更につながる可能性があります。
o An IKEv2 request has been re-transmitted several times, but no valid reply has been received. This suggests the current path is no longer working.
o IKEV2リクエストは数回再送信されましたが、有効な返信は受信されていません。これは、現在のパスが機能していないことを示唆しています。
o An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is received. This means the peer's addresses may have changed. This is particularly important if the announced set of addresses no longer contains the currently used address.
o 追加の_IP4_ADDRESS、追加_IP6_ADDRESS、またはNO_ADDITIONAL_ADDRESSの通知を含む情報リクエストが受信されます。これは、ピアのアドレスが変更された可能性があることを意味します。これは、発表されたアドレスのセットに現在使用されているアドレスが含まれていない場合に特に重要です。
o An UNACCEPTABLE_ADDRESSES notification is received as a response to address update request (described below).
o 容認できない_Addresses通知は、アドレス更新リクエストへの応答として受信されます（以下で説明）。
o The initiator receives a NAT_DETECTION_DESTINATION_IP notification that does not match the previous UPDATE_SA_ADDRESSES response (see Section 3.8 for a more detailed description).
o イニシエーターは、以前のupdate_sa_addresses応答と一致しないnat_detection_destination_ip通知を受信します（詳細な説明については、セクション3.8を参照）。
The description in the rest of this section assumes that the initiator has already decided what the new addresses should be. When this decision has been made, the initiator:
このセクションの残りの説明は、イニシエーターが新しいアドレスがどうあるべきかをすでに決定していると仮定しています。この決定が下されたとき、イニシエーター：
o Updates the IKE_SA with the new addresses, and sets the "pending_update" flag in the IKE_SA.
o IKE_SAを新しいアドレスで更新し、IKE_SAに「pending_update」フラグを設定します。
o Updates the IPsec SAs associated with this IKE_SA with the new addresses (unless the initiator's policy requires a return routability check before updating the IPsec SAs, and the check has not been done for this responder address yet).
o このIKE_SAに関連付けられたIPSEC SASを新しいアドレスで更新します（IPSEC SASを更新する前に、イニシエーターのポリシーが返品ルー上のチェックを必要とする場合を除き、このResponderアドレスのチェックはまだ行われていません）。
o If the IPsec SAs were updated in the previous step: If NAT Traversal is not enabled, and the responder supports NAT Traversal (as indicated by NAT detection payloads in the IKE_SA_INIT exchange), and the initiator either suspects or knows that a NAT is likely to be present, enables NAT Traversal (that is, enables UDP encapsulation of outgoing ESP packets and sending of NAT-Keepalive packets).
o IPSEC SASが前のステップで更新された場合：NATトラバーサルが有効になっていない場合、ResponderがNATトラバーサルをサポートしている場合（IKE_SA_INIT ExchangeのNAT検出ペイロードで示されているように）、イニシエーターはNATが疑わしいか知っていることを知っています。存在し、NATトラバーサルを有効にします（つまり、発信ESPパケットのUDPカプセル化とNAT-Keepaliveパケットの送信を可能にします）。
o If there are outstanding IKEv2 requests (requests for which the initiator has not yet received a reply), continues retransmitting them using the addresses in the IKE_SA (the new addresses).
o 未解決のIKEV2要求がある場合（イニシエーターがまだ返信を受け取っていないリクエスト）、IKE_SA（新しいアドレス）のアドレスを使用してそれらを再送信し続けます。
o When the window size allows, sends an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification (which does not contain any data), and clears the "pending_update" flag. The request will be as follows: Initiator Responder ----------- ----------- HDR, SK { N(UPDATE_SA_ADDRESSES), [N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP)], [N(NO_NATS_ALLOWED)], [N(COOKIE2)] } -->
o ウィンドウサイズが許可されている場合、update_sa_addresses通知（データには含まれていない）を含む情報リクエストを送信し、「pending_update」フラグをクリアします。リクエストは次のとおりです。イニシエーターレスポンダー------------------- hdr、sk {n update_sa_addresses）、[n（nat_detection_source_ip）、n（nat_detection_destination_ip）]、[n（no_nats_allowed）]、[n（cookie2）]} - >
o If a new address change occurs while waiting for the response, starts again from the first step (and ignores responses to this UPDATE_SA_ADDRESSES request).
o 応答を待っている間に新しいアドレスの変更が発生した場合、最初のステップから再び開始します（このupdate_sa_addressesリクエストに対する応答は無視します）。
When processing an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification, the responder:
update_sa_addresses通知を含む情報リクエストを処理する場合、応答者：
o Determines whether it has already received a newer UPDATE_SA_ADDRESSES request than this one (if the responder uses a window size greater than one, it is possible that requests are received out of order). If it has, a normal response message (described below) is sent, but no other action is taken.
o これよりも新しいupdate_sa_addressesリクエストを既に受信しているかどうかを判断します（レスポンダーがウィンドウサイズを1より大きい場合は、リクエストが順調に受け取られている可能性があります）。ある場合、通常の応答メッセージ（以下で説明）が送信されますが、他のアクションは実行されません。
o If the NO_NATS_ALLOWED notification is present, processes it as described in Section 3.9.
o NO_NATS_ALLOWED通知が存在する場合、セクション3.9で説明されているように処理します。
o Checks that the (source IP address, destination IP address) pair in the IP header is acceptable according to local policy. If it is not, replies with a message containing the UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2).
o IPヘッダーの（ソースIPアドレス、宛先IPアドレス）ペアがローカルポリシーに従って許容できることを確認します。そうでない場合は、容認できない_Addresses通知（および場合によってはCookie2）を含むメッセージで返信します。
o Updates the IP addresses in the IKE_SA with the values from the IP header. (Using the address from the IP header is consistent with normal IKEv2, and allows IKEv2 to work with NATs without needing unilateral self-address fixing [UNSAF].)
o IKE_SAのIPアドレスをIPヘッダーの値で更新します。（IPヘッダーのアドレスを使用すると、通常のIKEV2と一致し、IKEV2が一方的な自己アドレス固定を必要とせずにNATと動作させることができます[UNSAF]。）
o Replies with an INFORMATIONAL response:
o 情報応答での返信：
Initiator Responder
----------- -----------
<-- HDR, SK { [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[N(COOKIE2)] }
o If necessary, initiates a return routability check for the new initiator address (see Section 3.7) and waits until the check is completed.
o 必要に応じて、新しいイニシエーターアドレスの返品ルー上のチェックを開始し（セクション3.7を参照）、チェックが完了するまで待ちます。
o Updates the IPsec SAs associated with this IKE_SA with the new addresses.
o このIKE_SAに関連付けられたIPSEC SASを新しいアドレスで更新します。
o If NAT Traversal is supported and NAT detection payloads were included, enables or disables NAT Traversal.
o NATトラバーサルがサポートされ、NAT検出ペイロードが含まれている場合、NATトラバーサルを有効または無効にします。
When the initiator receives the reply:
イニシエーターが返信を受け取ったとき：
o If an address change has occurred after the request was first sent, no MOBIKE processing is done for the reply message because a new UPDATE_SA_ADDRESSES is going to be sent (or has already been sent, if window size greater than one is in use).
o リクエストが最初に送信された後にアドレスの変更が発生した場合、新しいupdate_sa_addressesが送信されるため、返信メッセージに対してmobike処理は行われません（または、1つ以上のウィンドウサイズが使用されている場合は既に送信されています）。
o If the response contains the UNEXPECTED_NAT_DETECTED notification, the initiator processes the response as described in Section 3.9.
o 応答にredixed_nat_detected通知が含まれている場合、イニシエーターはセクション3.9で説明されているように応答を処理します。
o If the response contains an UNACCEPTABLE_ADDRESSES notification, the initiator MAY select another addresses and retry the exchange, keep on using the previously used addresses, or disconnect.
o 応答に容認できない_Addresses通知が含まれている場合、イニシエーターは別のアドレスを選択して交換を再試行するか、以前に使用したアドレスを使用し続けるか、切断することができます。
o It updates the IPsec SAs associated with this IKE_SA with the new addresses (unless this was already done earlier before sending the request; this is the case when no return routability check was required).
o このIKE_SAに関連付けられたIPSEC SASを新しいアドレスに更新します（リクエストを送信する前に、これが既に以前に行われていない限り、これは返品ルー上のチェックが不要な場合です）。
o If NAT Traversal is supported and NAT detection payloads were included, the initiator enables or disables NAT Traversal.
o NATトラバーサルがサポートされ、NAT検出ペイロードが含まれている場合、イニシエーターはNATトラバーサルを有効または無効にします。
There is one exception to the rule that the responder never updates any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If the source address that the responder is currently using becomes unavailable (i.e., sending packets using that source address is no longer possible), the responder is allowed to update the IPsec SAs to use some other address (in addition to initiating the procedure described in the next section).
Responderがupdate_sa_addressesリクエストを受信せずにIPSEC SASを更新しないというルールには1つの例外があります。Responderが現在使用しているソースアドレスが利用できなくなった場合（つまり、そのソースアドレスを使用してパケットを送信することは不可能です）、ResponderはIPSEC SASを更新して他のアドレスを使用することができます（で説明されている手順を開始することに加えて次のセクション）。
As described in Section 3.4, both the initiator and responder can send a list of additional addresses in the IKE_AUTH exchange. This information can be updated by sending an INFORMATIONAL exchange request message that contains either one or more ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification.
セクション3.4で説明されているように、イニシエーターとレスポンダーの両方は、IKE_AUTH Exchangeで追加のアドレスのリストを送信できます。この情報は、1つまたは複数の追加_IP4_ADDRESS/ADDATION_IP6_ADDRESS通知またはNO_ADDITIONAL_ADDRESSES通知を含む情報交換要求メッセージを送信することで更新できます。
If the exchange initiator has only a single IP address, it is placed in the IP header, and the message contains the NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has several addresses, one of them is placed in the IP header, and the rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications.
Exchangeイニシエーターに単一のIPアドレスしかない場合、IPヘッダーに配置され、メッセージにはNO_ADDITIONAL_ADDRESSES通知が含まれています。Exchange Initiatorにいくつかのアドレスがある場合、そのうちの1つがIPヘッダーに、残りは追加の_IP4_ADDRESS/ADDATION_IP6_ADDRESS通知に配置されます。
The new list of addresses replaces the old information (in other words, there are no separate add/delete operations; instead, the complete list is sent every time these notifications are used).
アドレスの新しいリストは古い情報に置き換えられます（つまり、個別の追加/削除操作はありません。代わりに、これらの通知が使用されるたびに完全なリストが送信されます）。
The message exchange will look as follows:
メッセージ交換は次のように見えます。
Initiator Responder
----------- -----------
HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
[N(NO_ADDITIONAL_ADDRESSES)],
[N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->
<-- HDR, SK { [N(COOKIE2)] }
When a request containing an ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is received, the exchange responder:
追加の_IP4_ADDRESS、追加の_IP6_ADDRESS、またはNO_ADDITIONAL_ADDRESSの通知を含むリクエストが受信された場合、Exchange Responder：
o Determines whether it has already received a newer request to update the addresses (if a window size greater than one is used, it is possible that the requests are received out of order). If it has, a response message is sent, but the address set is not updated.
o アドレスを更新するための新しいリクエストを既に受け取っているかどうかを判断します（1つ以上のウィンドウサイズが使用されている場合、リクエストが故障しない可能性があります）。ある場合、応答メッセージが送信されますが、アドレスセットは更新されません。
o If the NO_NATS_ALLOWED notification is present, processes it as described in Section 3.9.
o NO_NATS_ALLOWED通知が存在する場合、セクション3.9で説明されているように処理します。
o Updates the set of peer addresses based on the IP header and the ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, and NO_ADDITIONAL_ADDRESSES notifications.
o IPヘッダーと追加の_IP4_ADDRESS、追加_IP6_ADDRESS、およびNO_ADDITIONAL_ADDRESSES通知に基づいて、ピアアドレスのセットを更新します。
o Sends a response.
o 応答を送信します。
The initiator MAY include these notifications in the same request as UPDATE_SA_ADDRESSES.
イニシエーターには、update_sa_addressesと同じ要求にこれらの通知を含めることができます。
If the request to update the addresses is retransmitted using several different source addresses, a new INFORMATIONAL request MUST be sent.
アドレスを更新するリクエストがいくつかの異なるソースアドレスを使用して再送信される場合、新しい情報リクエストを送信する必要があります。
There is one additional complication: when the responder wants to update the address set, the currently used addresses may no longer work. In this case, the responder uses the additional address list received from the initiator, and the list of its own addresses, to determine which addresses to use for sending the INFORMATIONAL request. This is the only time the responder uses the additional address list received from the initiator.
追加の複雑さが1つあります。応答者がアドレスセットを更新したい場合、現在使用されているアドレスが機能しなくなる可能性があります。この場合、レスポンダーは、イニシエーターから受信した追加のアドレスリストと独自のアドレスのリストを使用して、情報リクエストの送信に使用するアドレスを決定します。これは、レスポンダーがイニシエーターから受信した追加のアドレスリストを使用する唯一の時間です。
Note that both peers can have their own policies about what addresses are acceptable to use, and certain types of policies may simplify implementation. For instance, if the responder has a single fixed address, it does not need to process the ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications it receives (beyond ignoring unrecognized status notifications, as already required in [IKEv2]). Furthermore, if the initiator has a policy saying that only the responder address specified in local configuration is acceptable, it does not have to send its own additional addresses to the responder (since the responder does not need them except when changing its own address).
どちらのピアも、どのアドレスが使用できるかについて独自のポリシーを持つことができ、特定の種類のポリシーが実装を簡素化する可能性があることに注意してください。たとえば、Responderに単一の固定アドレスがある場合、受信する追加の_IP4_Addressと追加の_IP6_ADDRESS通知を処理する必要はありません（[IKEV2]ですでに必要とされるように、認識されていないステータス通知を無視することを超えて）。さらに、イニシエーターに、ローカル構成で指定されたレスポンダーアドレスのみが許容できるというポリシーがある場合、独自のアドレスをレスポンダーに送信する必要はありません（レスポンダーは独自のアドレスを変更する場合を除いてそれらを必要としないため）。
Both parties can optionally verify that the other party can actually receive packets at the claimed address. By default, this "return routability check" SHOULD be performed. In environments where the peer is expected to be well-behaved (many corporate VPNs, for instance), or the address can be verified by some other means (e.g., a certificate issued by an authority trusted for this purpose), the return routability check MAY be omitted.
両当事者は、オプションで、相手が請求された住所で実際にパケットを受け取ることができることをオプションで確認できます。デフォルトでは、この「Returnability Check」を実行する必要があります。ピアが行方不明になると予想される環境（たとえば、多くの企業VPN）、またはアドレスを他の手段（例えば、この目的で信頼できる当局によって発行された証明書など）で検証することができます。省略される場合があります。
The check can be done before updating the IPsec SAs, immediately after updating them, or continuously during the connection. By default, the return routability check SHOULD be done before updating the IPsec SAs, but in some environments it MAY be postponed until after the IPsec SAs have been updated.
チェックは、IPSEC SASを更新する前、それらを更新した直後、または接続中に継続的に行うことができます。デフォルトでは、IPSEC SASを更新する前に返品ルーティング可能性チェックを実行する必要がありますが、一部の環境では、IPSEC SASが更新されるまで延期される場合があります。
Any INFORMATIONAL exchange can be used for return routability purposes, with one exception (described later in this section): when a valid response is received, we know the other party can receive packets at the claimed address.
情報交換は、1つの例外を除き（このセクションで後述）、有効な応答を受信した場合、他の当事者がクレームアドレスでパケットを受信できることを知っています。
To ensure that the peer cannot generate the correct INFORMATIONAL response without seeing the request, a new payload is added to INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY include a COOKIE2 notification, and if included, the recipient of an INFORMATIONAL request MUST copy the notification as-is to the response. When processing the response, the original sender MUST verify that the value is the same one as sent. If the values do not match, the IKE_SA MUST be closed. (See also Section 4.2.5 for the format of the COOKIE2 notification.) The exception mentioned earlier is as follows: If the same INFORMATIONAL request has been sent to several different addresses (i.e., the destination address in the IKE_SA has been updated after the request was first sent), receiving the INFORMATIONAL response does not tell which address is the working one. In this case, a new INFORMATIONAL request needs to be sent to check return routability.
リクエストを表示せずにピアが正しい情報応答を生成できないことを確認するために、情報メッセージに新しいペイロードが追加されます。情報リクエストの送信者にはCookie2通知が含まれる場合があり、含まれている場合、情報リクエストの受信者は通知を応答にコピーする必要があります。応答を処理する場合、元の送信者は、値が送信と同じであることを確認する必要があります。値が一致しない場合、IKE_SAは閉じる必要があります。（Cookie2通知の形式については、セクション4.2.5も参照してください。）前述の例外は次のとおりです。同じ情報リクエストがいくつかの異なるアドレスに送信された場合（つまり、IKE_SAの宛先アドレスが更新された後に更新されました。リクエストが最初に送信されました）、情報応答を受信しても、どのアドレスが機能するかはわかりません。この場合、返品のルーティング可能性を確認するには、新しい情報リクエストを送信する必要があります。
IKEv2 performs Dead Peer Detection (DPD) if there has recently been only outgoing traffic on all of the SAs associated with the IKE_SA.
IKEV2は、IKE_SAに関連付けられているすべてのSAで最近発信トラフィックのみがある場合、デッドピア検出（DPD）を実行します。
In MOBIKE, these messages can also be used to detect if NAT mappings have changed (for example, if the keepalive interval is too long, or the NAT box is rebooted). More specifically, if both peers support both this specification and NAT Traversal, the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notifications MAY be included in any INFORMATIONAL request; if the request includes them, the responder MUST also include them in the response (but no other action is taken, unless otherwise specified).
Mobikeでは、これらのメッセージを使用して、NATマッピングが変更されたかどうかを検出することもできます（たとえば、Keepalive間隔が長すぎる場合、またはNATボックスが再起動されている場合）。より具体的には、両方のピアがこの仕様とNATトラバーサルの両方をサポートする場合、NAT_DETECTION_SOURCE_IPおよびNAT_DETECTION_DESTINATION_IP通知が情報リクエストに含まれる場合があります。リクエストにそれらが含まれている場合、応答者もそれらを応答に含める必要があります（ただし、特に指定されていない限り、他のアクションは実行されません）。
When the initiator is behind a NAT (as detected earlier using the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notifications), it SHOULD include these notifications in DPD messages and compare the received NAT_DETECTION_DESTINATION_IP notifications with the value from the previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT response). If the values do not match, the IP address and/or port seen by the responder has changed, and the initiator SHOULD send UPDATE_SA_ADDRESSES as described in Section 3.5. If the initiator suspects that the NAT mapping has changed, it MAY also skip the detection step and send UPDATE_SA_ADDRESSES immediately. This saves one roundtrip if the NAT mapping has indeed changed.
イニシエーターがNATの背後にある場合（NAT_DETECTION_SOURCE_IPおよびNAT_DETECTION_DESTINATION_IPIFICATIONSを使用して以前に検出されたように）、これらの通知をDPDメッセージに含め、受信したNAT_DETECTION_DESTINATION_IPの通知を以前のupdate_Sa_addresses応答（またはIKE_SA_INIT対応からの値と比較する必要があります。値が一致しない場合、レスポンダーが見たIPアドレスおよび/またはポートが変更され、イニシエーターはセクション3.5で説明されているようにupdate_sa_addressesを送信する必要があります。イニシエーターがNATマッピングが変更されたと疑っている場合、検出ステップをスキップして更新_SA_ADDRESSESをすぐに送信することもあります。これにより、NATマッピングが実際に変更された場合、1つの往復が節約されます。
Note that this approach to detecting NAT mapping changes may cause an extra address update when the IKE_SA is rekeyed. This is because the NAT_DETECTION_DESTINATION_IP hash also includes the IKE Security Parameter Indexes (SPIs), which change when performing rekeying. This unnecessary update is harmless, however.
NATマッピングの変更を検出するためのこのアプローチは、IKE_SAが再キーになったときに追加のアドレス更新を引き起こす可能性があることに注意してください。これは、NAT_DETECTION_DESTINATION_IPハッシュには、再キーイングの実行時に変更されるIKEセキュリティパラメーターインデックス（SPI）も含まれているためです。ただし、この不要な更新は無害です。
When MOBIKE is in use, the dynamic updates (specified in [IKEv2], Section 2.23), where the peer address and port are updated from the last valid authenticated packet, work in a slightly different fashion. The host not behind a NAT MUST NOT use these dynamic updates for IKEv2 packets, but MAY use them for ESP packets. This ensures that an INFORMATIONAL exchange that does not contain UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be used for, e.g., testing whether a particular path works.
Mobikeが使用されている場合、ダイナミックアップデート（[IKEV2]、セクション2.23で指定）。ここで、ピアアドレスとポートが最後に有効な認証されたパケットから更新され、わずかに異なる方法で動作します。NATの後ろにないホストは、IKEV2パケットにこれらの動的更新を使用してはなりませんが、ESPパケットにそれらを使用する場合があります。これにより、update_sa_addressesを含まない情報交換が変更を引き起こさないことが保証され、特定のパスが機能するかどうかをテストするために使用できるようになります。
Basic IKEv2/IPsec without NAT Traversal support may work across some types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in tunnel mode. This is because the IKEv2 integrity checksum does not cover the addresses in the IP header. This may be considered a problem in some circumstances, because in some sense any modification of the IP addresses can be considered an attack.
NATトラバーサルサポートのない基本的なIKEV2/IPSECは、トンネルモードでのあるタイプの1対1の「基本的な」NATおよびIPv4/IPv6翻訳エージェントで機能する場合があります。これは、IKEV2 Integrity ChecksumがIPヘッダーのアドレスをカバーしていないためです。ある意味では、IPアドレスの変更は攻撃と見なされる可能性があるため、状況によっては問題と見なされる場合があります。
This specification addresses the issue by protecting the IP addresses when NAT Traversal has not been explicitly enabled. This means that MOBIKE without NAT Traversal support will not work if the paths contain NATs, IPv4/IPv6 translation agents, or other nodes that modify the addresses in the IP header. This feature is mainly intended for IPv6 and site-to-site VPN cases, where the administrators may know beforehand that NATs are not present, and thus any modification to the packet can be considered an attack.
この仕様は、NATトラバーサルが明示的に有効になっていない場合にIPアドレスを保護することにより、問題に対処します。これは、パスにNAT、IPv4/IPv6翻訳エージェント、またはIPヘッダーのアドレスを変更する他のノードが含まれている場合、NATトラバーサルサポートのないMobikeが機能しないことを意味します。この機能は、主にIPv6およびサイト間VPNケースを対象としています。これは、管理者がNATが存在しないことを事前に知っている可能性があるため、パケットの変更は攻撃と見なすことができます。
More specifically, when NAT Traversal is not enabled, all messages that can update the addresses associated with the IKE_SA and/or IPsec SAs (the first IKE_AUTH request and all INFORMATIONAL requests that contain any of the following notifications: UPDATE_SA_ADDRESSES, ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED notification. The exchange responder MUST verify that the contents of the NO_NATS_ALLOWED notification match the addresses in the IP header. If they do not match, a response containing an UNEXPECTED_NAT_DETECTED notification is sent. The response message is sent to the address and port that the corresponding request came from, not to the address contained in the NO_NATS_ALLOWED notification.
より具体的には、NATトラバーサルが有効になっていない場合、IKE_SAおよび/またはIPSEC SASに関連付けられたアドレスを更新できるすべてのメッセージ（最初のIKE_AUTH要求と次の通知のいずれかを含むすべての情報リクエスト：update_SA_ADDRESSES、Addational_IP4_Address、追加）NO_NATS_ALLOWED通知も含める必要があります。Exchange Responderは、NO_NATS_ALLOWED通知の内容がIPヘッダーのアドレスと一致することを確認する必要があります。それらが一致しない場合、redixed_nat_detected通知を含む応答が送信されます。応答メッセージは、対応するリクエストが由来するアドレスとポートに送信されますが、NO_NATS_ALLOWED通知に含まれるアドレスにはありません。
If the exchange initiator receives an UNEXPECTED_NAT_DETECTED notification in response to its INFORMATIONAL request, it SHOULD retry the operation several times using new INFORMATIONAL requests. Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several times, starting from a new IKE_SA_INIT request. This ensures that an attacker who is able to modify only a single packet does not unnecessarily cause a path to remain unused. The exact number of retries is not specified in this document because it does not affect interoperability. However, because the IKE message will also be rejected if the attacker modifies the integrity checksum field, a reasonable number here would be the number of retries that is being used for normal retransmissions.
Exchangeイニシエーターが情報リクエストに応じてregiond_nat_detected通知を受け取った場合、新しい情報リクエストを使用して操作を何度か再試行する必要があります。同様に、IKE_AUTH Exchangeでイニシエーターが予期しない_NAT_DETECTEDを受信した場合、新しいIKE_SA_INITリクエストからIKE_SAの確立を数回再試行する必要があります。これにより、単一のパケットのみを変更できる攻撃者が不必要にパスを使用しないようにしないようにします。このドキュメントでは、相互運用性に影響しないため、このドキュメントでは正確な数は指定されていません。ただし、攻撃者が整合性チェックサムフィールドを変更した場合、IKEメッセージも拒否されるため、ここでの合理的な数は、通常の再送信に使用されているレトリの数です。
If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange responder MUST NOT use the contents of the NO_NATS_ALLOWED notification for any other purpose than possibly logging the information for troubleshooting purposes.
予期しない_NAT_DETECTED通知が送信された場合、Exchange Responderは、トラブルシューティングの目的で情報を記録する可能性がある以外の目的で、NO_NATS_ALLOWED通知のコンテンツを使用してはなりません。
IKEv2 Dead Peer Detection allows the peers to detect if the currently used path has stopped working. However, if either of the peers has several addresses, Dead Peer Detection alone does not tell which of the other paths might work.
IKEV2デッドピア検出により、ピアは現在使用されているパスが機能しなくなったかどうかを検出できます。ただし、いずれかのピアにいくつかのアドレスがある場合、死んだピア検出だけでは、他のパスのどれが機能するかはわかりません。
If required by its address selection policy, the initiator can use normal IKEv2 INFORMATIONAL request/response messages to test whether a certain path works. Implementations MAY do path testing even if the path currently being used is working to, for example, detect when a better (but previously unavailable) path becomes available.
アドレス選択ポリシーで要求された場合、イニシエーターは通常のIKEV2情報リクエスト/応答メッセージを使用して、特定のパスが機能するかどうかをテストできます。実装は、現在使用されているパスが機能している場合でも、パステストを行う場合があります。たとえば、より良い（以前に利用できなかった）パスが利用可能になった時期を検出します。
In MOBIKE, the initiator is responsible for detecting and recovering from most failures.
Mobikeでは、イニシエーターはほとんどの障害から検出および回復する責任があります。
To give the initiator enough time to detect the error, the responder SHOULD use relatively long timeout intervals when, for instance, retransmitting IKEv2 requests or deciding whether to initiate Dead Peer Detection. While no specific timeout lengths are required, it is suggested that responders continue retransmitting IKEv2 requests for at least five minutes before giving up.
エラーを検出するのに十分な時間をイニシエーターに与えるには、例えばIKEV2要求を再送信するか、デッドピア検出を開始するかどうかを決定する場合、レスポンダーは比較的長いタイムアウト間隔を使用する必要があります。特定のタイムアウトの長さは必要ありませんが、レスポンダーは、あきらめる前に少なくとも5分間IKEV2要求を再送信し続けることをお勧めします。
MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but as addresses may change, it is not sufficient to just verify that the peer is alive, but also that it is synchronized with the address updates and has not, for instance, ignored an address update due to failure to complete return routability test. This means that when there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the addresses used in those packets and determine that they correspond to those that should be employed. If they do not, such packets SHOULD NOT be used as evidence that the peer is able to communicate with this node and or that the peer has received all address updates.
Mobikeは通常のIKEV2と同じ死んだピア検出方法を使用しますが、アドレスが変化する可能性があるため、ピアが生きていることを確認するだけでは不十分ですが、アドレスの更新と同期しており、たとえば、無視していないこともありません。Returbability Testを完了できなかったためのアドレス更新。これは、IPSecパケットが着信する場合、Mobikeノードはそれらのパケットで使用されるアドレスを検査し、使用する必要があるものに対応することを決定する必要があることを意味します。そうでない場合、そのようなパケットは、ピアがこのノードと通信できるという証拠として、またはピアがすべてのアドレスアップデートを受け取ったという証拠として使用すべきではありません。
This specification defines several new IKEv2 Notify payload types. See [IKEv2], Section 3.10, for a general description of the Notify payload.
この仕様では、いくつかの新しいIKEV2がペイロードタイプを通知します。通知ペイロードの一般的な説明については、[IKEV2]、セクション3.10を参照してください。
The responder can include this notification in an INFORMATIONAL exchange response to indicate that the address change in the corresponding request message (which contained an UPDATE_SA_ADDRESSES notification) was not carried out.
レスポンダーには、この通知を情報交換応答に含めることができ、対応するリクエストメッセージ（update_sa_addresses通知が含まれている）のアドレスの変更が実行されなかったことを示します。
The Notify Message Type for UNACCEPTABLE_ADDRESSES is 40. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type.
容認できない_AddressesのNotifyメッセージタイプは40です。プロトコルIDおよびSPIサイズフィールドはゼロに設定されています。このNotifyタイプに関連付けられたデータはありません。
See Section 3.9 for a description of this notification.
この通知の説明については、セクション3.9を参照してください。
The Notify Message Type for UNEXPECTED_NAT_DETECTED is 41. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type.
nectionify_nat_detectedのNotifyメッセージタイプは41です。プロトコルIDおよびSPIサイズフィールドはゼロに設定されています。このNotifyタイプに関連付けられたデータはありません。
The MOBIKE_SUPPORTED notification is included in the IKE_AUTH exchange to indicate that the implementation supports this specification.
mobike_supported通知は、ike_auth Exchangeに含まれており、実装がこの仕様をサポートしていることを示します。
The Notify Message Type for MOBIKE_SUPPORTED is 16396. The Protocol ID and SPI Size fields are set to zero. The notification data field MUST be left empty (zero-length) when sending, and its contents (if any) MUST be ignored when this notification is received. This allows the field to be used by future versions of this protocol.
Mobike_SupportedのNotifyメッセージタイプは16396です。プロトコルIDおよびSPIサイズフィールドはゼロに設定されています。通知データフィールドは、送信時に空のままにしておく必要があり、この通知を受信したときにその内容（存在する場合）は無視する必要があります。これにより、このプロトコルの将来のバージョンでフィールドを使用できます。
Both parties can include ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and INFORMATIONAL exchange request messages; see Section 3.4 and Section 3.6 for more detailed description.
どちらの関係者も、IKE_AUTH Exchangeおよび情報交換リクエストメッセージに追加の_IP4_ADDRESSおよび/またはADDATION_IP6_ADDRESS通知を含めることができます。詳細な説明については、セクション3.4およびセクション3.6を参照してください。
The Notify Message Types for ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS are 16397 and 16398, respectively. The Protocol ID and SPI Size fields are set to zero. The data associated with these Notify types is either a four-octet IPv4 address or a 16-octet IPv6 address.
追加の_IP4_ADDRESSおよびAdditional_IP6_AddressのNotifyメッセージタイプは、それぞれ16397と16398です。プロトコルIDおよびSPIサイズフィールドはゼロに設定されています。これらのNotifyタイプに関連付けられているデータは、4オクテットのIPv4アドレスまたは16オクテットのIPv6アドレスのいずれかです。
The NO_ADDITIONAL_ADDRESSES notification can be included in an INFORMATIONAL exchange request message to indicate that the exchange initiator does not have addresses beyond the one used in the exchange (see Section 3.6 for more detailed description).
NO_ADDITIONAL_ADDRESSES通知は、交換イニシエーターが取引所で使用されているものを超えたアドレスを持っていないことを示すための情報交換要求メッセージに含めることができます（詳細な説明については、セクション3.6を参照）。
The Notify Message Type for NO_ADDITIONAL_ADDRESSES is 16399. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type.
NO_ADDITIONAL_ADDRESSESのNotifyメッセージタイプは16399です。プロトコルIDおよびSPIサイズフィールドはゼロに設定されています。このNotifyタイプに関連付けられたデータはありません。
This notification is included in INFORMATIONAL exchange requests sent by the initiator to update addresses of the IKE_SA and IPsec SAs (see Section 3.5).
この通知は、IKE_SAおよびIPSEC SASのアドレスを更新するために、イニシエーターから送信された情報交換リクエストに含まれています（セクション3.5を参照）。
The Notify Message Type for UPDATE_SA_ADDRESSES is 16400. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type.
update_sa_addressesのNotifyメッセージタイプは16400です。プロトコルIDおよびSPIサイズフィールドはゼロに設定されています。このNotifyタイプに関連付けられたデータはありません。
This notification MAY be included in any INFORMATIONAL request for return routability check purposes (see Section 3.7). If the INFORMATIONAL request includes COOKIE2, the exchange responder MUST copy the notification to the response message.
この通知は、返品可能性チェックの目的のための情報リクエストに含まれる場合があります（セクション3.7を参照）。情報リクエストにCookie2が含まれている場合、Exchange Responderは通知を応答メッセージにコピーする必要があります。
The data associated with this notification MUST be between 8 and 64 octets in length (inclusive), and MUST be chosen by the exchange initiator in a way that is unpredictable to the exchange responder. The Notify Message Type for this message is 16401. The Protocol ID and SPI Size fields are set to zero.
この通知に関連付けられたデータは、長さ8〜64オクテット（包括的）でなければならず、Exchange Responderが予測不可能な方法でExchangeイニシエーターによって選択される必要があります。このメッセージの通知メッセージタイプは16401です。プロトコルIDおよびSPIサイズフィールドはゼロに設定されています。
See Section 3.9 for a description of this notification.
この通知の説明については、セクション3.9を参照してください。
The Notify Message Type for this message is 16402. The notification data contains the IP addresses and ports from/to which the packet was sent. For IPv4, the notification data is 12 octets long and is defined as follows:
このメッセージの通知メッセージタイプは16402です。通知データには、パケットが送信されたIPアドレスとポートが含まれています。IPv4の場合、通知データの長さは12オクターで、次のように定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source IPv4 address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Destination IPv4 address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source port ! Destination port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For IPv6, the notification data is 36 octets long and is defined as follows:
IPv6の場合、通知データの長さは36オクターで、次のように定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! Source IPv6 address !
! !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! Destination IPv6 address !
! !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source port ! Destination port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol ID and SPI Size fields are set to zero.
プロトコルIDおよびSPIサイズフィールドはゼロに設定されています。
The main goals of this specification are to maintain the security offered by usual IKEv2 procedures and to counter mobility-related threats in an appropriate manner. This section describes new security considerations introduced by MOBIKE. See [IKEv2] for security considerations for IKEv2 in general.
この仕様の主な目標は、通常のIKEV2手順によって提供されるセキュリティを維持し、モビリティ関連の脅威に適切な方法で対抗することです。このセクションでは、Mobikeが導入した新しいセキュリティに関する考慮事項について説明します。一般的なIKEV2のセキュリティ上の考慮事項については、[IKEV2]を参照してください。
MOBIKE payloads relating to updating addresses are encrypted, integrity protected, and replay protected using the IKE_SA. This assures that no one except the participants can, for instance, give a control message to change the addresses.
アドレスの更新に関連するMobikeペイロードは、暗号化され、整合性保護され、IKE_SAを使用してリプレイ保護されています。これにより、参加者以外の誰も、たとえば、アドレスを変更するためのコントロールメッセージを提供できないことが保証されます。
However, as with normal IKEv2, the actual IP addresses in the IP header are not covered by the integrity protection. This means that a NAT between the parties (or an attacker acting as a NAT) can modify the addresses and cause incorrect tunnel header (outer) IP addresses to be used for IPsec SAs. The scope of this attack is limited mainly to denial of service because all traffic is protected using IPsec.
ただし、通常のIKEV2と同様に、IPヘッダーの実際のIPアドレスは整合性保護の対象ではありません。これは、パーティー（またはNATとして機能する攻撃者）間のNATがアドレスを変更し、IPSEC SASに使用される誤ったトンネルヘッダー（外側）IPアドレスを引き起こすことを意味します。この攻撃の範囲は、すべてのトラフィックがIPSECを使用して保護されているため、主にサービスの拒否に制限されています。
This attack can only be launched by on-path attackers that are capable of modifying IKEv2 messages carrying NAT detection payloads (such as Dead Peer Detection messages). By modifying the IP header of these packets, the attackers can lead the peers to believe a new NAT or a changed NAT binding exists between them. The attack can continue as long as the attacker is on the path, modifying the IKEv2 messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms designed to detect NAT mapping changes will eventually recognize that the intended traffic is not getting through, and will update the addresses appropriately.
この攻撃は、NAT検出ペイロード（デッドピア検出メッセージなど）を運ぶIKEV2メッセージを変更できるパスオンパス攻撃者によってのみ開始できます。これらのパケットのIPヘッダーを変更することにより、攻撃者はピアに新しいNATまたは変更されたNATバインディングがそれらの間に存在すると信じるように導くことができます。攻撃者がパス上にある限り、攻撃は継続し、IKEV2メッセージを変更します。これがもはや当てはまらない場合、NATマッピングの変更を検出するために設計されたIKEV2およびMobikeメカニズムは、最終的に意図したトラフィックが通過していないことを認識し、アドレスを適切に更新します。
MOBIKE introduces the NO_NATS_ALLOWED notification that is used to detect modification, by outsiders, of the addresses in the IP header. When this notification is used, communication through NATs and other address translators is impossible, so it is sent only when not doing NAT Traversal. This feature is mainly intended for IPv6 and site-to-site VPN cases, where the administrators may know beforehand that NATs are not present.
Mobikeは、IPヘッダーのアドレスの修正を検出するために使用されるNO_NATS_ALLOWED通知を紹介します。この通知を使用すると、NATやその他のアドレス翻訳者を介した通信は不可能であるため、NATトラバーサルをしない場合にのみ送信されます。この機能は、主にIPv6およびサイト間VPNケースを対象としています。これは、管理者がNATが存在しないことを事前に知っている場合があります。
The use of IPsec protection on payload traffic protects the participants against disclosure of the contents of the traffic, should the traffic end up in an incorrect destination or be subject to eavesdropping.
ペイロードトラフィックにIPSEC保護を使用すると、トラフィックが誤った宛先に終わるか、盗聴の対象となる場合、トラフィックの内容の開示から参加者が保護されます。
However, security associations originally created for the protection of a specific flow between specific addresses may be updated by MOBIKE later on. This has to be taken into account if the (outer) IP address of the peer was used when deciding what kind of IPsec SAs the peer is allowed to create.
ただし、特定のアドレス間の特定のフローを保護するために元々作成されたセキュリティ関連は、後でMobikeによって更新される場合があります。ピアが作成できるIPSECの種類を決定する際にピアの（外側の）IPアドレスを使用した場合、これを考慮する必要があります。
For instance, the level of required protection might depend on the current location of the VPN client, or access might be allowed only from certain IP addresses.
たとえば、必要な保護のレベルは、VPNクライアントの現在の場所に依存する場合があります。または、特定のIPアドレスからのみアクセスが許可される場合があります。
It is recommended that security policies, for peers that are allowed to use MOBIKE, are configured in a manner that takes into account that a single security association can be used at different times through paths of varying security properties.
Mobikeの使用を許可されているピアのセキュリティポリシーは、さまざまなセキュリティプロパティのパスを介して異なる時期に単一のセキュリティ協会を使用できることを考慮した方法で構成されることをお勧めします。
This is especially critical for traffic selector authorization. The (logical) Peer Authorization Database (PAD) contains the information used by IKEv2 when determining what kind of IPsec SAs a peer is allowed to create. This process is described in [IPsecArch], Section 4.4.3. When a peer requests the creation of an IPsec SA with some traffic selectors, the PAD must contain "Child SA Authorization Data" linking the identity authenticated by IKEv2 and the addresses permitted for traffic selectors. See also [Clarifications] for a more extensive discussion.
これは、トラフィックセレクターの承認にとって特に重要です。（論理）ピア認証データベース（PAD）には、ピアが作成できるIPSEC SASの種類を決定する際にIKEV2が使用する情報が含まれます。このプロセスは、[IPSecarch]、セクション4.4.3で説明されています。ピアがいくつかのトラフィックセレクターを使用してIPSEC SAの作成を要求する場合、パッドには、IKEV2によって認証されたアイデンティティとトラフィックセレクターの許可されているアドレスをリンクする「子SA認証データ」を含める必要があります。より広範な議論については、[明確化]も参照してください。
It is important to note that simply sending IKEv2 packets using some particular address does not automatically imply a permission to create IPsec SAs with that address in the traffic selectors. However, some implementations are known to use policies where simply being reachable at some address X implies a temporary permission to create IPsec SAs for address X. Here "being reachable" usually means the ability to send (or spoof) IP packets with source address X and receive (or eavesdrop) packets sent to X.
特定のアドレスを使用してIKEV2パケットを送信するだけでは、トラフィックセレクターにそのアドレスを使用してIPSEC SASを作成する許可を自動的に意味するものではないことに注意することが重要です。ただし、いくつかの実装は、一部のアドレスXで単純に到達可能なポリシーを使用することが知られていますXは、アドレスXのIPSEC SASを作成する一時的な許可を意味します。ここでは、「到達可能」を意味します。xに送信されたパケットを受信（または盗聴）パケット。
Using this kind of policies or extensions with MOBIKE may need special care to enforce the temporary nature of the permission. For example, when the peer moves to some other address Y (and is no longer reachable at X), it might be necessary to close IPsec SAs with traffic selectors matching X. However, these interactions are beyond the scope of this document.
この種のポリシーまたはMobikeで拡張機能を使用すると、許可の一時的な性質を実施するために特別な注意が必要な場合があります。たとえば、ピアが他のアドレスYに移動する場合（Xでは到達できなくなった場合）、Xを一致させるトラフィックセレクターでIPSEC SASを閉じる必要がある場合があります。ただし、これらの相互作用はこのドキュメントの範囲を超えています。
Traffic redirection may be performed not just to gain access to the traffic or to deny service to the peers, but also to cause a denial-of-service attack on a third party. For instance, a high-speed TCP session or a multimedia stream may be redirected towards a victim host, causing its communications capabilities to suffer.
トラフィックリダイレクトは、トラフィックへのアクセスやピアへのサービスを拒否するだけでなく、サードパーティへのサービス拒否攻撃を引き起こすためにも実行される場合があります。たとえば、高速TCPセッションまたはマルチメディアストリームは、被害者のホストに向かってリダイレクトされ、通信機能が損なわれます。
The attackers in this threat can be either outsiders or even one of the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers can be easily dealt with if the authentication performed in the initial IKEv2 negotiation can be traced to persons who can be held responsible for the attack. This may not be the case in all scenarios, particularly with opportunistic approaches to security.
この脅威の攻撃者は、部外者またはIKEV2ピアの1人でさえあります。通常のVPN使用シナリオでは、最初のIKEV2交渉で実行された認証が攻撃の責任を負うことができる人に追跡できる場合、ピアによる攻撃は簡単に対処できます。これは、特にセキュリティに対する日和見的なアプローチに伴い、すべてのシナリオに当てはまるわけではありません。
If the attack is launched by an outsider, the traffic flow would normally stop soon due to the lack of responses (such as transport layer acknowledgements). However, if the original recipient of the flow is malicious, it could maintain the traffic flow for an extended period of time, since it often would be able to send the required acknowledgements (see [Aura02] for more discussion).
攻撃が部外者によって発売された場合、応答がないため（輸送層の確認など）、通常、トラフィックフローがすぐに停止します。ただし、フローの元の受信者が悪意のある場合、必要な謝辞を送信できることが多いため、トラフィックフローを長期間維持することができます（詳細については[Aura02]を参照）。
It should also be noted, as shown in [Bombing], that without ingress filtering in the attacker's network, such attacks are already possible simply by sending spoofed packets from the attacker to the victim directly. Furthermore, if the attacker's network has ingress filtering, this attack is largely prevented for MOBIKE as well. Consequently, it makes little sense to protect against attacks of similar nature in MOBIKE. However, it still makes sense to limit the amplification capabilities provided to attackers, so that they cannot use stream redirection to send a large number of packets to the victim by sending just a few packets themselves.
また、[爆撃]に示されているように、攻撃者のネットワークでの侵入フィルタリングがなければ、そのような攻撃は攻撃者から被害者に直接送信するだけで既に可能であることに注意する必要があります。さらに、攻撃者のネットワークがフィルタリングを侵入している場合、この攻撃はMobikeにとっても大部分が妨げられます。その結果、Mobikeの同様の性質の攻撃から保護することはほとんど意味がありません。ただし、攻撃者に提供される増幅機能を制限することは依然として理にかなっています。そのため、ストリームリダイレクトを使用して、少数のパケットだけを送信して多数のパケットを被害者に送信できません。
This specification includes return routability tests to limit the duration of any "third party bombing" attacks by off-path (relative to the victim) attackers. The tests are authenticated messages that the peer has to respond to, and can be performed before the address change takes effect, immediately afterwards, or even periodically during the session. The tests contain unpredictable data, and only someone who has the keys associated with the IKE SA and has seen the request packet can properly respond to the test.
この仕様には、パスオフパス（被害者と比較して）攻撃者による「サードパーティの爆撃」攻撃の期間を制限するための返品ルー上のテストが含まれています。テストは、ピアが応答しなければならない認証されたメッセージであり、アドレスの変更が直後に、またはセッション中に定期的に有効になる前に実行することができます。テストには予測不可能なデータが含まれており、IKE SAに関連付けられたキーを持っていて、リクエストパケットがテストに適切に応答できるのを見た人のみが含まれています。
The duration of the attack can also be limited if the victim reports the unwanted traffic to the originating IPsec tunnel endpoint using ICMP error messages or INVALID_SPI notifications. As described in [IKEv2], Section 2.21, this SHOULD trigger a liveness test, which also doubles as a return routability check if the COOKIE2 notification is included.
ICMPエラーメッセージまたはInvalID_SPI通知を使用して、被害者が元のIPSECトンネルエンドポイントへの不要なトラフィックを報告した場合、攻撃の期間も制限される可能性があります。[IKEV2]、セクション2.21で説明されているように、これにより、Cookie2通知が含まれているかどうかを返すルーティング可能性チェックとしても兼ねるliveningテストがトリガーされるはずです。
Attackers may spoof various indications from lower layers and the network in an effort to confuse the peers about which addresses are or are not working. For example, attackers may spoof link-layer error messages in an effort to cause the parties to move their traffic elsewhere or even to disconnect. Attackers may also spoof information related to network attachments, router discovery, and address assignments in an effort to make the parties believe they have Internet connectivity when, in reality, they do not.
攻撃者は、どのアドレスが機能しているか、または機能していないかについて、仲間を混乱させるために、下層とネットワークからのさまざまな兆候を吸収する場合があります。たとえば、攻撃者は、当事者にトラフィックを他の場所に移動させたり、切断したりするために、リンク層エラーメッセージをスプーフィングする場合があります。攻撃者はまた、ネットワークの添付ファイル、ルーターの発見、および課題に関連する情報をスプーフィングすることができ、実際にはそうでない場合に、当事者がインターネット接続を持っていると信じさせるために努力することもできます。
This may cause use of non-preferred addresses or even denial of service.
これにより、非繰り返しの住所やサービスの拒否を引き起こす可能性があります。
MOBIKE does not provide any protection of its own for indications from other parts of the protocol stack. These vulnerabilities can be mitigated through the use of techniques specific to the other parts of the stack, such as validation of ICMP errors [ICMPAttacks], link layer security, or the use of [SEND] to protect IPv6 Router and Neighbor Discovery.
Mobikeは、プロトコルスタックの他の部分からの適応について、独自の保護を提供しません。これらの脆弱性は、ICMPエラー[ICMPATTACKS]、リンクレイヤーセキュリティ、またはIPv6ルーターと近隣発見を保護するための[送信]の使用など、スタックの他の部分に固有の手法を使用することで軽減できます。
Ultimately, MOBIKE depends on the delivery of IKEv2 messages to determine which paths can be used. If IKEv2 messages sent using a particular source and destination addresses reach the recipient and a reply is received, MOBIKE will usually consider the path working; if no reply is received even after retransmissions, MOBIKE will suspect the path is broken. An attacker who can consistently control the delivery or non-delivery of the IKEv2 messages in the network can thus influence which addresses actually get used.
最終的に、MobikeはIKEV2メッセージの配信に依存して、使用できるパスを決定します。特定のソースと宛先アドレスを使用して送信されたIKEV2メッセージが受信者に到達し、返信が受信された場合、Mobikeは通常、パスの動作を検討します。再送信後でも返信がない場合、Mobikeはパスが壊れていると思われます。したがって、ネットワーク内のIKEV2メッセージの配信または非配信を一貫して制御できる攻撃者は、実際に使用されるアドレスに影響を与える可能性があります。
MOBIKE address updates and the ADDITIONAL_IP4_ADDRESS/ ADDITIONAL_IP6_ADDRESS notifications reveal information about which networks the peers are connected to.
Mobike Addressの更新とAddational_IP4_Address/ Addational_ip6_Address通知は、ピアが接続されているネットワークに関する情報を明らかにします。
For example, consider a host A with two network interfaces: a cellular connection and a wired Ethernet connection to a company LAN. If host A now contacts host B using IKEv2 and sends ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications, host B receives additional information it might not otherwise know. If host A used the cellular connection for the IKEv2 traffic, host B can also see the company LAN address (and perhaps further guess that host A is used by an employee of that company). If host A used the company LAN to make the connection, host B can see that host A has a subscription from this particular cellular operator.
たとえば、2つのネットワークインターフェイスを備えたホストAを検討します。セルラー接続と会社LANへの有線イーサネット接続です。Host AがIKEV2を使用してホストBに連絡し、追加の_IP4_ADDRESS/ADDATION_IP6_ADDRESS通知を送信すると、ホストBは他の方法では知らない追加情報を受信します。ホストAがIKEV2トラフィックのセルラー接続を使用した場合、ホストBは会社LANアドレスを見ることができます（そしておそらく、ホストAはその会社の従業員によって使用されると推測します）。ホストAを使用してLANを使用して接続を作成した場合、ホストBはホストAがこの特定のセルラー演算子からサブスクリプションを持っていることを確認できます。
These additional addresses can also disclose more accurate location information than just a single address. Suppose that host A uses its cellular connection for IKEv2 traffic, but also sends an ADDITIONAL_IP4_ADDRESS notification containing an IP address corresponding to, say, a wireless LAN at a particular coffee shop location. It is likely that host B can now make a much better guess at A's location than would be possible based on the cellular IP address alone.
これらの追加アドレスは、単一のアドレスよりも正確な位置情報を開示することもできます。ホストAがIKEV2トラフィックにセルラー接続を使用するだけでなく、特定のコーヒーショップの場所でワイヤレスLANに対応するIPアドレスを含む追加の_IP4_Address通知も送信すると仮定します。ホストBは、セルラーIPアドレスのみに基づいて可能になるよりも、Aの位置ではるかに良い推測をすることができる可能性があります。
Furthermore, as described in Section 3.4, some of the addresses could also be private addresses behind a NAT.
さらに、セクション3.4で説明されているように、アドレスの一部は、NATの背後にあるプライベートアドレスである可能性があります。
In many environments, disclosing address information is not a problem (and indeed it cannot be avoided if the hosts wish to use those addresses for IPsec traffic). For instance, a remote access VPN client could consider the corporate VPN gateway sufficiently trustworthy for this purpose. Furthermore, the ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications are sent encrypted, so the addresses are not visible to eavesdroppers (unless, of course, they are later used for sending IKEv2/IPsec traffic).
多くの環境では、アドレス情報の開示は問題ではありません（実際、ホストがIPSECトラフィックにそれらのアドレスを使用したい場合は避けることはできません）。たとえば、リモートアクセスVPNクライアントは、この目的のためにコーポレートVPNゲートウェイを十分に信頼できると考えることができます。さらに、追加の_IP4_ADDRESSおよびADDATION_IP6_ADDRESS通知は暗号化されて送信されるため、アドレスは盗聴者に表示されません（もちろん、後でIKEV2/IPSECトラフィックを送信するために使用されない限り）。
However, if MOBIKE is used in some more opportunistic approach, it can be desirable to limit the information that is sent. Naturally, the peers do not have to disclose any addresses they do not want to use for IPsec traffic. Also, as noted in Section 3.6, an initiator whose policy is to always use the locally configured responder address does not have to send any ADDITIONAL_IP4_ADDRESS/ ADDITIONAL_IP6_ADDRESS payloads.
ただし、Mobikeがより日和的なアプローチで使用されている場合、送信される情報を制限することが望ましい場合があります。当然、ピアはIPSECトラフィックに使用したくないアドレスを開示する必要はありません。また、セクション3.6に記載されているように、ローカルで構成されたレスポンダーアドレスを常に使用するというポリシーでは、追加の_IP4_Address/ Addational_IP6_Addressペイロードを送信する必要はありません。
This document does not create any new namespaces to be maintained by IANA, but it requires new values in namespaces that have been defined in the IKEv2 base specification [IKEv2].
このドキュメントでは、IANAによって維持される新しい名前空間は作成されませんが、IKEV2ベース仕様[IKEV2]で定義されている名前空間に新しい値が必要です。
This document defines several new IKEv2 notifications whose values have been allocated from the "IKEv2 Notify Message Types" namespace.
このドキュメントでは、「IKEV2通知メッセージタイプ」という名前から値が割り当てられたいくつかの新しいIKEV2通知を定義します。
Notify Messages - Error Types Value
----------------------------- -----
UNACCEPTABLE_ADDRESSES 40
UNEXPECTED_NAT_DETECTED 41
Notify Messages - Status Types Value
------------------------------ -----
MOBIKE_SUPPORTED 16396
ADDITIONAL_IP4_ADDRESS 16397
ADDITIONAL_IP6_ADDRESS 16398
NO_ADDITIONAL_ADDRESSES 16399
UPDATE_SA_ADDRESSES 16400
COOKIE2 16401
NO_NATS_ALLOWED 16402
These notifications are described in Section 4.
これらの通知については、セクション4で説明します。
This document is a collaborative effort of the entire MOBIKE WG. We would particularly like to thank Jari Arkko, Tuomas Aura, Marcelo Bagnulo, Stephane Beaulieu, Elwyn Davies, Lakshminath Dondeti, Francis Dupont, Paul Hoffman, James Kempf, Tero Kivinen, Pete McCann, Erik Nordmark, Mohan Parthasarathy, Pekka Savola, Bill Sommerfeld, Maureen Stillman, Shinta Sugimoto, Hannes Tschofenig, and Sami Vaarala. This document also incorporates ideas and text from earlier MOBIKE-like protocol proposals, including [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the MOBIKE design document [Design].
このドキュメントは、Mobike WG全体の共同作業です。特に、ジャリ・アークコ、トゥオマス・オーラ、マルセロ・バグヌロ、ステファン・ボーリュー、エルウィン・デイビス、ラクシュミナート・ドンデティ、フランシス・デュポン、ポール・ホフマン、ジェームズ・ケンプフ、テロ・キビネン、ピート・マッカン、エリック・ノルドマーク、モハン・パルササルマー、ペンマー、ペンマー仏、Maureen Stillman、Shinta Sugimoto、Hannes Tschofenig、およびSami Vaarala。このドキュメントには、[addrmgmt]、[kivinen]、[mopo]、[smobike]、およびmobike design document [design]など、以前のMobikeのようなプロトコル提案のアイデアとテキストも組み込まれています。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[IPsecArch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[Ipsecarch] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、1997年3月。
[AddrMgmt] Dupont, F., "Address Management for IKE version 2", Work in Progress, November 2005.
[addrmgmt] Dupont、F。、「IKEバージョン2のアドレス管理」、2005年11月、Work in Progress。
[Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", Proc. 18th Annual Computer Security Applications Conference (ACSAC), December 2002.
[Aura02] Aura、T.、Roe、M。、およびJ. Arkko、「インターネットロケーション管理のセキュリティ」、Proc。第18回年次コンピューターセキュリティアプリケーション会議（ACSAC）、2002年12月。
[Bombing] Dupont, F., "A note about 3rd party bombing in Mobile IPv6", Work in Progress, December 2005.
[爆撃]デュポン、F。、「モバイルIPv6での第3党の爆撃に関するメモ」、2005年12月、進行中の作業。
[Clarifications] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", Work in Progress, February 2006.
[明確化] Eronen、P。およびP. Hoffman、「IKEV2の説明と実装ガイドライン」、2006年2月、Work in Progress。
[DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[DNA4] Aboba、B.、Carlson、J。、およびS. Cheshire、「IPv4（DNAV4）のネットワークアタッチメントの検出」、RFC 4436、2006年3月。
[DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting Network Attachment in IPv6 - Best Current Practices for hosts", Work in Progress, October 2005.
[DNA6] Narayanan、S.、Daley、G。、およびN. Montavont、「IPv6のネットワーク添付ファイルの検出 - ホストの最良の現在のプラクティス」、2005年10月、作業。
[Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", Work in Progress, January 2006.
[デザイン] Kivinen、T。およびH. Tschofenig、「Mobike Protocolのデザイン」、2006年1月、進行中の作業。
[ICMPAttacks] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2005.
[ICMPATTACKS] GONT、F。、「TCPに対するICMP攻撃」、2005年10月、進行中の作業。
[Kivinen] Kivinen, T., "MOBIKE protocol", Work in Progress, February 2004.
[キビネン]キビネン、T。、「Mobike Protocol」、2004年2月、進行中の作業。
[MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[MIP4] Perkins、C。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[MIP6] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO-IKE)", Work in Progress, February 2005.
[Mopo] Eronen、P。、「IKEV2（MOPO-yik）のモビリティプロトコルオプション」、2005年2月の作業。
[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月。
[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[送信] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and Multihoming Extensions for IKEv2 (SMOBIKE)", Work in Progress, March 2004.
[Smobike] Eronen、P。and H. Tschofenig、「IKEV2（Smobike）のシンプルなモビリティとマルチホミング拡張機能」、2004年3月、作業進行中。
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[Stun] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「Stun-ネットワークアドレス翻訳者（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、RFC 3489、2003年3月。
[UNSAF] Daigle, L., "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[UNSAF] Daigle、L。、「ネットワークアドレス翻訳全体の一方的な自己アドレス固定（UNSAF）のIABの考慮事項」、RFC 3424、2002年11月。
[IPsecArch], Section 4.4.2, says that "For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache". The document does not specify how exactly this "pointing" is done, since this is an implementation detail that does not have to be standardized.
[Ipsecarch]、セクション4.4.2は、「アウトバウンド処理の場合、SPDキャッシュのSPD-S部分のエントリによって、各悲しいエントリは指摘されています」と述べています。ドキュメントは、これが標準化する必要のない実装の詳細であるため、この「ポインティング」がどのように行われるかを正確に指定していません。
However, it is clear that the links between the SPD cache and the SAD have to be done correctly to ensure that outbound packets are sent over the right SA. Some implementations are known to have problems in this area.
ただし、SPDキャッシュとSADの間のリンクを正しく行う必要があることは明らかです。いくつかの実装は、この分野で問題があることが知られています。
In particular, simply storing the (remote tunnel header IP address, remote SPI) pair in the SPD cache is not sufficient, since the pair does not always uniquely identify a single SAD entry. For instance, two hosts behind the same NAT can accidentally happen to choose the same SPI value. The situation can also occur when a host is assigned an IP address previously used by some other host, and the SAs associated with the old host have not yet been deleted by Dead Peer Detection. This may lead to packets being sent over the wrong SA or, if the key management daemon ensures the pair is unique, denying the creation of otherwise valid SAs.
特に、SPDキャッシュに（リモートトンネルヘッダーIPアドレス、リモートSPI）ペアを単に保存するだけでは十分ではありません。ペアは常に単一のSADエントリを一意に識別するとは限らないからです。たとえば、同じNATの背後にある2つのホストが誤って同じSPI値を選択することができます。この状況は、ホストが以前に他のホストが以前に使用したIPアドレスを割り当てられ、古いホストに関連付けられたSASがデッドピア検出によってまだ削除されていない場合にも発生する可能性があります。これにより、間違ったSAにパケットが送信されるか、キー管理デーモンがペアがユニークであることを保証し、他の方法では有効なSAの作成を否定する場合があります。
Storing the remote tunnel header IP address in the SPD cache may also complicate the implementation of MOBIKE, since the address can change during the lifetime of the SA. Thus, we recommend implementing the links between the SPD cache and the SAD in a way that does not require modification when the tunnel header IP address is updated by MOBIKE.
SPDキャッシュにリモートトンネルヘッダーIPアドレスを保存すると、SAの寿命の間にアドレスが変更される可能性があるため、Mobikeの実装が複雑になる場合があります。したがって、Tunnel Header IPアドレスがMobikeによって更新されたときに変更を必要としない方法で、SPDキャッシュとThe Sadの間のリンクを実装することをお勧めします。
When an outbound packet requires IPsec processing but no suitable SA exists, a new SA will be created. In this case, the host has to determine (1) who is the right peer for this SA, (2) whether the host already has an IKE_SA with this peer, and (3) if no IKE_SA exists, the IP address(es) of the peer for contacting it.
アウトバウンドパケットにIPSEC処理が必要であるが、適切なSAが存在しない場合、新しいSAが作成されます。この場合、ホストは（1）このSAに適したピアである人、（2）ホストがすでにこのピアとIKE_SAを持っているかどうか、（3）IKE_SAが存在しない場合、IPアドレス（ES）を決定する必要があります。連絡してくれたピアの。
Neither [IPsecArch] nor MOBIKE specifies how exactly these three steps are carried out. [IPsecArch], Section 4.4.3.4, says:
[Ipsecarch]もMobikeも、これらの3つのステップがどのように実行されるかを指定していません。[IPSECARCH]、セクション4.4.3.4、次のように述べています。
For example, assume that IKE A receives an outbound packet destined for IP address X, a host served by a security gateway. RFC 2401 [RFC2401] and this document do not specify how A determines the address of the IKE peer serving X. However, any peer contacted by A as the presumed representative for X must be registered in the PAD in order to allow the IKE exchange to be authenticated. Moreover, when the authenticated peer asserts that it represents X in its traffic selector exchange, the PAD will be consulted to determine if the peer in question is authorized to represent X.
たとえば、IKE Aがセキュリティゲートウェイが提供するホストであるIPアドレスX向けのアウトバウンドパケットを受け取ると仮定します。RFC 2401 [RFC2401]およびこのドキュメントは、IKEピアサービングXのアドレスを決定する方法を指定していません。ただし、Xの推定代表者としてA AS AS AS AS AS AS AS AS AS AS ASがIKEの交換を許可するためには、PADに登録する必要があります。認証されます。さらに、認証されたピアがトラフィックセレクターの交換でXを表すと主張すると、パッドが相談され、問題のピアがXを表すことが許可されているかどうかを判断します。
In step 1, there may be more than one possible peer (e.g., several security gateways that are allowed to represent X). In step 3, the host may need to consult a directory such as DNS to determine the peer IP address(es).
ステップ1では、複数のピアがある場合があります（たとえば、xを表すことができるいくつかのセキュリティゲートウェイ）。ステップ3では、ホストはピアIPアドレス（ES）を決定するためにDNSなどのディレクトリを参照する必要がある場合があります。
When performing these steps, implementations may use information contained in the SPD, the PAD, and possibly some other implementation-specific databases. Regardless of how exactly the steps are implemented, it is important to remember that IP addresses can change, and that an IP address alone does not always uniquely identify a single IKE peer (for the same reasons as why the combination of the remote IP address and SPI does not uniquely identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1 and 2 it may be easier to identify the "right peer" using its authenticated identity instead of its current IP address. However, these implementation details are beyond the scope of this specification.
これらの手順を実行するとき、実装は、SPD、PAD、および場合によっては他のいくつかの実装固有のデータベースに含まれる情報を使用する場合があります。手順がどのように実装されているかに関係なく、IPアドレスが変更される可能性があり、IPアドレスだけが常に単一のIKEピアを独自に識別するとは限らないことを覚えておくことが重要です（リモートIPアドレスと組み合わせの組み合わせと同じ理由でSPIは、アウトバウンドIPSEC SAを一意に識別しません。付録A.1を参照）。したがって、手順1と2では、現在のIPアドレスの代わりに認証されたアイデンティティを使用して「右ピア」を識別する方が簡単かもしれません。ただし、これらの実装の詳細は、この仕様の範囲を超えています。
Author's Address
著者の連絡先
Pasi Eronen (editor) Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen（編集者）Nokia Research Center P.O.Box 407 Fin-00045 Nokia Group Finland
EMail: pasi.eronen@nokia.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）によって提供されます。