RFC4555 日本語訳
4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE). P. Eronen. June 2006. (Format: TXT=78698 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Eronen, Ed. Request for Comments: 4555 Nokia Category: Standards Track June 2006
ワーキンググループP.Eronen、エドをネットワークでつないでください。コメントのために以下を要求してください。 4555年のノキアカテゴリ: 標準化過程2006年6月
IKEv2 Mobility and Multihoming Protocol (MOBIKE)
IKEv2の移動性とマルチホーミングプロトコル(MOBIKE)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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に関連しているIPアドレスとトンネルモードIPsec Security Associationsを変えさせます。 可動のVirtual兵士のNetwork(VPN)クライアントは、VPNゲートウェイがアクティブな状態で1つのアドレスから別のアドレスまで動いている間、接続を保つのにMOBIKEを使用できました。 同様に、例えば、現在使用されるのが仕事を中止するなら、「マルチ-家へ帰」っているホストは、交通を異なったインタフェースに動かすのにMOBIKEを使用するかもしれません。
Eronen Standards Track [Page 1] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[1ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 動機. . . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 範囲と制限. . . . . . . . . . . . . . . . . . 4 1.3。 用語と記法. . . . . . . . . . . . . . . . . 4 2。 概観. . . . . . . . . . . . . . . . . . . . . . 5 2.1について議定書の中で述べてください。 基本的な操作. . . . . . . . . . . . . . . . . . . . . 5 2.2。 例のプロトコルは.62.3を交換します。 MOBIKEとネットワークは翻訳(NAT). . . . . . . 9 3を記述します。 交換. . . . . . . . . . . . . . . . . . . . . . 10 3.1について議定書の中で述べてください。 IKE交換. . . . . . . . . . . . . . . . . . . 10 3.2に頭文字をつけてください。 MOBIKE. . . . . . . . . . . . . . . 10 3.3のサポートに合図します。 トンネルヘッダーアドレス. . . . . . . . . . . . . 11 3.4に頭文字をつけてください。 追加アドレス. . . . . . . . . . . . . . . . . . . 11 3.5。 IPsec SAs. . . . . . . . . . . . . 12 3.6のアドレスを変えます。 追加アドレス. . . . . . . . . . . . . . 15 3.7をアップデートします。 チェック. . . . . . . . . . . . . . . . . 17 3.8をRoutabilityに返してください。 NATマッピング. . . . . . . . . . . . . . . . . 18 3.9における変化。 NAT禁止. . . . . . . . . . . . . . . . . . . . . 19 3.10。 経路テスト. . . . . . . . . . . . . . . . . . . . . . . 20 3.11。 失敗回復とタイムアウト. . . . . . . . . . . . . . 20 3.12。 死んでいる同輩検出. . . . . . . . . . . . . . . . . . . 20 4。 有効搭載量は.214.1をフォーマットします。 メッセージに通知してください--誤りは.214.2をタイプします。 メッセージに通知してください--状態は.215をタイプします。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 24 5.1。 交通リダイレクションとハイジャック. . . . . . . . . . . . 24 5.2。 IPsec有効搭載量保護. . . . . . . . . . . . . . . . . 24 5.3。 第三者. . . . . 25 5.4に対するサービス不能攻撃。 ネットワークの接続性指摘. . . . . . . . 26 5.5をだまします。 アドレスとトポロジー公開. . . . . . . . . . . . . 27 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 28 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 29 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 29 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 29付録A.実現問題. . . . . . . . . . . . 31A.1。 SPDからのリンクは外国行きの悲しいエントリーに.31A.2をキャッシュします。 外国行きのSAs. . . . . . . . . . . . . . . . . . 31を作成します。
Eronen Standards Track [Page 2] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[2ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
1. Introduction
1. 序論
1.1. Motivation
1.1. 動機
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 Security Associations(SAs)を設立して、維持することと同様に互いの認証を実行するのに使用されます。 ベースIKEv2プロトコル[IKEv2]では、IKE SAsとトンネルモードIPsec SAsはIKE_SAが設立されるとき使用されたIPアドレスの間でそれとなく作成されます。 そして、これらのIPアドレスはトンネルモードIPsecパケットに外側(トンネルヘッダー)のアドレスとして使用されます(交通機関IPsec SAsはこのドキュメントの範囲を超えています)。 現在、IKE_SAが作成された後にこれらのアドレスを変えるのは可能ではありません。
There are scenarios where these IP addresses might change. One example is mobility: a host changes its point of network attachment and receives a new IP address. Another example is a multihoming host that would like to change to a different interface if, for instance, the currently used interface stops working for some reason.
シナリオがこれらのIPアドレスが変化するかもしれないところにあります。 1つの例が移動性です: ホストは、ネットワーク付属のポイントを変えて、新しいIPアドレスを受け取ります。 別の例は例えば、現在中古のインタフェースがある理由で仕事を中止するかどうかを異なったインタフェースに変えたがっているマルチホーミングホストです。
Although the problem can be solved by creating new IKE and IPsec SAs when the addresses need to be changed, this may not be optimal for several reasons. In some cases, creating a new IKE_SA may require user interaction for authentication, such as entering a code from a token card. Creating new SAs often involves expensive calculations and possibly a large number of round-trips. For these reasons, a mechanism for updating the IP addresses of existing IKE and IPsec SAs is needed. The MOBIKE protocol described in this document provides such a mechanism.
アドレスが、変えられる必要があると新しいIKEとIPsec SAsを作成することによって、問題を解決できますが、これはいくつかの理由で最適でないかもしれません。 いくつかの場合、新しいIKE_SAを作成するのは認証のためにユーザ相互作用を必要とするかもしれません、トークン・カードからコードを入れるのなどように。 新しいSAsを作成すると、高価な計算とことによると多くの周遊旅行がしばしばかかわります。 これらの理由で、既存のIKEとIPsec SAsのIPアドレスをアップデートするためのメカニズムが必要です。 本書では説明されたMOBIKEプロトコルはそのようなメカニズムを提供します。
The main scenario for MOBIKE is enabling a remote access VPN user to move from one address to another without re-establishing all security associations with the VPN gateway. For instance, a user could start from fixed Ethernet in the office and then disconnect the laptop and move to the office's wireless LAN. When the user leaves the office, the laptop could start using General Packet Radio Service (GPRS); when the user arrives home, the laptop could switch to the home wireless LAN. MOBIKE updates only the outer (tunnel header) addresses of IPsec SAs, and the addresses and other traffic selectors used inside the tunnel stay unchanged. Thus, mobility can be (mostly) invisible to applications and their connections using the VPN.
MOBIKEに、主なシナリオは、遠隔アクセスのVPNユーザが1つのアドレスから別のアドレスまでVPNゲートウェイとのすべてのセキュリティ協会を復職させるというわけではなくて移るのを可能にしています。 例えば、ユーザは、オフィスで固定イーサネットから始めて、次に、ラップトップを外して、オフィスの無線LANに移ることができました。 ユーザが退庁するとき、ラップトップは、汎用パケット無線システム(GPRS)を使用し始めるかもしれません。 ユーザが家に着くとき、ラップトップは家の無線LANに切り替わることができました。 MOBIKEはIPsec SAsの外側(トンネルヘッダー)のアドレスだけをアップデートします、そして、トンネルの中で使用されたアドレスと他の交通セレクタは変わりがない状態で残っています。 したがって、アプリケーションと彼らの接続には、移動性は、VPNを使用することで(ほとんど)目に見えない場合があります。
Eronen Standards Track [Page 3] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[3ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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ゲートウェイであるかもしれません。
1.2. Scope and Limitations
1.2. 範囲と制限
This document focuses on the main scenario outlined above and supports only tunnel mode IPsec SAs.
このドキュメントは、上に概説された主なシナリオに焦点を合わせて、トンネルモードだけIPsec SAsを支持します。
The mobility support in MOBIKE allows both parties to move, but does not provide a "rendezvous" mechanism that would allow simultaneous movement of both parties or discovery of the addresses when the IKE_SA is first established. Therefore, MOBIKE is best suited for situations where the address of at least one endpoint is relatively stable and can be discovered using existing mechanisms such as DNS (see Section 3.1).
MOBIKEでの移動性サポートで、動きますが、双方はIKE_SAが最初に設立されるとき双方の同時の運動かアドレスの発見を許す「ランデブー」メカニズムを提供しません。 したがって、MOBIKEは少なくとも1つの終点のアドレスが比較的安定している状況に合うのが最も良く、DNSなどの既存のメカニズムを使用することで発見できます(セクション3.1を見てください)。
MOBIKE allows both parties to be multihomed; however, only one pair of addresses is used for an SA at a time. In particular, load balancing is beyond the scope of this specification.
MOBIKEは、双方が「マルチ-家へ帰」るのを許容します。 しかしながら、1組のアドレスだけが一度に、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.
ネットワークAddress Translators(NATs)は上に記載されたものを超えて追加制限を導入します。 詳細について、セクション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デザインドキュメント[デザイン]に相談してください。
1.3. Terminology and Notation
1.3. 用語と記法
When messages containing IKEv2 payloads are described, optional payloads are shown in brackets (for instance, "[FOO]"), and a plus sign indicates that a payload can be repeated one or more times (for instance, "FOO+"). To provide context, some diagrams also show what existing IKEv2 payloads would typically be included in the exchanges. These payloads are shown for illustrative purposes only; see [IKEv2] for an authoritative description.
IKEv2ペイロードを含むメッセージが説明されるとき、任意のペイロードは括弧(例えば、「[FOO]」)に示されます、そして、プラスサインは1回(例えば、「FOO+」)以上ペイロードを繰り返すことができるのを示します。 また、文脈を提供するために、いくつかのダイヤグラムが、どんな既存のIKEv2ペイロードが交換に通常含まれているかを示します。 これらのペイロードは説明に役立った目的だけのために見せられます。 正式の記述に関して[IKEv2]を見てください。
Eronen Standards Track [Page 4] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[4ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
When this document describes updating the source/destination addresses of an IPsec SA, it means updating IPsec-related state so that outgoing Encapsulating Security Payload (ESP)/Authentication Header (AH) packets use those addresses in the tunnel header. Depending on how the nominal divisions between Security Association Database (SAD), Security Policy Database (SPD), and Peer Authorization Database (PAD) described in [IPsecArch] are actually implemented, an implementation can have several different places that have to be updated.
このドキュメントが、IPsec SAのソース/送付先アドレスをアップデートすると説明するとき、IPsec関連の状態をアップデートすることを意味するので、外向的なEncapsulating Security有効搭載量(超能力)/認証Header(AH)パケットはトンネルヘッダーでそれらのアドレスを使用します。 [IPsecArch]で説明されたSecurity Association Database(SAD)と、Security Policy Database(SPD)と、Peer Authorization Database(PAD)の間の名目上の部門が実際にどう実行されるかによって、実現はアップデートされなければならないいくつかの異なった場所を持つことができます。
In this document, the term "initiator" means the party who originally initiated the first IKE_SA (in a series of possibly several rekeyed IKE_SAs); "responder" is the other peer. During the lifetime of the IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA exchanges; in this case, the terms "exchange initiator" and "exchange responder" are used. The term "original initiator" (which in [IKEv2] refers to the party who started the latest IKE_SA rekeying) is not used in this document.
本書では、「創始者」という用語は元々最初のIKE_SA(一連のことによると数個のrekeyed IKE_SAsの)を開始したパーティーを意味します。 「応答者」はもう片方の同輩です。 IKE_SAの生涯、双方はINFORMATIONALかCREATE_CHILD_SA交換を起こすかもしれません。 この場合、期間「交換創始者」と「交換応答者」は使用されています。 「オリジナルの創始者」([IKEv2]で最新のIKE_SA rekeyingを始動したパーティーについて言及する)という用語は本書では使用されません。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[キーワード]で説明されるように本書では解釈されることであるべきですか?
2. Protocol Overview
2. プロトコル概観
2.1. Basic Operation
2.1. 基本的な操作
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次第です。 これらの組のどれを使用したらよいかに関する決定はいくつかの要素を考慮に入れなければなりません。 まず最初に、パーティーは、どのインタフェースが例えば、性能のために使用されているべきであるかに関して好みを持って、理由かかるかもしれません。 2番目に、いくつかの組が両立しないIPバージョン、ネットワークにおける供給停止、地方のリンクの問題のためどちらかの終わり、などに全く働かないかもしれないという事実によって決定は抑制されます。
MOBIKE solves this problem by taking a simple approach: the party that initiated the IKE_SA (the "client" in a remote access VPN scenario) is responsible for deciding which address pair is used for the IPsec SAs and for collecting the information it needs to make this decision (such as determining which address pairs work or do not work). The other party (the "gateway" in a remote access VPN scenario) simply tells the initiator what addresses it has, but does not update the IPsec SAs until it receives a message from the initiator to do so. This approach applies to the addresses in the IPsec SAs; in the IKE_SA case, the exchange initiator can decide which addresses are used.
MOBIKEは簡潔な解決法を取ることによって、この問題を解決します: IKE_SA(遠隔アクセスのVPNシナリオの「クライアント」)を開始したパーティーはどのアドレス組がIPsec SAsに使用されるかを決めて、それがこの決定をするように必要とする情報を集めるのに(どのアドレス組が働いているか、または働いていないかを決定などなどの)責任があります。 相手(遠隔アクセスのVPNシナリオの「ゲートウェイ」)は、それがどんなアドレスを持っているかを単に創始者に言いますが、そうするために創始者からメッセージを受け取るまで、IPsec SAsをアップデートしません。 このアプローチはIPsec SAsのアドレスに適用されます。 IKE_SA場合では、交換創始者は、どのアドレスが使用されているかを決めることができます。
Eronen Standards Track [Page 5] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[5ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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]などの移動性プロトコルについて一般的です。 多くのメカニズムが、既に存在しているか、またはこれらの問題に対処するために開発されています。 例えば、地方のリンク[RFC2461]の中に接続性の状態を追跡するのにリンクレイヤとIP-層のメカニズムを使用できます。 動き検出は[DNA4]、[DNA6]などにおける、IPv4とIPv6の両方に指定されています。
Naturally, updating the addresses of IPsec SAs has to take into account several security considerations. MOBIKE includes two features designed to address these considerations. First, a "return routability" check can be used to verify the addresses provided by the peer. This makes it more difficult to flood third parties with large amounts of traffic. Second, a "NAT prohibition" feature ensures that IP addresses have not been modified by NATs, IPv4/IPv6 translation agents, or other similar devices. This feature is enabled only when NAT Traversal is not used.
当然、IPsec SAsのアドレスをアップデートすると、いくつかのセキュリティ問題が考慮に入れられなければなりません。 MOBIKEはこれらの問題を記述するように設計された2つの特徴を含んでいます。 まず最初に、同輩によって提供されたアドレスについて確かめるのに「リターンroutability」チェックを使用できます。 これで、多量の交通で第三者をあふれさせるのは、より難しくなります。 2番目に、「NAT禁止」の特徴は、IPアドレスがNATs、IPv4/IPv6翻訳エージェント、または他の同様の装置によって変更されていないのを確実にします。 NAT Traversalが使用されていないときだけ、この特徴は可能にされます。
2.2. Example Protocol Exchanges
2.2. 例のプロトコル交換
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アドレスを表します。
Eronen Standards Track [Page 6] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[6ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
Initiator Responder
----------- -----------
1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
創始者応答者----------- ----------- 1) (IP_I1: 500->IP_R1: 500) HDR、SAi1、KEi、Ni、N(_NAT_検出_ソースIP)、N(_NAT_の検出_目的地IP) -->。
<-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
<--HDR、SAr1、KEr、Nr、N(_NAT_検出_ソースIP)、(IP_R1: 500->IP_I1: 500)N(_NAT_の検出_目的地IP)
2) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } -->
2) (4500->IP_R1: IP_I1:4500) HDR、SK、IDi、本命、AUTH、CP(CFG_要求)、SAi2、TSi、TSr、N(支持されたMOBIKE_)--、>。
<-- (IP_R1:4500 -> IP_I1:4500)
HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY),
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED) }
<--HDR、(IP_R1: 4500->IP_I1: 4500)SKIDr、本命、AUTH、CP(CFG_回答)、SAr2、TSi、TSr、N(支持されたMOBIKE_)
(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) (4500->IP_R1: IP_I2:4500) HDR、SK、N(アップデート_SA_アドレス)、N(_NAT_検出_ソースIP)、N(_NAT_の検出_目的地IP)--、>。
<-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
<--HDR、(IP_R1: 4500->IP_I2: 4500)SKN(_NAT_検出_ソースIP)、N(_NAT_の検出_目的地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) <-- (4500->IP_I2: IP_R1:4500) HDR、SKN(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
ステップ1は通常のイケ_INIT交換です。 ステップ2では、同輩は、彼らがMOBIKEを支持することを互いに知らせます。 ステップ3では、創始者は、それ自身のアドレスにおける変化に気付いて、応答者に受け取ったことを知らせさせます。
Eronen Standards Track [Page 7] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[7ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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.
UPDATE_SA_ADDRESSES通知を含むINFORMATIONAL要求を送るのによるこれ。 要求に新しいIPアドレスを使用させます。 また、ここに、それはソースアドレスとしてそれ自身の外向的な超能力交通で新しいアドレスを使用し始めます。 UPDATE_SA_ADDRESSES通知を受け取ると、応答者は、新しいアドレスを記録して、それが方針によって必要とされるなら、アドレスのリターンroutabilityチェックを実行します。 (ステップ4)が終了するこのチェック、外向的な超能力交通に目的地として新しいアドレスを使用する応答者始めであるときに。
Another protocol run in a multihoming scenario is illustrated below. In this scenario, the initiator has one address but the responder has two.
別のプロトコルはシナリオが例証されるマルチホーミングに立候補します。 このシナリオでは、創始者は1つのアドレスを持っていますが、応答者には、2があります。
Initiator Responder
----------- -----------
1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
創始者応答者----------- ----------- 1) (IP_I1: 500->IP_R1: 500) HDR、SAi1、KEi、Ni、N(_NAT_検出_ソースIP)、N(_NAT_の検出_目的地IP) -->。
<-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
<--HDR、SAr1、KEr、Nr、N(_NAT_検出_ソースIP)、(IP_R1: 500->IP_I1: 500)N(_NAT_の検出_目的地IP)
2) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } -->
2) (4500->IP_R1: IP_I1:4500) HDR、SK、IDi、本命、AUTH、CP(CFG_要求)、SAi2、TSi、TSr、N(支持されたMOBIKE_)--、>。
<-- (IP_R1:4500 -> IP_I1:4500)
HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY),
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED),
N(ADDITIONAL_IP4_ADDRESS) }
<--HDR、(IP_R1: 4500->IP_I1: 4500)SKIDr、本命、AUTH、CP(CFG_回答)、SAr2、TSi、TSr、N(支持されたMOBIKE_)、N(追加_IP4_アドレス)
(The initiator suspects a problem in the currently used address pair and probes its liveness.)
(創始者は、現在中古のアドレス組で問題を疑って、活性を調べます。)
Eronen Standards Track [Page 8] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[8ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
3) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
3) (4500->IP_R1: IP_I1:4500) HDR、SK、N(_NAT_検出_ソースIP)、N(_NAT_の検出_目的地IP)--、>。
(IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
HDR、(IP_I1: 4500->IP_R1: 4500)SK、N(_NAT_検出_ソースIP)、N(_NAT_の検出_目的地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) (4500->IP_R2: IP_I1:4500) HDR、SKN(_NAT_検出_ソースIP)、N(_NAT_の検出_目的地IP)
<-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
<--HDR、(IP_R2: 4500->IP_I1: 4500)SKN(_NAT_検出_ソースIP)、N(_NAT_の検出_目的地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) (4500->IP_R2: IP_I1:4500) HDR、SK、N(アップデート_SA_アドレス)、N(_NAT_検出_ソースIP)、N(_NAT_の検出_目的地IP)、N(COOKIE2)--、>。
<-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) }
<--HDR、(IP_R2: 4500->IP_I1: 4500)SKN(_NAT_検出_ソースIP)、N(_NAT_の検出_目的地IP)、N(COOKIE2)
2.3. MOBIKE and Network Address Translation (NAT)
2.3. MOBIKEとネットワークアドレス変換(NAT)
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シナリオでは、ネットワークは、NATsを含んでいるか、またはパケットフィルタをstatefulするかもしれません(簡潔さのために、このドキュメントの残りは単にNATsについて説明します)。 多くの場合、IKEv2は[IKEv2]で指定されたNAT Traversal機能でNATsを終えることができます、そして、MOBIKEはこの機能性に投機できます: IPsec SAsに使用されるアドレスを変えるとき、MOBIKEは必要であるようにIKEv2NAT Traversalを有効にするか、または無効にすることができます。
Nevertheless, there are some limitations because NATs usually introduce an asymmetry into the network: only packets coming from the "inside" cause state to be created. This asymmetry leads to
それにもかかわらず、NATsが通常ネットワークに非対称を取り入れるので、いくつかの制限があります: “inside"から来るパケットだけで、状態を創設します。 この非対称は通じます。
Eronen Standards Track [Page 9] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[9ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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).
MOBIKEができることが制限。 具体的な例を示すには、両方の同輩にただ一つのアドレスしかなくて、創始者がNATの後ろにいる状況を考えてください。 応答者のアドレスが現在変化するなら、それは、新しいアドレスを使用することでパケットを創始者に送る必要があります。 しかしながら、例えば、一般的な「制限された円錐」タイプ(異なったNATの1つの記述のための[STUN]がタイプするのを見る)にNATがあるなら、これは可能ではありません。 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は、NATsが存在しているなら、創始者がパーティー“behind"であると仮定します。NAT、および応答者のアドレス変化が完全に支持されるというわけではないケース(どんな特別な努力もこの機能性を支持するためにされない意味)。 また、応答者も彼らがいるNATsのNATsか特定のタイプに気づかないかもしれません。 しかしながら、接続性の損失をもたらす変化が起こったとき、それでも、MOBIKE応答者は、変化について創始者に知らせるのを試みるでしょう。 例えば、正確なタイプのNATによって、それは成功するかもしれません。 しかしながら、これが働くか、または働かない場合、正確な事情は本書では分析されません。
3. Protocol Exchanges
3. プロトコル交換
3.1. Initial IKE Exchange
3.1. 初期のIKE交換
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.
同輩のどちらかか両方に複数のアドレスがあるなら、いくつかの組み合わせは働かないかもしれません。 INITが要求するイケ_SA_を再送するとき、したがって、創始者SHOULDは様々なソースと送付先アドレス組み合わせを試みます。
3.2. Signaling Support for MOBIKE
3.2. MOBIKEのシグナリングサポート
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).
特定のイケ_SA MUSTにMOBIKEを使用したがっている実現がイケ_AUTH交換(SAペイロードを含むメッセージにおける複数のイケ_AUTH交換の場合の)におけるMOBIKE_SUPPORTED通知を含んでいます。
Eronen Standards Track [Page 10] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[10ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
The format of the MOBIKE_SUPPORTED notification is described in Section 4.
MOBIKE_SUPPORTED通知の形式はセクション4で説明されます。
3.3. Initial Tunnel Header Addresses
3.3. 初期のトンネルヘッダーアドレス
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にカプセル化をします) IPsec SAを要求するIKEv2メッセージのIPヘッダーではなく、IKE_SAから、取ります。 IKE_SAのアドレスは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がポートから500〜4500に釣り銭がいるので、AUTHが要求するイケ_からアドレスを取ります。 ものを簡素化するために、この仕様とNAT Traversalの両方を支持する実現は、また、通信員が両方を支持するかどうかをポート4500に変えなければなりません、NATが全くそれらの間に検出されなかったとしても(この道、NATがある他の経路に検出されるなら、後でポートを変える必要は全くありません)。
3.4. Additional Addresses
3.4. 追加アドレス
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.
ともに、創始者と応答者はイケ_AUTHのIP4_ADDRESS、そして/または、ADDITIONAL_IP6_ADDRESS通知が交換する(SAペイロードを含むメッセージにおける複数のイケ_AUTH交換の場合に)1ADDITIONAL_を入れるかもしれません。 ここで、「追加_*_アドレス」は追加_IP4_アドレスか追加_IP6_アドレス通知のどちらかを意味します。
Initiator Responder
----------- -----------
HDR, SK { IDi, [CERT], [IDr], AUTH,
[CP(CFG_REQUEST)]
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_*_ADDRESS)+] } -->
創始者応答者----------- ----------- HDR、SK、IDi、[本命]、[IDr]、AUTH、SAi2、TSi、TSr、[CP(CFG_要求)]N(支持されたMOBIKE_)[N(追加_*_アドレス)+]--、>。
<-- HDR, SK { IDr, [CERT], AUTH,
[CP(CFG_REPLY)],
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED)
[N(ADDITIONAL_*_ADDRESS)+] }
<--HDR、SKIDr、[本命]、AUTH、[CP(CFG_回答)]、SAr2、TSi、TSr、N(支持されたMOBIKE_)[N(追加_*_アドレス)+]
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に論理的に関連する)であるのに1セットの同輩アドレスを維持して、わずかに異なった目的にこの情報を使用することに注意するのは重要です。
Eronen Standards Track [Page 11] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[11ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
The initiator uses the set of responder addresses as an input to its address selection policy; it may, at some later point, decide to move the IPsec traffic to one of these addresses using the procedure described in Section 3.5. The responder normally does not use the set of initiator addresses for anything: the addresses are used only when the responder's own addresses change (see Section 3.6).
創始者は入力として応答者アドレスのセットをアドレス選択方針に使用します。 何らかの後のポイントでは、それは、セクション3.5で説明された手順を用いることでIPsec交通をこれらのアドレスの1つに動かすと決めるかもしれません。 通常、応答者は何にも創始者アドレスのセットを使用しません: 応答者の自己のアドレスが変化するときだけ(セクション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で説明された応答者アドレスを変えるための手順が完全に働くというわけではないことを意味します。 同じくらいに関しては、理由、同輩SHOULD NOTも何がそれをアップデートするこのドキュメントか将来の仕様で明らかに説明されるかよりいかなる他の目的にもこの情報を使用します。
3.5. Changing Addresses in IPsec SAs
3.5. IPsec SAsのアドレスを変えます。
In MOBIKE, the initiator decides what addresses are used in the IPsec SAs. That is, the responder does not normally update any IPsec SAs without receiving an explicit UPDATE_SA_ADDRESSES request from the initiator. (As described below, the responder can, however, update the IKE_SA in some circumstances.)
MOBIKEでは、創始者は、どんなアドレスがIPsec SAsで使用されるかを決めます。 SA_ADDRESSESが創始者から要求する明白なUPDATE_を受けないで、通常、すなわち、応答者は少しのIPsec SAsもアップデートしません。 (しかしながら、以下で説明されるように、応答者はいくつかの事情でIKE_SAをアップデートできます。)
The reasons why the initiator wishes to change the addresses are largely beyond the scope of MOBIKE. Typically, triggers include information received from lower layers, such as changes in IP addresses or link-down indications. Some of this information can be unreliable: for instance, ICMP messages could be spoofed by an attacker. Unreliable information SHOULD be treated only as a hint that there might be a problem, and the initiator SHOULD trigger Dead Peer Detection (that is, send an INFORMATIONAL request) to determine if the current path is still usable.
創始者がアドレスを変えたがっている理由は主にMOBIKEの範囲を超えています。 通常、引き金はIPアドレスの変化などの下層か下にリンクする指摘から受け取られた情報を含んでいます。 この情報のいくつかがあてにならない場合があります: 例えば、攻撃者はICMPメッセージをだますことができました。 不確かな情報SHOULD、単に問題があるかもしれないというヒント、および創始者SHOULD引き金のDead Peer Detection(すなわち、INFORMATIONAL要求を送る)として扱われて、現在の経路がまだ使用可能であるかどうか決定してください。
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要求を再送しましたが、どんな有効な回答も受け取っていません。 これは、現在の経路がもう働いていないのを示します。
Eronen Standards Track [Page 12] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[12ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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_IP6_ADDRESSを含んでいますが、ADDITIONAL_IP4_ADDRESS、どんな_ADDITIONALも含んでいなくて、ADDRESSES通知が受信されているというINFORMATIONAL要求。 これは、同輩のアドレスが変化したかもしれないことを意味します。 発表されたセットのアドレスがもう現在中古のアドレスを含んでいないなら、これは特に重要です。
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応答に合っていないNAT_DETECTION_DESTINATION_IP通知を受け取ります(より詳細な記述に関してセクション3.8を見てください)。
The description in the rest of this section assumes that the initiator has already decided what the new addresses should be. When this decision has been made, the initiator:
このセクションの残りにおける記述は、創始者が、新しいアドレスが何であるべきであるかを既に決めたと仮定します。 この決定をしたとき創始者:
o Updates the IKE_SA with the new addresses, and sets the
"pending_update" flag in the IKE_SA.
o 新しいアドレスでIKE_SAをアップデートして、IKE_SAに「未定の_アップデート」旗を設定します。
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 SAsが新しいアドレス(IPsec SAsをアップデートする前に、創始者の方針がリターンroutabilityチェックを必要として、この応答者アドレスのためにまだチェックしている場合)でこのIKE_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).
o 前のステップでIPsec SAsをアップデートしたなら: NAT Traversalが有効にされないで、応答者がNAT Traversalを支持して(NAT検出ペイロードによってイケ_SA_INIT交換で示されるように)、創始者がNATが存在している傾向があることを疑うか、または知って、NAT Traversal(すなわち、出発している超能力パケットのUDPカプセル化とNAT Keepaliveパケットの発信を可能にする)を有効にするなら。
o If there are outstanding IKEv2 requests (requests for which the
initiator has not yet received a reply), continues retransmitting
them using the addresses in the IKE_SA (the new addresses).
o あれば、傑出しているIKEv2は、(創始者がまだ回答を受け取っていない要求)を要求して、IKE_SA(新しいアドレス)のアドレスを使用することでそれらを再送し続けています。
o When the window size allows, sends an INFORMATIONAL request
containing the UPDATE_SA_ADDRESSES notification (which does not
contain any data), and clears the "pending_update" flag. The
request will be as follows:
o いつ、ウィンドウサイズが許容するか、UPDATE_SA_ADDRESSES通知(少しのデータも含まない)を含むINFORMATIONAL要求を送って、「未定の_アップデート」旗をきれいにします。 要求は以下の通りになるでしょう:
Eronen Standards Track [Page 13] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[13ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
Initiator Responder
----------- -----------
HDR, SK { N(UPDATE_SA_ADDRESSES),
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->
創始者応答者----------- ----------- HDR、SK、N、(アップデート_SA_アドレス)、[N(_NAT_検出_ソースIP)、N(_NAT_の検出_目的地IP)][N(NATS_が許容しなかった_全く)]、[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 新しい..アドレス..変化..起こる..待つ..応答..始め..再び..第一歩..そして..無視..応答..要求
When processing an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification, the responder:
UPDATE_SA_ADDRESSES通知、応答者を含むINFORMATIONAL要求を処理するとき:
o Determines whether it has already received a newer
UPDATE_SA_ADDRESSES request than this one (if the responder uses a
window size greater than one, it is possible that requests are
received out of order). If it has, a normal response message
(described below) is sent, but no other action is taken.
o それが既にこれより新しいUPDATE_SA_ADDRESSES要求を受け取った(応答者がウィンドウサイズ1以上を使用するなら、故障していた状態で要求を受け取るのは可能です)か否かに関係なく、決定します。 それがそうしたなら、正常な応答メッセージ(以下で、説明される)を送りますが、他の行動を全く取りません。
o If the NO_NATS_ALLOWED notification is present, processes it as
described in Section 3.9.
o いいえ_NATS_ALLOWED通知がセクション3.9で説明されるように存在していて、それを処理するなら。
o Checks that the (source IP address, destination IP address) pair
in the IP header is acceptable according to local policy. If it
is not, replies with a message containing the
UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2).
o ローカルの方針によると、IPヘッダーという(ソースIPアドレス、送付先IPアドレス)組が許容できるのをチェックします。 それがないなら、メッセージがUNACCEPTABLE_ADDRESSES通知(そして、ことによるとCOOKIE2)を含んでいて、回答します。
o Updates the IP addresses in the IKE_SA with the values from the IP
header. (Using the address from the IP header is consistent with
normal IKEv2, and allows IKEv2 to work with NATs without needing
unilateral self-address fixing [UNSAF].)
o IPがIKE_SAに値でIPヘッダーから記述するアップデート。 (IPヘッダーからのアドレスを使用するのは、正常なIKEv2と一致していて、IKEv2がNATsと共に[UNSAF]を修理しながら一方的な自己アドレスを必要としないで働いているのを許容します。)
o Replies with an INFORMATIONAL response:
o INFORMATIONAL応答による回答:
Initiator Responder
----------- -----------
<-- HDR, SK { [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[N(COOKIE2)] }
創始者応答者----------- ----------- <-- HDR、SK[N(_NAT_検出_ソースIP)、N(_NAT_の検出_目的地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 必要ならチェックが終了するまで、リターンroutabilityが新しい創始者アドレス(セクション3.7を見る)がないかどうかチェックして、待つ開始。
o Updates the IPsec SAs associated with this IKE_SA with the new
addresses.
o IPsec SAsが新しいアドレスでこのIKE_SAに関連づけたアップデート。
Eronen Standards Track [Page 14] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[14ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
o If NAT Traversal is supported and NAT detection payloads were
included, enables or disables NAT Traversal.
o NAT TraversalがNAT Traversalを支持されるのと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 最初に要求を送った後にアドレス変化が起こったなら、MOBIKEではありません処理が新しい_UPDATE_SA ADDRESSESを送るので(または、既に、ウィンドウサイズ1以上が使用中であるなら、送りました)応答メッセージのためにされる。
o If the response contains the UNEXPECTED_NAT_DETECTED notification,
the initiator processes the response as described in Section 3.9.
o 応答がUNEXPECTED_NAT_DETECTED通知を含んでいるなら、創始者はセクション3.9で説明されるように応答を処理します。
o If the response contains an UNACCEPTABLE_ADDRESSES notification,
the initiator MAY select another addresses and retry the exchange,
keep on using the previously used addresses, or disconnect.
o 応答がUNACCEPTABLE_ADDRESSES通知を含んでいるなら、創始者は、別のアドレスを選択して、交換を再試行するか、以前中古のアドレスを使用し続けるか、または連絡を断つかもしれません。
o It updates the IPsec SAs associated with this IKE_SA with the new
addresses (unless this was already done earlier before sending the
request; this is the case when no return routability check was
required).
o それが新しいアドレスでこのIKE_SAに関連しているIPsec SAsをアップデートする、(要求を送る前に、より早く既にこれをしました; リターンroutabilityチェックは全く必要でなかったときに、これがそうである、)
o If NAT Traversal is supported and NAT detection payloads were
included, the initiator enables or disables NAT Traversal.
o NAT Traversalが支持されて、NAT検出ペイロードが含まれていたなら、創始者は、NAT Traversalを有効にするか、または無効にします。
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).
応答者がADDRESSESが要求するUPDATE_SA_を受けないでどんなIPsec SAsも決してアップデートしないという規則への1つの例外があります。 応答者が現在使用しているソースアドレスが入手できなくなるなら(すなわち、そのソースアドレスを使用することでパケットを送るのはもう可能ではありません)、応答者は、ある他のアドレス(次のセクションで説明された手順に着手することに加えた)を使用するためにIPsec SAsをアップデートできます。
3.6. Updating Additional Addresses
3.6. 追加アドレスをアップデートします。
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で説明されるように、創始者と応答者の両方がイケ_AUTH交換における追加アドレスのリストを送ることができます。 どちらかを含むINFORMATIONAL交換要求メッセージ、より多くのADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS通知またはいいえ_ADDITIONAL_ADDRESSES通知を送ることによって、この情報をアップデートできます。
If the exchange initiator has only a single IP address, it is placed in the IP header, and the message contains the NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has several addresses, one of them is placed in the IP header, and the rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications.
交換創始者にただ一つのIPアドレスしかないなら、それはIPヘッダーに置かれます、そして、メッセージはいいえ_ADDITIONAL_ADDRESSES通知を含んでいます。 交換創始者にいくつかのアドレスがあるなら、それらの1つはADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS通知にIPヘッダー、および残りに置かれます。
Eronen Standards Track [Page 15] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[15ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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(追加_*_アドレス)+]、[N(_の追加_アドレスがない)]、[N(NATS_が許容しなかった_全く)][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_ADDRESSES通知、ADDITIONAL_IP4_ADDRESS、ADDITIONAL_IP6_ADDRESSを含む要求であることの交換応答者:
o Determines whether it has already received a newer request to
update the addresses (if a window size greater than one is used,
it is possible that the requests are received out of order). If
it has, a response message is sent, but the address set is not
updated.
o それが既に、アドレスをアップデートするというより新しい要求を受け取った(ウィンドウサイズ1以上が使用されているなら、故障していた状態で要求を受け取るのは可能です)か否かに関係なく、決定します。 それがそうしたなら、応答メッセージを送りますが、アドレスセットをアップデートしません。
o If the NO_NATS_ALLOWED notification is present, processes it as
described in Section 3.9.
o いいえ_NATS_ALLOWED通知がセクション3.9で説明されるように存在していて、それを処理するなら。
o Updates the set of peer addresses based on the IP header and the
ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, and
NO_ADDITIONAL_ADDRESSES notifications.
o 同輩アドレスのセットがIPヘッダーに基礎づけたアップデートにもかかわらず、ADDITIONAL_IP4_ADDRESS、ADDITIONAL_IP6_ADDRESSにもかかわらず、_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.
1つの追加複雑さがあります: 応答者がアドレスセットをアップデートしたがっているとき、現在中古のアドレスはもう働かないかもしれません。 この場合、応答者は、INFORMATIONALが要求する送付にどのアドレスを使用したらよいかを決定するのに創始者から受け取られた、追加住所録、およびそれ自身のアドレスのリストを使用します。 これは応答者が創始者から受け取られた追加住所録を使用する唯一の時です。
Eronen Standards Track [Page 16] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[16ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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]で既に必要であるように認識されていない状態通知を無視することを超えて)IP6_ADDRESS通知をADDITIONAL_IP4_ADDRESSを処理する必要性とどんなADDITIONALにもしません。 その上、創始者に地方の構成で指定された応答者アドレスだけが許容できると言う方針があるなら、それはそれ自身の追加アドレスを応答者に送る必要はありません(それ自身のアドレスを変える時以外に、応答者がそれらを必要としないので)。
3.7. Return Routability Check
3.7. リターンRoutabilityはチェックします。
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.
双方は、相手が実際に要求されたアドレスでパケットを受けることができることを任意に確かめることができます。 デフォルトで、これが「routabilityに、チェックを返す」というSHOULD、実行されてください。 同輩が品行方正であると(例えば、多くの法人のVPNs)予想するか、またはある他の手段(例えばこのために信じられた権威によって発行された証明書)がアドレスについて確かめることができる環境で、リターンroutabilityチェックは省略されるかもしれません。
The check can be done before updating the IPsec SAs, immediately after updating them, or continuously during the connection. By default, the return routability check SHOULD be done before updating the IPsec SAs, but in some environments it MAY be postponed until after the IPsec SAs have been updated.
絶え間なく彼らをアップデートする直後接続の間、IPsec SAsをアップデートする前に、チェックできます。 デフォルトで、IPsec SAsをアップデートする前にしますが、IPsec SAsをアップデートした後までそれがいくつかの環境であるかもしれないことで延期するのを除いて、リターンroutabilityはSHOULDをチェックします。
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.
リターンroutability目的に1つの例外(後でこのセクションで説明される)でどんな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メッセージに追加されます。 INFORMATIONAL要求の送付者はCOOKIE2通知を入れるかもしれません、そして、含まれているなら、INFORMATIONAL要求の受取人は応答にそのままな通知をコピーしなければなりません。 応答を処理するとき、元の送り主は、値が送るように同じ1つであることを確かめなければなりません。 値がマッチでない、イケ_にSA MUSTをするなら、閉じられてください。 (また、COOKIE2通知の形式に関してセクション4.2.5を見てください。)
Eronen Standards Track [Page 17] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[17ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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の送付先アドレスをアップデートしました)、INFORMATIONAL応答を受けるのは、どのアドレスが働くものであるかを言いません。 この場合、新しいINFORMATIONAL要求は、リターンroutabilityをチェックするために送られる必要があります。
3.8. Changes in NAT Mappings
3.8. NATマッピングにおける変化
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に関連しているSAsのすべてになかったなら、IKEv2はDead Peer Detection(DPD)を実行します。
In MOBIKE, these messages can also be used to detect if NAT mappings have changed (for example, if the keepalive interval is too long, or the NAT box is rebooted). More specifically, if both peers support both this specification and NAT Traversal, the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notifications MAY be included in any INFORMATIONAL request; if the request includes them, the responder MUST also include them in the response (but no other action is taken, unless otherwise specified).
また、MOBIKEでは、NATマッピングが変化したかどうか(例えばkeepalive間隔が長過ぎるか、またはNAT箱がリブートされるなら)検出するのにこれらのメッセージを使用できます。 _より明確に、両方の同輩が_NAT DETECTION_SOURCE_のこの仕様、NAT Traversal、IP、およびナットの両方を支持するなら、DETECTION_DESTINATION_IP通知はどんなINFORMATIONAL要求にも含まれるかもしれません。 また、要求がそれらを含んでいるなら、応答者は応答でそれらを入れなければなりません(別の方法で指定しない場合、他の行動を全く取りません)。
When the initiator is behind a NAT (as detected earlier using the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notifications), it SHOULD include these notifications in DPD messages and compare the received NAT_DETECTION_DESTINATION_IP notifications with the value from the previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT response). If the values do not match, the IP address and/or port seen by the responder has changed, and the initiator SHOULD send UPDATE_SA_ADDRESSES as described in Section 3.5. If the initiator suspects that the NAT mapping has changed, it MAY also skip the detection step and send UPDATE_SA_ADDRESSES immediately. This saves one roundtrip if the NAT mapping has indeed changed.
創始者はNATの後ろにいます(より早くNAT_DETECTION_SOURCE_IPとNAT_DETECTION_DESTINATION_IP通知を使用することで検出されるように)、それ。いつ、SHOULDは前のUPDATE_SA_ADDRESSES応答(または、イケ_SA_INIT応答)から値にDPDメッセージでこれらの通知を含めて、受信されたNAT_DETECTION_DESTINATION_IP通知をたとえるか。 値が合っていないなら、応答者によって見られたIPアドレス、そして/または、ポートは変化しました、そして、創始者SHOULDはセクション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 Security Parameter Indexes(SPIs)(「再-合わせ」ることを実行するとき、変化する)を含んでいるからです。 しかしながら、この不要なアップデートは無害です。
When MOBIKE is in use, the dynamic updates (specified in [IKEv2], Section 2.23), where the peer address and port are updated from the last valid authenticated packet, work in a slightly different fashion. The host not behind a NAT MUST NOT use these dynamic updates for IKEv2 packets, but MAY use them for ESP packets. This ensures that an INFORMATIONAL exchange that does not contain UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be used for, e.g., testing whether a particular path works.
MOBIKEが使用中であるときに、ダイナミックなアップデート([IKEv2]、セクション2.23では、指定される)は同輩アドレスとポートが最後の有効な認証されたパケットからアップデートされるところでわずかに異なったファッションで働いています。 ホストは、IKEv2パケットにNATの後ろでこれらのダイナミックなアップデートを使用しなければなりませんが、超能力パケットにそれらを使用するかもしれません。 これは、UPDATE_SA_ADDRESSESを含まないINFORMATIONAL交換が少しの変化も引き起こさないのを確実にします、特定の経路が働いているか否かに関係なく、それが中古で、例えば、テストしているのを許容して。
Eronen Standards Track [Page 18] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[18ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
3.9. NAT Prohibition
3.9. NAT禁止
Basic IKEv2/IPsec without NAT Traversal support may work across some types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in tunnel mode. This is because the IKEv2 integrity checksum does not cover the addresses in the IP header. This may be considered a problem in some circumstances, because in some sense any modification of the IP addresses can be considered an attack.
NAT Traversalサポートのない基本的なIKEv2/IPsecは何人かのタイプの1〜1「基本的な」NATsと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 Traversalが明らかに有効にされていないときIPアドレスを保護することによって、問題を記述します。 これは、経路がIPヘッダーでアドレスを変更するNATs、IPv4/IPv6翻訳エージェント、または他のノードを含んでいるとNAT TraversalサポートのないMOBIKEが働かないことを意味します。 この特徴はIPv6とサイトからサイトへのVPNケースのために主に意図します、そして、その結果、攻撃であるとパケットへのどんな変更も考えることができます。(そこでは、管理者があらかじめ、NATsが存在していないのを知るかもしれません)。
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 Traversalが有効にされないとき、IKE_SA、そして/または、IPsec SAs(_AUTHが要求する最初のイケ_と以下の通知のいずれも含むすべてのINFORMATIONAL要求: UPDATE_SA_ADDRESSES、ADDITIONAL_IP4_ADDRESS、ADDITIONAL_IP6_ADDRESS、いいえ、ADDITIONAL_ADDRESSES)に関連しているアドレスをアップデートできるすべてのメッセージがいいえ_NATS_ALLOWED通知を含まなければなりません。 交換応答者は、いいえ_NATS_ALLOWED通知の内容がIPヘッダーでアドレスに合っていることを確かめなければなりません。 彼らが合っていないなら、UNEXPECTED_NAT_DETECTED通知を含む応答を送ります。 対応する要求がいいえ_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.
交換創始者はINFORMATIONAL要求に対応してUNEXPECTED_NAT_DETECTED通知を受け取って、それは何度か使用している操作新しいINFORMATIONALが要求するSHOULD再試行です。 同様である、創始者はイケ_AUTH交換で_UNEXPECTED_NAT DETECTEDを受け取って、それはa新しい_イケ_SA INITから始めると何度か、要求されるSHOULD再試行IKE_SA設立です。 これは、単一のパケットしか変更できない攻撃者が未使用のままで経路を不必要に残らせないのを確実にします。 本書では相互運用性に影響しないので、再試行のはっきりした数は指定されません。 しかしながら、また、攻撃者が保全チェックサム分野を変更するとIKEメッセージが拒絶されるので、ここの相当な数は正常な「再-トランスミッション」に使用されている再試行の数でしょう。
Eronen Standards Track [Page 19] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[19ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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通知を送るなら、交換応答者はことによるとトラブルシューティング目的のための情報を登録するよりいかなる他の目的にもいいえ_NATS_ALLOWED通知のコンテンツを使用してはいけません。
3.10. Path Testing
3.10. 経路テスト
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 Dead Peer Detectionは同輩を検出させます。 しかしながら、同輩のどちらかにいくつかのアドレスがあるなら、Dead Peer Detectionだけが、他の経路のどれが働くかもしれないかを言いません。
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要求/応答メッセージを使用できます。 現在使用される経路が例えば、より良くて(以前に、入手できません)の経路がいつ利用可能になるかを検出するために働いても、実現は経路テストをするかもしれません。
3.11. Failure Recovery and Timeouts
3.11. 失敗回復とタイムアウト
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要求を再送するか、またはDead Peer Detectionを開始するかどうか決めるとき、誤りを検出できるくらいの時間を創始者に与えるために、応答者SHOULDは比較的長いタイムアウト間隔を費やします。 どんな特定のタイムアウトの長さも必要ではありませんが、応答者が、あきらめる前に少なくとも5分を求めるIKEv2要求を再送し続けていることを提案されます。
3.12. Dead Peer Detection
3.12. 死んでいる同輩検出
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と同じDead Peer Detection方法を使用しますが、アドレスが変化するかもしれないので、リターンroutabilityテストを終了しないことのため同輩が生きていますが、アドレス最新版と同時にして、例えば、アドレス最新版をまた無視していないことをただ確かめるのは十分ではありません。 これは、入って来るIPsecパケットがあるとき、MOBIKEノードSHOULDが、それらのパケットで使用されるアドレスを点検して、使われるべきであるものに対応することを決定することを意味します。 そして、そうしません、そのようなパケットSHOULD NOT、同輩がこのノードとコミュニケートできるという証拠として使用されてください、または、同輩はすべてのアドレス最新版を受けました。
Eronen Standards Track [Page 20] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[20ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
4. Payload Formats
4. 有効搭載量形式
This specification defines several new IKEv2 Notify payload types. See [IKEv2], Section 3.10, for a general description of the Notify payload.
この仕様はいくつかの新しいIKEv2 Notifyペイロードタイプを定義します。 Notifyペイロードの概説のために[IKEv2]、セクション3.10を見てください。
4.1. Notify Messages - Error Types
4.1. メッセージに通知してください--誤りタイプ
4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload
4.1.1. 容認できない_アドレスは有効搭載量に通知します。
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のためのNotify Message Typeは40歳です。 Protocol IDとSPI Size分野はゼロに設定されます。 このNotifyタイプに関連しているどんなデータもありません。
4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload
4.1.2. _が検出した予期していなかった_NATは有効搭載量に通知します。
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のためのNotify Message Typeは41歳です。 Protocol IDとSPI Size分野はゼロに設定されます。 このNotifyタイプに関連しているどんなデータもありません。
4.2. Notify Messages - Status Types
4.2. メッセージに通知してください--状態タイプ
4.2.1. MOBIKE_SUPPORTED Notify Payload
4.2.1. 支持されたMOBIKE_は有効搭載量に通知します。
The MOBIKE_SUPPORTED notification is included in the IKE_AUTH exchange to indicate that the implementation supports this specification.
MOBIKE_SUPPORTED通知は、実装がこの仕様をサポートするのを示すためにイケ_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のためのNotify Message Typeは16396です。 Protocol IDとSPI Size分野はゼロに設定されます。 発信するとき、空の(ゼロ・レングス)に通知データ・フィールドを残さなければなりません、そして、この通知が受信されているとき、コンテンツ(もしあれば)を無視しなければなりません。 これは、分野がこのプロトコルの将来のバージョンによって使用されるのを許容します。
4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify
Payloads
4.2.2. 追加_IP4_アドレスと追加_IP6_アドレスは有効搭載量に通知します。
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.
双方はイケ_AUTHのIP4_ADDRESS、そして/または、ADDITIONAL_IP6_ADDRESS通知が交換するADDITIONAL_とINFORMATIONAL交換要求メッセージを含むことができます。 より詳細な記述に関してセクション3.4とセクション3.6を見てください。
Eronen Standards Track [Page 21] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[21ページ]RFC4555MOBIKEは2006年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のためのNotify Message Typesはそれぞれ16397と16398です。 Protocol IDとSPI Size分野はゼロに設定されます。 これらのNotifyタイプに関連しているデータは、4八重奏のIPv4アドレスか16八重奏のIPv6アドレスのどちらかです。
4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload
4.2.3. どんな_の追加_アドレスも有効搭載量に通知しません。
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).
交換に使用されるものを超えて交換創始者にはアドレスがないのを示すINFORMATIONAL交換要求メッセージにいいえ_ADDITIONAL_ADDRESSES通知を含むことができます(より詳細な記述に関してセクション3.6を見てください)。
The Notify Message Type for NO_ADDITIONAL_ADDRESSES is 16399. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type.
_ADDITIONAL_ADDRESSESでないNotify Message Typeは16399です。 Protocol IDとSPI Size分野はゼロに設定されます。 このNotifyタイプに関連しているどんなデータもありません。
4.2.4. UPDATE_SA_ADDRESSES Notify Payload
4.2.4. アップデート_SA_アドレスは有効搭載量に通知します。
This notification is included in INFORMATIONAL exchange requests sent by the initiator to update addresses of the IKE_SA and IPsec SAs (see Section 3.5).
この通知はIKE_SAとIPsec SAsのアドレスをアップデートするために創始者によって送られた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のためのNotify Message Typeは16400です。 Protocol IDとSPI Size分野はゼロに設定されます。 このNotifyタイプに関連しているどんなデータもありません。
4.2.5. COOKIE2 Notify Payload
4.2.5. COOKIE2は有効搭載量に通知します。
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.
この通知はリターンroutabilityチェック目的を求めるどんなINFORMATIONAL要求にも含まれるかもしれません(セクション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の八重奏でなければならなく、交換創始者は交換応答者にとって、予測できない方法で選ばなければなりません。 このメッセージのためのNotify Message Typeは16401です。 Protocol IDとSPI Size分野はゼロに設定されます。
4.2.6. NO_NATS_ALLOWED Notify Payload
4.2.6. _が許容したいいえ_NATSは有効搭載量に通知します。
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:
このメッセージのためのNotify Message Typeは16402です。 通知データはパケットが送られた/からのIPアドレスとポートを含んでいます。 IPv4に関しては、通知データは、長い間の12の八重奏であり、以下の通り定義されます:
Eronen Standards Track [Page 22] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[22ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Protocol IDとSPI Size分野はゼロに設定されます。
Eronen Standards Track [Page 23] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[23ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
5. Security Considerations
5. セキュリティ問題
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]を見てください。
5.1. Traffic Redirection and Hijacking
5.1. トラフィックリダイレクションとハイジャック
MOBIKE payloads relating to updating addresses are encrypted, integrity protected, and replay protected using the IKE_SA. This assures that no one except the participants can, for instance, give a control message to change the addresses.
アドレスをアップデートするのに関係するMOBIKEペイロードは暗号化されていました、そして、保全は保護されました、そして、再生は、IKE_SAを使用することで保護されました。 これは、例えば、関係者以外のだれもアドレスを変えるコントロールメッセージを与えることができないことを保証します。
However, as with normal IKEv2, the actual IP addresses in the IP header are not covered by the integrity protection. This means that a NAT between the parties (or an attacker acting as a NAT) can modify the addresses and cause incorrect tunnel header (outer) IP addresses to be used for IPsec SAs. The scope of this attack is limited mainly to denial of service because all traffic is protected using IPsec.
しかしながら、正常なIKEv2のように、IPヘッダーの実際のIPアドレスは保全保護でカバーされていません。 これは、パーティー(または、NATとして務めている攻撃者)の間のNATがIPsec SAsに使用されるようにアドレスと原因不正確なトンネルヘッダー(外側の)IPアドレスを変更できることを意味します。 すべてのトラフィックがIPsecを使用することで保護されるので、この攻撃の範囲は主にサービスの否定に制限されます。
This attack can only be launched by on-path attackers that are capable of modifying IKEv2 messages carrying NAT detection payloads (such as Dead Peer Detection messages). By modifying the IP header of these packets, the attackers can lead the peers to believe a new NAT or a changed NAT binding exists between them. The attack can continue as long as the attacker is on the path, modifying the IKEv2 messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms designed to detect NAT mapping changes will eventually recognize that the intended traffic is not getting through, and will update the addresses appropriately.
経路のNAT検出ペイロード(Dead Peer Detectionメッセージなどの)を運ぶ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ヘッダーのアドレスの部外者によって使用されるいいえ_NATS_ALLOWED通知を紹介します。 この通知が使用されているとき、NATsと他のアドレス変換機構を通したコミュニケーションが不可能であるので、NAT Traversalをしないときだけ、それを送ります。 この特徴はIPv6とサイトからサイトへのVPNケースのために主に意図します。そこでは、管理者があらかじめ、NATsが存在していないのを知るかもしれません。
5.2. IPsec Payload Protection
5.2. IPsec有効搭載量保護
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保護の使用はトラフィックのコンテンツの公開に対して関係者を保護します、トラフィックが不正確な目的地で終わるか、または盗聴を受けることがあるなら。
Eronen Standards Track [Page 24] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[24ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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 SAsに作成できるかを決めるとき、同輩の(外側)の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.
トラフィックセレクタ承認に、これは特に重要です。 (論理的)の同輩Authorization Database(PAD)は同輩がどういうIPsec SAsに作成できるかを決定するときIKEv2によって使用された情報を含んでいます。 このプロセスは[IPsecArch]、セクション4.4.3で説明されます。 同輩がいくつかのトラフィックセレクタで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 SAsを作成する許可を含意しないことに注意するのは重要です。 しかしながら、いくつかの実装が何らかのアドレスXで単に届くのが、通常、「届く」のでアドレスX.HereのためにIPsec SAsを作成する一時的な許可がソースアドレス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.However、これらの相互作用がこのドキュメントの範囲を超えているのが近いIPsec SAsに必要であるかもしれません。
5.3. Denial-of-Service Attacks against Third Parties
5.3. 第三者に対するサービス不能攻撃
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セッションかマルチメディアストリームが犠牲者ホストに向かって向け直されるかもしれません、苦しむ能力をコミュニケーションに引き起こして。
Eronen Standards Track [Page 25] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[25ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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同輩のひとりのどちらかであることさえできます。 普通のVPN用法シナリオでは、初期のIKEv2交渉で実行された認証を攻撃に責任を負わせることができる人々にたどることができるなら、容易に同輩による攻撃に対処できます。 これはすべてのシナリオで特にセキュリティへの便宜主義的なアプローチがあるそうでないかもしれません。
If the attack is launched by an outsider, the traffic flow would normally stop soon due to the lack of responses (such as transport layer acknowledgements). However, if the original recipient of the flow is malicious, it could maintain the traffic flow for an extended period of time, since it often would be able to send the required acknowledgements (see [Aura02] for more discussion).
攻撃が部外者によって着手されるなら、通常、交通の流れはすぐ、応答(トランスポート層承認などの)の不足のため止まるでしょう。 しかしながら、流れのオリジナルの受取人は悪意があるなら、時間の長期間の間、交通の流れを維持するかもしれません、しばしば必要な承認を送ることができるでしょう(より多くの議論に関して[Aura02]を見てください)、したがって。
It should also be noted, as shown in [Bombing], that without ingress filtering in the attacker's network, such attacks are already possible simply by sending spoofed packets from the attacker to the victim directly. Furthermore, if the attacker's network has ingress filtering, this attack is largely prevented for MOBIKE as well. Consequently, it makes little sense to protect against attacks of similar nature in MOBIKE. However, it still makes sense to limit the amplification capabilities provided to attackers, so that they cannot use stream redirection to send a large number of packets to the victim by sending just a few packets themselves.
また、[爆撃]で示されるように攻撃者のネットワークにおけるイングレスフィルタリングがなければ、そのような攻撃が単に直接偽造しているパケットを攻撃者から犠牲者に送ることによって既に可能であることに注意されるべきです。 その上、攻撃者のネットワークにイングレスフィルタリングがあるなら、この攻撃はまた、MOBIKEのために主に防がれます。 その結果、それはほとんどMOBIKEでの同様の自然の攻撃から守る意味になりません。 しかしながら、まだ、攻撃者に提供された増幅能力を制限する意味になっています、彼らがわずかいくつかのパケット自体を送ることによって多くのパケットを犠牲者に送るのにストリームリダイレクションを使用できないように。
This specification includes return routability tests to limit the duration of any "third party bombing" attacks by off-path (relative to the victim) attackers. The tests are authenticated messages that the peer has to respond to, and can be performed before the address change takes effect, immediately afterwards, or even periodically during the session. The tests contain unpredictable data, and only someone who has the keys associated with the IKE SA and has seen the request packet can properly respond to the test.
この仕様は、オフ経路(犠牲者に比例した)攻撃者によるどんな「第三者爆撃」攻撃の持続時間も制限するためにリターンroutabilityテストを含んでいます。 テストは、同輩がそうしたという応じる認証されたメッセージであり、アドレス変化がその後すぐに効く前にセッションの間、定期的にさえ実行できます。 テストは予測できないデータを含んでいます、そして、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で説明されるように、このSHOULDは活性テストの引き金となります。
5.4. Spoofing Network Connectivity Indications
5.4. ネットワークの接続性が指摘であると偽造します。
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
攻撃者は、アドレスがそうである同輩を混乱させるように下層とネットワークから取り組みで様々な指摘を偽造するかもしれないか、または働いていません。 例えば、攻撃者は、パーティーが彼らのトラフィックをほかの場所に動かすか、または切断するのさえ引き起こすために取り組みにおけるリンクレイヤエラーメッセージを偽造するかもしれません。 また、攻撃者はだますかもしれません。
Eronen Standards Track [Page 26] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[26ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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はそれ自身の少しの保護もプロトコル・スタックの他の一部から指摘に提供しません。 IPv6 RouterとNeighborディスカバリーを保護するためにスタックのICMP誤りの合法化などの他の一部[ICMPAttacks]、リンクレイヤセキュリティ、または[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メッセージの非配送が影響を及ぼすことができるそれのアドレスが実際に使用される攻撃者。
5.5. Address and Topology Disclosure
5.5. アドレスとトポロジー公開
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.
例えば、2つのネットワーク・インターフェースをもっているホストAを考えてください: 会社のLANへのセル接続とワイヤードなイーサネット接続。 ホストAがIKEv2を使用することで現在、ホストBに連絡して、_ADDRESS/ADDITIONAL_IP6_ADDRESS通知をADDITIONAL_IP4に送るなら、ホストBはそれが別の方法で知らないかもしれない追加情報を受け取ります。 また、ホストAがIKEv2トラフィックにセル接続を使用したなら、ホストBは会社のLANアドレスを見ることができます(ホストAがその会社の従業員によって使用されると恐らくさらに推測してください)。 ホストAが接続を作るのに会社のLANを使用したなら、ホストBは、ホストAにはこの特定のセルオペレータからの購読があるのを見ることができます。
These additional addresses can also disclose more accurate location information than just a single address. Suppose that host A uses its cellular connection for IKEv2 traffic, but also sends an ADDITIONAL_IP4_ADDRESS notification containing an IP address corresponding to, say, a wireless LAN at a particular coffee shop location. It is likely that host B can now make a much better guess at A's location than would be possible based on the cellular IP address alone.
また、これらの追加アドレスはまさしくただ一つのアドレスより正確な位置情報を明らかにすることができます。 ホストAがIKEv2トラフィックにセル接続を使用しますが、特定の喫茶店の位置にたとえば、無線LANに対応するIPアドレスを保管しているADDITIONAL_IP4_ADDRESS通知をまた送ると仮定してください。 ホストBは今、セルIPアドレスだけに基づいて可能であるだろうというよりもAの位置ではるかに良い推測をすることができそうです。
Eronen Standards Track [Page 27] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[27ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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に述べられるように、いつも局所的に構成された応答者アドレスを使用する方針がことである創始者は_ADDRESS/ ADDITIONAL_IP6_ADDRESSペイロードをどんなADDITIONAL_IP4にも送る必要はありません。
6. IANA Considerations
6. IANA問題
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
メッセージに通知してください--誤りは値をタイプします。----------------------------- ----- 容認できない_アドレス40の予期していなかった_NAT_は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
メッセージに通知してください--状態は値をタイプします。------------------------------ ----- MOBIKE_はどんな_の追加_アドレスも16399アップデートしない16396の追加_IP4_アドレス16397の追加_IP6_アドレス16398に_COOKIE2 16401いいえ_NATS_が16402を許容したSA_アドレス16400をサポートしました。
These notifications are described in Section 4.
これらの通知はセクション4で説明されます。
Eronen Standards Track [Page 28] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[28ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
7. Acknowledgements
7. 承認
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の共同努力です。 特にエリックNordmark、モハンのヤリArkko、Tuomas Aura、マルセロBagnulo、ステファーヌBeaulieu、Elwynデイヴィース、Lakshminath Dondeti、フランシス・デュポン、ポール・ホフマン、ジェームス・ケンフ、Tero Kivinen、ピートマッキャン、パルタサラティ、ペッカSavola、ビル・ゾンマーフェルト、モーリーン・スティルマン、Shinta杉本、ハンネスTschofenig、およびサミVaaralaに感謝申し上げます。 また、このドキュメントは以前のMOBIKEのようなプロトコル提案から考えとテキストを取り入れます、[AddrMgmt]、[Kivinen]、[MOPO]、[SMOBIKE]、およびMOBIKEデザインドキュメント[デザイン]を含んでいて。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[IKEv2] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[IPsecArch] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[IPsecArch] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
8.2. Informative References
8.2. 有益な参照
[AddrMgmt] Dupont, F., "Address Management for IKE version 2",
Work in Progress, November 2005.
[AddrMgmt] デュポン、F.は「Progress、2005年11月にIKEのためのManagementがバージョン2インチ、Workであると扱います」。
[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。 2002年12月の第18年に一度のコンピュータセキュリティアプリケーションコンファレンス(ACSAC)。
[Bombing] Dupont, F., "A note about 3rd party bombing in
Mobile IPv6", Work in Progress, December 2005.
[爆撃します] デュポン、F.、「2005年12月にモバイルIPv6"、ProgressのWorkで爆撃する3番目のパーティーに関する注。」
[Clarifications] Eronen, P. and P. Hoffman, "IKEv2 Clarifications
and Implementation Guidelines", Work in Progress,
February 2006.
P.、P.ホフマン、および「IKEv2明確化と実施要綱」という[明確化]Eronenは進歩、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)でネットワーク付属を見つけます」、RFC4436、2006年3月。
Eronen Standards Track [Page 29] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[29ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
[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にNetwork Attachmentを検出します--ホストのためにCurrent Practicesを負かしてください」、ProgressのWork、2005年10月。
[Design] Kivinen, T. and H. Tschofenig, "Design of the
MOBIKE protocol", Work in Progress, January 2006.
Progress、2006年1月の[デザイン]KivinenとT.とH.Tschofenig、「MOBIKEプロトコルのデザイン」、Work。
[ICMPAttacks] Gont, F., "ICMP attacks against TCP", Work in
Progress, October 2005.
[ICMPAttacks]Gont、F.、「TCPに対するICMP攻撃」、Progress、2005年10月のWork。
[Kivinen] Kivinen, T., "MOBIKE protocol", Work in Progress,
February 2004.
[Kivinenします] Kivinen、T.、「MOBIKEは議定書を作る」Progress、2004年2月のWork。
[MIP4] Perkins, C., "IP Mobility Support for IPv4",
RFC 3344, August 2002.
[MIP4] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[MIP6] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[MOPO] Eronen, P., "Mobility Protocol Options for IKEv2
(MOPO-IKE)", Work in Progress, February 2005.
P.、「IKEv2(MOPO-IKE)のための移動性プロトコルオプション」という[MOPO]Eronenは進歩、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)のための隣人発見」、RFC2461、1998年12月。
[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
March 2005.
[発信します] ArkkoとJ.とケンフとJ.とZill、B.とP.Nikander、「安全な隣人発見(発信する)」、RFC3971、2005年3月。
[SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and
Multihoming Extensions for IKEv2 (SMOBIKE)",
Work in Progress, March 2004.
[SMOBIKE] 「IKEv2(SMOBIKE)のための簡単な移動性とマルチホーミング拡大」というEronen、P.、およびH.Tschofenigは進歩、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.
[気絶させます] ローゼンバーグ、J.、ワインバーガー、J.、Huitema、C.、およびR.マーイ、「気絶させてください--ネットワークアドレス変換機構(NATs)を通したユーザー・データグラム・プロトコル(UDP)の簡単な縦断」、RFC3489、2003年3月。
[UNSAF] Daigle, L., "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[UNSAF] Daigle、L.、「一方的な自己アドレスのためのネットワークアドレス変換の向こう側に(UNSAF)を修理するIAB問題」、RFC3424、2002年11月。
Eronen Standards Track [Page 30] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[30ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
Appendix A. Implementation Considerations
付録A.実装問題
A.1. Links from SPD Cache to Outbound SAD Entries
A.1。 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.
「外国行きの処理において、それぞれのSADエントリーはSPDキャッシュのSPD-S部分にエントリーで示されます。」と、[IPsecArch](セクション4.4.2)は言います。 ドキュメントは、この「指すこと」がいったいどうやって完了しているかを指定しません、これが標準化される必要はない実装の詳細であるので。
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.
しかしながら、外国行きのパケットが右のSAの上に送られるのを保証するために正しくSPDキャッシュとSADとのリンクをしなければならないのは明確です。 いくつかの実装がこの領域に問題を持っているのが知られています。
In particular, simply storing the (remote tunnel header IP address, remote SPI) pair in the SPD cache is not sufficient, since the pair does not always uniquely identify a single SAD entry. For instance, two hosts behind the same NAT can accidentally happen to choose the same SPI value. The situation can also occur when a host is assigned an IP address previously used by some other host, and the SAs associated with the old host have not yet been deleted by Dead Peer Detection. This may lead to packets being sent over the wrong SA or, if the key management daemon ensures the pair is unique, denying the creation of otherwise valid SAs.
SPDキャッシュで単に(リモートトンネルヘッダーIPアドレス、リモートSPI)組を保存するのは特に、十分ではありません、組がいつも唯一単一のSADエントリーを特定するというわけではないので。 例えば、同じNATの後ろの2人のホストが偶然たまたま同じSPI値を選ぶことができます。 また、以前にある他のホストによって使用されたIPアドレスがホストに割り当てられるとき、状況は起こることができます、そして、年取ったホストに関連しているSAsはDead Peer Detectionによってまだ削除されていません。 これは間違ったSAかかぎ管理デーモンが組が確実にユニークになるようにするときそうでなければ、有効なSAsの作成を否定する上に送られるパケットに通じるかもしれません。
Storing the remote tunnel header IP address in the SPD cache may also complicate the implementation of MOBIKE, since the address can change during the lifetime of the SA. Thus, we recommend implementing the links between the SPD cache and the SAD in a way that does not require modification when the tunnel header IP address is updated by MOBIKE.
また、SPDキャッシュにおけるリモートトンネルヘッダーIPアドレスを保存すると、MOBIKEの実装は複雑にされるかもしれません、アドレスがSAの生涯変化できるので。 したがって、私たちは、トンネルヘッダーIPアドレスがMOBIKEによってアップデートされるとき変更を必要としない方法でSPDキャッシュとSADとのリンクを実装することを勧めます。
A.2. Creating Outbound SAs
A.2。 外国行きのSAsを作成します。
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は作成されるでしょう。 この場合、ホストは、このSAのために(1) だれが正しい同輩であるかを決心しなければなりません、(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 言います:
Eronen Standards Track [Page 31] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[31ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
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(セキュリティゲートウェイによって役立たれるホスト)のために運命づけられた外国行きのパケットを受けると仮定してください。 RFC2401[RFC2401]とこのドキュメントはAがどうX.Howeverに勤めているIKE同輩のアドレスを決定するかを指定しません、とどんな同輩もIKE交換が認証されるのを許容するためにPADにXのための推定された代表を登録しなければならないので、Aで連絡しました。 認証された同輩が、交通セレクタ交換における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に、1人以上の可能な同輩(Xを表すことができる例えばいくつかのセキュリティゲートウェイ)がいるかもしれません。 ステップ3では、ホストは、同輩IPアドレス(es)を決定するためにDNSなどのディレクトリを参照する必要があるかもしれません。
When performing these steps, implementations may use information contained in the SPD, the PAD, and possibly some other implementation-specific databases. Regardless of how exactly the steps are implemented, it is important to remember that IP addresses can change, and that an IP address alone does not always uniquely identify a single IKE peer (for the same reasons as why the combination of the remote IP address and SPI does not uniquely identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1 and 2 it may be easier to identify the "right peer" using its authenticated identity instead of its current IP address. However, these implementation details are beyond the scope of this specification.
これらのステップを実行するとき、実現はSPD、PAD、およびことによるとある他の実現特有のデータベースに含まれた情報を使用するかもしれません。 いったいどうやってであることにかかわらずステップは実行されるか、そして、IPアドレスが変化できて、IPアドレスだけがいつも唯一独身のIKE同輩を特定するというわけではないのを覚えているのは重要です(リモートIPのアドレスとSPIの組み合わせが唯一外国行きのIPsec SAを特定しない理由と同じ理由で; Appendix 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フィン-00045Nokia Groupフィンランド
EMail: pasi.eronen@nokia.com
メール: pasi.eronen@nokia.com
Eronen Standards Track [Page 32] RFC 4555 MOBIKE Protocol June 2006
Eronen標準化過程[32ページ]RFC4555MOBIKEは2006年6月に議定書を作ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Eronen Standards Track [Page 33]
Eronen標準化過程[33ページ]
一覧
スポンサーリンク
