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