Network Working Group P. Eronen, Ed.
Request for Comments: 4555 Nokia
Category: Standards Track June 2006
IKEv2 Mobility and Multihoming Protocol (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).
著作権（C）インターネット協会（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プロトコル、インターネット鍵交換（IKEv2の）への移動性とマルチホーミング拡張について説明します。 MOBIKEは、IKEv2のとトンネルモードIPsecセキュリティアソシエーションに関連付けられたIPアドレスを変更することができます。別のアドレスから移動させながら、モバイル仮想プライベートネットワーク（VPN）クライアントがアクティブなVPNゲートウェイとの接続を維持するためにMOBIKEを使用することができます。同様に、マルチホームホストは、例えば、現在一方が作動停止を使用している場合など、異なるインターフェースにトラフィックを移動するために、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セキュリティアソシエーション（SA）を確立し、維持するために使用されます。ベースのIKEv2プロトコルで[IKEv2の]、IKE SAのトンネルモードのIPsec SAがIKE_SAを確立する際に使用されるIPアドレスとの間で暗黙的に作成されています。これらのIPアドレスは、次に、トンネルモードのIPsecパケットの外側（トンネルヘッダ）アドレス（トランスポート・モードのIPsec SAが、この文書の範囲外である）として使用されます。現在のところ、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アドレスが変更される場合がありますシナリオがあります。一例としては、移動度：ホストがネットワーク接続点を変更し、新しい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 SAを作成することによって解決することができるが、これはいくつかの理由のために最適ではないかもしれません。いくつかのケースでは、新しいIKE_SAを作成することは、トークンカードからコードを入力すると、認証用のユーザとの対話が必要な場合があります。新しいSAを作成すると、多くの場合、高価な計算と、おそらくラウンドトリップが多数含まれます。これらの理由から、既存のIKEおよびIPsec SAの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 SAのアドレス、およびアドレス及びトンネル内で使用される他のトラフィックセレクタは不変とどまります。このように、移動度は（主に）見えないアプリケーションや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 SAをサポートします。
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は、少なくとも一つのエンドポイントのアドレスは比較的安定であり、（セクション3.1を参照）DNSなど既存のメカニズムを使用して検出することができる状況に最も適しています。
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のために使用されています。具体的には、ロード・バランシングは、この仕様の範囲を超えています。
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設計書[デザイン]を参照してください。
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は]」）、およびプラス記号（「FOO +」、例えば）ペイロードを1回以上繰り返すことができることを示しています。コンテキストを提供するために、いくつかの図は、既存の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のソース/宛先アドレスの更新について説明する際、発信カプセル化セキュリティペイロード（ESP）/認証ヘッダ（AH）パケットがトンネルヘッダにこれらのアドレスを使用するように、それは、IPsec関連の状態を更新する手段とセキュリティアソシエーションデータベース間の公称部門が（SAD）、セキュリティポリシーデータベース（SPD）、および[IPsecArch]で説明ピア認証データベース（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_SAsの一連の）最初のIKE_SAを開始したパーティを意味します。 「応答者は」他のピアです。 IKE_SAの寿命の間に、両当事者は、INFORMATIONAL又はCREATE_CHILD_SA交換を開始することができます。この場合には、用語「交換イニシエータ」及び「交換レスポンダ」が使用されています。 （[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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アドレスのN * M組まであります。使用するこれらのペアのの決定は、アカウントにいくつかの要因を取る必要があります。まず、当事者は、インターフェイスが原因、例えば、性能とコストの理由に使用されるべきかについての好みを有することができます。第二に、決定はペアの一部が原因ように互換性のない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.
（リモートアクセスVPNのシナリオでは、「クライアント」）IKE_SAを開始したパーティのIPsec SAのために使用されたアドレスのペアを決定するため、それを作るために必要な情報を収集するための責任がある：MOBIKEは単純なアプローチを取ることによってこの問題を解決します（このようなアドレスのペアが動作したり動作しないかを決定するなど）、この決定。相手方（リモートアクセスVPNのシナリオでは、「ゲートウェイ」）は、単にそれが持っているアドレスが、それはそうするイニシエータからメッセージを受信するまでのIPsec SAを更新しない何イニシエータを伝えます。このアプローチは、IPsecのSA内のアドレスに適用されます。 IKE_SAの場合には、交換イニシエータは、アドレスが使用されているかを決定することができます。
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]内の接続のステータスを追跡するために使用することができます。動き検出ように[DNA6]、[DNA4]で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のSAのアドレスを更新すると、アカウントにいくつかのセキュリティ上の考慮事項を取ることがあります。 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交換を以下に示します。表記は[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) } -->
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) } -->
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.)
（レスポンダは、イニシエータがそれを正しいIPアドレスを与えていることを確認します。）
4) <-- (IP_R1:4500 -> IP_I2:4500) HDR, SK { N(COOKIE2) }
4）< - （IP_R1：4500 - > IP_I2：4500）HDR、SK {N（COOKIE2）}
(IP_I2:4500 -> IP_R1: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交換です。ステップ2では、ピアは、彼らがMOBIKEをサポートすることをお互いに通知します。ステップ3では、イニシエータは、自身のアドレスの変更を通知し、UPDATE_SA_ADDRESSES通知を含む情報要求を送信することによって、この約レスポンダに通知します。要求は、新しいIPアドレスを使用して送信されます。この時点で、それはまた、独自の発信ESPトラフィックの送信元アドレスとして新しいアドレスを使用することを開始します。 UPDATE_SA_ADDRESSES通知を受信すると、応答者は、それがポリシーによって必要とされている場合、アドレスのリターンルータビリティチェックを行い、新しいアドレスを記録し。このチェック（ステップ4）が完了すると、レスポンダは、発信ESPトラフィックの送信先として、新しいアドレスを使用することを開始します。
Another protocol run in a multihoming scenario is illustrated below. In this scenario, the initiator has one address but the responder has two.
マルチホーミングシナリオで実行する別のプロトコルを以下に示します。このシナリオでは、イニシエータは、一つのアドレスを持っていますが、応答は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) } -->
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) } -->
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) } -->
（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) }
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) } -->
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のか、ステートフルパケットフィルタを（簡潔にするため、このドキュメントの残りの部分は、単にNATのを記述）を含んでいてもよいです。 [IKEv2の]で指定されたNATトラバーサル機能は、IKEv2のは、多くの場合、NATを介して動作することを可能にする、とMOBIKEは、この機能を利用することができます：IPsecのSAの使用アドレスが変更された場合、必要に応じて、MOBIKEは、IKEv2のNATトラバーサルを有効または無効にすることができます。
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の背後にあります。応答者のアドレスが今変更した場合、それはその新しいアドレスを使用してイニシエータにパケットを送信する必要があります。しかし、NATである場合、例えば、共通の「制限されたコーン」型で、これは不可能である（異なるNATタイプのいずれかについては、[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「の背後にある」パーティで、応答者のアドレスが変更する場合は、完全に（特別な努力は、この機能をサポートするために行われていないことを意味する）はサポートされていないことを前提としています。レスポンダはまた、NATのか、彼らは背後にあるNATの特定のタイプを知らないかもしれません。ただし、変更は、接続の損失を引き起こすことが発生した場合には、MOBIKEレスポンダはまだ変更のイニシエータに通知しようとします。応じて、例えば、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拡張子から任意の情報にのみ交換が十分に進行したとき、後で利用できるようになります。正確にどのように初期の交換のために使用されるアドレスが発見され、この仕様の範囲を超えています。情報の典型的な源は、ローカル構成と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交換の場合には、SAペイロードを含むメッセージで）IKE_AUTH交換にMOBIKE_SUPPORTED通知を含まなければなりません。
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が作成されると、トンネルヘッダのIPアドレス（およびポートは、UDPカプセル化を行う場合）IKE_SA、のIPsec SAを要求するのIKEv2メッセージのないIPヘッダから取られます。 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).
NATが発見された場合のIKEv2は4500にポート500から変更する必要があるためアドレスは、IKE_AUTH要求から取得されます。特派員はまた、（何のNATがそれらの間で検出されなかった場合でも、このように両方をサポートしている場合、物事を単純化するために、本明細書およびNATトラバーサルの両方をサポートする実装は、ポート4500に変更する必要があり、NATがある場合は、後にポートを変更する必要はありません他のいくつかのパスで検出されました）。
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.
イニシエータとレスポンダの両方が（SAペイロードを含むメッセージ内の複数のIKE_AUTH交換の場合には、）IKE_AUTH交換における1つ以上のADDITIONAL_IP4_ADDRESS及び/又はADDITIONAL_IP6_ADDRESS通知を含むかもしれません。ここで「付加_ * _ ADDRESS」ADDITIONAL_IP4_ADDRESSまたはADDITIONAL_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節で説明した手順を使用して、これらのアドレスの1つに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の背後にある場合、応答者によって受信されたアドレスが正しくないことに注意してください。これは、イニシエータがNATの背後にある場合、セクション3.6で説明した応答者のアドレスを変更するための手順が完全に動作しないことを意味します。同じ理由で、ピアはまた、明示的にこの文書またはそれを更新し、将来の仕様のいずれかで記述されているもの以外の目的のために、この情報を使用しないでください。
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のSAの中で使用されているかを決定します。すなわち、レスポンダは、通常、イニシエータからの明示的なUPDATE_SA_ADDRESSES要求を受信することなく、任意のIPsec SAを更新しない、です。 （後述するように、応答者は、しかし、いくつかの状況では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 ADDITIONAL_IP4_ADDRESSを含む情報要求は、ADDITIONAL_IP6_ADDRESS、又はNO_ADDITIONAL_ADDRESSES通知が受信されます。これは、ピアのアドレスが変更された可能性があることを意味します。アドレスの発表されたセットは、もはや現在使用されたアドレスが含まれていない場合、これは特に重要です。
o An UNACCEPTABLE_ADDRESSES notification is received as a response to address update request (described below).
O UNACCEPTABLE_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応答（より詳細な説明については、セクション3.8を参照）と一致しないNAT_DETECTION_DESTINATION_IP通知を受信します。
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（イニシエータのポリシーはIPsecのSAを更新する前に、リターン・ルータビリティチェックを必要としない限り、チェックは、まだこのレスポンダアドレスに対して行われていない）新しいアドレスを持つこのIKE_SAに関連したIPSec SAを更新します。
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).
NATトラバーサルが有効でない場合、および応答者は、NATトラバーサル（IKE_SA_INIT交換においてNAT検出ペイロードによって示されるように）、およびイニシエータにどちらかの容疑者をサポートしていますかNATの可能性があることを知っている：OのIPsec SAが前のステップで更新された場合存在することが、NATトラバーサル（つまり、発信ESPパケットのUDPカプセル化を可能にし、NATキープアライブパケットの送信）できます。
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).
（イニシエータが、まだ返事を受け取っていないいる要求）非凡のIKEv2の要求がある場合は、O、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:
ウィンドウサイズが許す場合には、O、（任意のデータが含まれていない）UPDATE_SA_ADDRESSES通知を含む情報要求を送信し、「pending_update」フラグをクリアします。次のようにリクエストは次のようになります。
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 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は、それが既に（レスポンダが1より大きいウィンドウサイズを使用する場合、要求が順序を外れて受信されることが可能である）、これよりも新しいUPDATE_SA_ADDRESSES要求を受信したか否かを判定する。それは持っている場合、通常の応答メッセージは、（後述）が送信されるが、他のアクションは行われません。
o If the NO_NATS_ALLOWED notification is present, processes it as described in Section 3.9.
NO_NATS_ALLOWED通知が存在する場合、セクション3.9で説明したように、O、それを処理します。
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アドレス）がペアは、ローカルポリシーに従って許容されます。そうでない場合、（おそらくとCOOKIE2）UNACCEPTABLE_ADDRESSES通知を含むメッセージで応答します。
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 IPヘッダからの値でIKE_SAでIPアドレスを更新します。 （IPヘッダからのアドレスを使用すると、通常のIKEv2と一致している、とのIKEv2は[UNSAF】固定片側自己アドレスを必要とせずにNATを用いて作業することができます。）
o Replies with an INFORMATIONAL response:
oはINFORMATIONAL応答と語り合う場です。
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 SAを更新します。
o If NAT Traversal is supported and NAT detection payloads were included, enables or disables NAT Traversal.
NATトラバーサルがサポートされており、NAT検出ペイロードが含まれていた場合は、O、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.
応答がUNEXPECTED_NAT_DETECTED通知が含まれている場合は、セクション3.9で説明したように、O、イニシエータは、応答を処理します。
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.
応答がUNACCEPTABLE_ADDRESSES通知が含まれている場合は、O、イニシエータは別のアドレスを選択して交換を再試行し、以前に使用されるアドレス、または切断を使用し続けるかもしれません。
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 SAを更新します。
o If NAT Traversal is supported and NAT detection payloads were included, the initiator enables or disables NAT Traversal.
NATトラバーサルがサポートされており、NAT検出ペイロードが含まれていた場合は、O、イニシエータは、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).
レスポンダはUPDATE_SA_ADDRESSES要求を受信することなく、任意のIPSec SAを更新したことがない規則には例外が1つあります。応答者が現在使用している送信元アドレス（すなわち、送信元アドレスは、もはや不可能であることを使用してパケットを送信する）使用できなくなった場合、応答者はで説明した手順を開始に加えて、他のいくつかのアドレスを（使用してIPSec SAを更新するために許可されています次のセクション）。
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交換において、追加のアドレスのリストを送信することができます。この情報は、1つまたは複数のADDITIONAL_IP4_ADDRESS / ADDITIONAL_IP6_ADDRESS通知またはNO_ADDITIONAL_ADDRESSES通知のいずれかを含むINFORMATIONAL交換要求メッセージを送信することにより更新することができます。
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.
交換イニシエータが単一のIPアドレスを持っている場合は、IPヘッダに入れ、メッセージがNO_ADDITIONAL_ADDRESSES通知が含まれます。交換イニシエータは、複数のアドレスを持っている場合は、そのうちの一つは、IPヘッダに入れ、残りADDITIONAL_IP4_ADDRESS / ADDITIONAL_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)] }
< - 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:
ADDITIONAL_IP4_ADDRESS、ADDITIONAL_IP6_ADDRESS、又はNO_ADDITIONAL_ADDRESSES通知を含む要求を受信した場合、交換レスポンダ：
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.
NO_NATS_ALLOWED通知が存在する場合、セクション3.9で説明したように、O、それを処理します。
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ヘッダとADDITIONAL_IP4_ADDRESS、ADDITIONAL_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.
アドレスを更新するための要求は、いくつかの異なる送信元アドレスを使用して再送された場合は、新しいINFORMATIONAL要求を送らなければなりません。
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.
応答者がアドレスセットを更新したい場合、現在使用されたアドレスが機能しなくなることがあります。一つの追加の合併症があります。この場合、レスポンダはINFORMATIONAL要求を送信するために使用するアドレスを決定するために、イニシエータから受信した追加アドレスリスト、および独自のアドレスのリストを使用します。これは、応答は、イニシエータから受信した追加のアドレスリストを使用する唯一の時間です。
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).
両方のピアは、アドレスが使用する許容されるかについて、独自のポリシーを持っていることに注意してください、との方針の特定の種類は、実装を簡素化することができます。レスポンダは、単一の固定アドレスを有する場合、例えば、それは、（既に【のIKEv2]で必要に応じて、認識されていない状態通知を無視越え）が受信ADDITIONAL_IP4_ADDRESSとADDITIONAL_IP6_ADDRESS通知を処理する必要はありません。さらに、イニシエータは、ローカル設定で指定された唯一の応答者のアドレスが許容され、それは（応答者は、自身のアドレスを変更する場合を除き、それらを必要としないため）レスポンダに独自の追加のアドレスを送信する必要がないことを言ってポリシーを持っている場合。
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.
両当事者は、必要に応じて他の当事者が実際に主張したアドレスにパケットを受信できるかどうかを確認することができます。デフォルトでは、この「リターン・ルータビリティ・チェックは」実施すべきです。ピアは、（例えば、多くの企業の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のSAを更新する前に行うことができます。デフォルトでは、リターン・ルータビリティ・チェックは、IPsec SAを更新する前に行うべきであるが、一部の環境では、IPsec SAが更新された後まで延期されるかもしれません。
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.
どれINFORMATIONAL交換は、（このセクションで後述）一つの例外を除いて、リターン・ルータビリティの目的に使用することができます。有効な応答を受信したとき、私たちは、他の当事者が主張したアドレスにパケットを受信することができます知っています。
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.)
ピアが要求を見ることなく、正しいINFORMATIONAL応答を生成することができないことを確認するために、新しいペイロードは情報メッセージに追加されます。 INFORMATIONAL要求の送信者がCOOKIE2通知を含むことができ、含まれている場合、応答にそのまま、情報要求の受信者は、通知をコピーする必要があります。応答を処理するときに、元の送信者は、送信された値が同じものであることを確認しなければなりません。値が一致しない場合は、IKE_SAを閉じる必要があります。 （またCOOKIE2通知の形式については、セクション4.2.5を参照してください。）
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.
次のように前述の例外は次のとおりです。同じINFORMATIONAL要求があるアドレス情報提供応答が教えてくれない受信、（要求が最初に送られた後、すなわち、IKE_SAの宛先アドレスが更新された）いくつかの異なるアドレスに送信された場合作業1。この場合、新しいINFORMATIONAL要求は、リターン・ルータビリティをチェックするために送信する必要があります。
IKEv2 performs Dead Peer Detection (DPD) if there has recently been only outgoing traffic on all of the SAs associated with the IKE_SA.
最近IKE_SAに関連付けられたSAの全てにのみ発信トラフィックがあった場合のIKEv2はデッドピア検出（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マッピングが変更されているかどうかを検出するために使用することができます（例えば、キープアライブ間隔が長すぎる、または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_DETECTION_SOURCE_IPとNAT_DETECTION_DESTINATION_IP通知を使用して検出される）イニシエータがNATの背後にある場合、それはDPDメッセージにこれらの通知を含み、前UPDATE_SA_ADDRESSES応答から値（又はIKE_SA_INIT応答）で受信NAT_DETECTION_DESTINATION_IP通知を比較する必要があります。値が一致しない場合、応答者から見たIPアドレスおよび/またはポートが変更されていて、セクション3.5で説明したように、イニシエータはUPDATE_SA_ADDRESSESを送るべきです。イニシエータがNATマッピングが変更されたことを疑った場合、それはまた、検出ステップをスキップして、すぐにUPDATE_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.
IKE_SAがリキーされたときにNATマッピングの変更を検出したことに、このアプローチは、余分なアドレスの更新を引き起こす可能性があることに注意してください。 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を使用している場合、ピアアドレスとポートがわずかに異なる方法で最後の有効な認証パケット、仕事から更新される（セクション2.23、[IKEv2の]で指定された）動的更新、。ないNATの背後にあるホストは、IKEv2のパケットのためにこれらの動的更新を使用してはならないが、ESPパケットのためにそれらを使用するかもしれません。これはUPDATE_SA_ADDRESSESを含まないINFORMATIONAL交換は、特定のパスが動作するかどうかを試験、例えば、それがために使用されることを可能にする、任意の変更を引き起こさないことを保証します。
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.
基本のIKEv2 / IPsecのNATトラバーサルをサポートしていないトンネルモードで一対一の「基本」のNATとIPv4 / IPv6変換剤のいくつかのタイプで動作する可能性があります。 IKEv2の整合性チェックサムは、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アドレスを保護することで問題を解決します。これは、パスは、IPヘッダ内のアドレスを変更するNATはIPv4 / IPv6変換剤、または他のノードが含まれている場合、NATトラバーサルをサポートしていないMOBIKEが動作しないことを意味します。この機能は、主に、管理者がNATのが存在しないため、パケットへの変更は、攻撃と見なすことができることを事前に知っているかもしれないIPv6とサイト間VPNの場合、対象としています。
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のSAの（最初のIKE_AUTH要求し、次の通知のいずれかを含むすべての情報要求に関連するアドレスを更新することができ、すべてのメッセージが有効でない場合：UPDATE_SA_ADDRESSES、ADDITIONAL_IP4_ADDRESS、ADDITIONAL_IP6_ADDRESS、NO_ADDITIONAL_ADDRESSESを）またNO_NATS_ALLOWED通知を含まなければなりません。交換レスポンダはNO_NATS_ALLOWED通知の内容は、IPヘッダ内のアドレスと一致していることを確認しなければなりません。それらが一致しない場合は、UNEXPECTED_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.
交換イニシエータがその情報提供要求に応じてUNEXPECTED_NAT_DETECTED通知を受信した場合、それは新しいINFORMATIONAL要求を使用して操作を数回再試行する必要があります。イニシエータは、IKE_AUTH交換においてUNEXPECTED_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.
UNEXPECTED_NAT_DETECTED通知が送信されている場合は、交換レスポンダは、おそらくトラブルシューティングのための情報をログに記録するよりも、他の目的に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 INFORMATIONAL要求/応答メッセージを使用することができます。実装は、現在使用されているパスは、例えば、に取り組んでいる場合でも、テストパスを行い、より良い（しかし以前は利用できなかった）パスが利用可能になったときに検出することができます。
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と同じデッドピア検出方法を使用しますが、アドレスが変更される可能性として、それだけで相手が生きていることを確認するために十分ではないですが、また、それはアドレスの更新と同期していることと、例えば、無視されていませんリターンルータビリティテストを完了するために失敗に起因するアドレス更新。これは、着信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通知を含んでいた）対応する要求メッセージ内のアドレスの変更を行わなかったことを示すために、INFORMATIONAL交換応答でこの通知を含むことができます。
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.
UNACCEPTABLE_ADDRESSES用の通知メッセージタイプが40ザプロトコルID及びSPIサイズフィールドがゼロに設定されています。この通知タイプに関連付けられているデータはありません。
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.
UNEXPECTED_NAT_DETECTED用の通知メッセージタイプが41ザプロトコルID及びSPIサイズフィールドがゼロに設定されています。この通知タイプに関連付けられているデータはありません。
The MOBIKE_SUPPORTED notification is included in the IKE_AUTH exchange to indicate that the implementation supports this specification.
MOBIKE_SUPPORTED通知は実装がこの仕様をサポートしていることを示すために、IKE_AUTH交換に含まれています。
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のための通知メッセージタイプは、プロトコルIDとSPIサイズフィールドがゼロに設定されている16396.です。通知データフィールドは空のままにされなければならない（ゼロ長）この通知を受信したときに無視されなければならない（もしあれば）、その内容を送信するとき。これは、フィールドは、このプロトコルの将来のバージョンで使用することができます。
4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify Payloads
4.2.2. ADDITIONAL_IP4_ADDRESSとADDITIONAL_IP6_ADDRESS通知ペイロード
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交換や情報交換要求メッセージにADDITIONAL_IP4_ADDRESSおよび/またはADDITIONAL_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.
ADDITIONAL_IP4_ADDRESSとADDITIONAL_IP6_ADDRESSのためのメッセージタイプを通知し、それぞれ、16397および16398です。プロトコルIDとSPIサイズフィールドはゼロに設定されています。これらの通知タイプに関連付けられたデータは、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通知が交換イニシエータが交換に使用されるものを超えてアドレスを持っていないことを示すためにINFORMATIONAL交換要求メッセージに含まれることができる（より詳細な説明については、セクション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のための通知メッセージタイプは、プロトコルIDとSPIサイズフィールドがゼロに設定されている16399.です。この通知タイプに関連付けられているデータはありません。
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 SAのアドレスを更新するために、イニシエータによって送信さINFORMATIONAL交換要求に含まれている（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のための通知メッセージタイプは、プロトコルIDとSPIサイズフィールドがゼロに設定されている16400.です。この通知タイプに関連付けられているデータはありません。
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節を参照）リターン・ルータビリティチェックの目的で、任意の情報提供要求に含まれるかもしれません。 INFORMATIONAL要求はCOOKIE2が含まれている場合は、交換応答は、応答メッセージに通知をコピーする必要があります。
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オクテットでなければなりません、と交換レスポンダに予測不可能な方法で交換イニシエータによって選択されなければなりません。このメッセージの通知メッセージの種類は、プロトコルIDとSPIサイズフィールドがゼロに設定されている16401.です。
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:
このメッセージの通知メッセージタイプは、通知データは、パケットが送られたから/先のIPアドレスとポートが含まれてい16402.です。 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 SAのために使用される間違ったトンネルヘッダ（外側の）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トラバーサルを行っていない場合にのみ送信されます。この機能は、主に、管理者がNATのが存在しないことを事前に知っているかもしれないIPv6とサイト間VPNの場合、対象としています。
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 SAの種類を決定する際に、ピアの（外側の）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 SAの種類を決定する際のIKEv2によって使用される情報が含まれています。このプロセスは、セクション4.4.3、[IPsecArch]に記載されています。ピアが一部のトラフィックセレクタでのIPsec SAの作成を要求すると、PADが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 SAを作成する権限を意味するものではないことに注意することは重要です。しかし、いくつかの実装は、単にいくつかのアドレスXに到達可能ポリシーを使用することが知られているが、「到達可能」ここではアドレスXのためのIPsec SAを作成するための一時的な許可を意味し、通常はソースアドレスXでIPパケットを送信する（または詐称）する能力を意味しますそして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 SAを閉じるために必要かもしれない、これらの相互作用は、この文書の範囲を超えています。
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ピアの一つでもいずれでもよいです。初期のIKEv2交渉で行われる認証は、攻撃のための責任を負うことができる人にさかのぼることができるならば通常のVPNの使用シナリオでは、ピアによる攻撃は、容易に対応することができます。これは特に、セキュリティへの日和見的なアプローチで、すべてのシナリオの場合とできない場合があります。
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通知が含まれている場合も、リターン・ルータビリティチェックを兼ね生存性試験をトリガーします。
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ルータおよび近隣探索を保護する[SEND]の使用の検証としてスタックの他の部分に特定の技術の使用によって軽減することができます。
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アドレスの更新とADDITIONAL_IP4_ADDRESS / ADDITIONAL_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.
携帯電話接続および企業LANへの有線イーサネット接続：たとえば、2つのネットワークインタフェースを持つホストAを検討します。 IKEv2のを使用している場合はホストA今の連絡先ホストBとADDITIONAL_IP4_ADDRESS / ADDITIONAL_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.
これらの追加アドレスも1つだけのアドレスよりも、より正確な位置情報を開示することができます。特定のコーヒーショップの場所で無線LAN、ホストAは、IKEv2のトラフィック用のセルラー接続を使用していますが、また、に対応するIPアドレスを含むADDITIONAL_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ゲートウェイは、十分に信頼できる考えることができます。さらに、ADDITIONAL_IP4_ADDRESSとADDITIONAL_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、そのポリシーは常にローカルに設定された応答者のアドレスを使用することで任意のADDITIONAL_IP4_ADDRESS / ADDITIONAL_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の共同の努力です。私たちは、特にヤリArkko、のTuomasオーラ、マルセロBagnulo、ステファン・ボーリュー、エルウィン・デイヴィス、Lakshminath Dondeti、フランシスデュポン、ポール・ホフマン、ジェームズ・ケンプ、TERO Kivinen、ピートマッキャン、エリックNordmarkと、モハンパルタサラティ、ペッカSavola、ビルゾンマーフェルトに感謝したいと思います、モーリーンスティルマン、信太杉本、ハンネスTschofenig、およびサミVaarala。この文書はまた、[Kivinen]、[MOPO]、および[SMOBIKE]、およびMOBIKE設計書[デザイン]、[AddrMgmt]を含め、以前MOBIKEのようなプロトコルの提案からアイデアやテキストが組み込まれています。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[IPsecArch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPsecArch]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、「要件レベルを示すためにRFCsにおける使用のためのキーワード」、RFC 2119、1997年3月。
[AddrMgmt] Dupont, F., "Address Management for IKE version 2", Work in Progress, November 2005.
[AddrMgmt]デュポン、F.、 "IKEのバージョン2のためのアドレス管理"、進歩、2005年11月に作業。
[Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", Proc. 18th Annual Computer Security Applications Conference (ACSAC), December 2002.
[Aura02]オーラ、T.、卵、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におけるサードパーティの爆撃についての注意」、進歩、2005年12月に作業。
[Clarifications] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", Work in Progress, February 2006.
[明確化] Eronen、P.およびP.ホフマン、 "IKEv2の明確化および実装のガイドライン"、進歩、2006年2月に作業。
[DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
【DNA4] Aboba、B.、カールソン、J.、およびS.チェシャー、 "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]ナラヤナン、S.、デイリー、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プロトコルの設計"、進歩、2006年1月の作業。
[ICMPAttacks] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2005.
[ICMP攻撃]フォント、F.、 "TCPに対するICMP攻撃"、進歩、2005年10月に作業。
[Kivinen] Kivinen, T., "MOBIKE protocol", Work in Progress, February 2004.
[ロッキー]岩場、T.、 "モバイルプロトコル"、進歩、2004年2月に作業。
[MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[MIP4]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[MIP6]ジョンソン、D.、パーキンス、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-IKE）のためのモビリティプロトコル・オプション"、進歩、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.シンプソン、 "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.
[SEND] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（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.と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]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.、およびR.マーイ、 - 2003年3月、RFC 3489 "STUNネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサルは、翻訳者（NATのを）アドレス"。
[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月。
Appendix A. Implementation Considerations
付録A.実装に関する考慮事項
A.1. Links from SPD Cache to Outbound SAD Entries
A.1。 SADエントリをアウトバウンドするSPDキャッシュからのリンク
[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、「アウトバウンド処理の場合、各SADエントリは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間のリンクは、アウトバウンドパケットは右のSAを介して送信されることを保証するために正確に行わなければならないことは明らかです。いくつかの実装では、この分野での問題があることが知られています。
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.
具体的には、単に保存（リモートトンネルヘッダのIPアドレスを、リモートSPI）SPDキャッシュ内のペアは、ペアが常に一意に単一のSADエントリを識別しないので、不十分です。例えば、同じNATの背後にある二つのホストは、偶然同じSPI値を選択することが起こる可能性があります。ホストが以前にいくつかの他のホストが使用するIPアドレスが割り当てられ、古いホストに関連付けられているSAがまだデッドピア検出によって削除されていないときの状況が発生することもあります。これは、キー管理デーモンは、そうでない場合は、有効な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.
アドレスは、SAの存続期間中に変更することができるので、SPDキャッシュにリモートトンネルヘッダのIPアドレスを格納することも、MOBIKEの実装を複雑にすることができます。したがって、我々は、SPDキャッシュおよびトンネルヘッダのIPアドレスがMOBIKEにより更新されたときに変更を必要としない方法で、SAD間のリンクを実装することをお勧めします。
A.2. Creating Outbound SAs
A.2。アウトバウンドSAを作成します
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]及びAしかしながらIKEピアなるXのアドレスにIKE交換を可能にするために、PADに登録する必要がありXのための推定代表としてが接触任意のピアを決定する方法を指定しない本書認証されます。認証されたピアは、そのトラフィックセレクタ交換にXを表すことをアサートする。また、PADは、当該ピアが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アドレスを決定するために、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アドレスは常に一意なぜリモートIPアドレスの組み合わせと同じ理由のために、単一のIKEピアを（特定していないこと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
パシEronen（編集）、ノキア・リサーチセンター私書箱ボックス407 FIN-00045 Nokiaのグループフィンランド
EMail: pasi.eronen@nokia.com
メールアドレス：pasi.eronen@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。