RFC5265 日本語訳
5265 Mobile IPv4 Traversal across IPsec-Based VPN Gateways. S.Vaarala, E. Klovning. June 2008. (Format: TXT=86254 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Vaarala
Request for Comments: 5265 Codebay
Category: Standards Track E. Klovning
Birdstep
June 2008
Vaaralaがコメントのために要求するワーキンググループS.をネットワークでつないでください: 5265年のCodebayカテゴリ: 標準化過程E.Klovning Birdstep2008年6月
Mobile IPv4 Traversal across IPsec-Based VPN Gateways
IPsecベースのVPNゲートウェイの向こう側のモバイルIPv4縦断
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document outlines a solution for the Mobile IPv4 (MIPv4) and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely.
このドキュメントはモバイルIPv4(MIPv4)とIPsec共存問題によって企業のユーザのためにソリューションについて概説します。 ソリューションは、法人の遠隔アクセスのシナリオのセッションの移動性にモバイルIPv4とIPsecを使用して、しっかりと信じられた内部のネットワークを検出するのに必要なメカニズムを使用するために適用性証明から成ります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Related Work . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Terms and Abbreviations . . . . . . . . . . . . . . . . . 5
1.5. Requirement Levels . . . . . . . . . . . . . . . . . . . . 6
1.6. Assumptions and Rationale . . . . . . . . . . . . . . . . 7
1.7. Why IPsec Lacks Mobility . . . . . . . . . . . . . . . . . 8
2. The Network Environment . . . . . . . . . . . . . . . . . . . 9
2.1. Access Mode: 'c' . . . . . . . . . . . . . . . . . . . . . 12
2.2. Access Mode: 'f' . . . . . . . . . . . . . . . . . . . . . 13
2.3. Access Mode: 'cvc' . . . . . . . . . . . . . . . . . . . . 13
2.4. Access Mode: 'fvc' . . . . . . . . . . . . . . . . . . . . 14
2.5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 14
3. Internal Network Detection . . . . . . . . . . . . . . . . . . 15
3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Implementation Requirements . . . . . . . . . . . . . . . 16
3.2.1. Separate Tracking of Network Interfaces . . . . . . . 16
3.2.2. Connection Status Change . . . . . . . . . . . . . . . 16
3.2.3. Registration-Based Internal Network Detection . . . . 17
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 概要. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 範囲. . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3。 関連仕事. . . . . . . . . . . . . . . . . . . . . . . 5 1.4。 用語と略語. . . . . . . . . . . . . . . . . 5 1.5。 要件レベル. . . . . . . . . . . . . . . . . . . . 6 1.6。 仮定と原理. . . . . . . . . . . . . . . . 7 1.7。 IPsecは移動性. . . . . . . . . . . . . . . . . 8 2を欠いています。 ネットワーク環境. . . . . . . . . . . . . . . . . . . 9 2.1。 モードにアクセスしてください: 'c'. . . . . . . . . . . . . . . . . . . . . 12 2.2。 モードにアクセスしてください: 'f'. . . . . . . . . . . . . . . . . . . . . 13 2.3。 モードにアクセスしてください: 'cvc'. . . . . . . . . . . . . . . . . . . . 13 2.4。 モードにアクセスしてください: 'fvc'. . . . . . . . . . . . . . . . . . . . 14 2.5。 NAT縦断. . . . . . . . . . . . . . . . . . . . . . 14 3。 内部のネットワーク検出. . . . . . . . . . . . . . . . . . 15 3.1。 仮定. . . . . . . . . . . . . . . . . . . . . . . 16 3.2。 実装要件. . . . . . . . . . . . . . . 16 3.2.1。 ネットワーク・インターフェース. . . . . . . 16 3.2.2を追跡して、分離してください。 接続形態変化. . . . . . . . . . . . . . . 16 3.2.3。 登録ベースの内部のネットワーク検出. . . . 17
Vaarala & Klovning Standards Track [Page 1] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[1ページ]。
3.2.4. Registration-Based Internal Network Monitoring . . . . 17
3.3. Proposed Algorithm . . . . . . . . . . . . . . . . . . . . 19
3.4. Trusted Networks Configured (TNC) Extension . . . . . . . 20
3.5. Implementation Issues . . . . . . . . . . . . . . . . . . 20
3.6. Rationale for Design Choices . . . . . . . . . . . . . . . 21
3.6.1. Firewall Configuration Requirements . . . . . . . . . 21
3.6.2. Registration-Based Internal Network Monitoring . . . . 22
3.6.3. No Encryption When Inside . . . . . . . . . . . . . . 22
3.7. Improvements . . . . . . . . . . . . . . . . . . . . . . . 22
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Mobile Node Requirements . . . . . . . . . . . . . . . . . 23
4.2. VPN Device Requirements . . . . . . . . . . . . . . . . . 23
4.3. Home Agent Requirements . . . . . . . . . . . . . . . . . 24
5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Comparison against Guidelines . . . . . . . . . . . . . . 24
5.2. Packet Overhead . . . . . . . . . . . . . . . . . . . . . 26
5.3. Latency Considerations . . . . . . . . . . . . . . . . . . 27
5.4. Firewall State Considerations . . . . . . . . . . . . . . 27
5.5. Intrusion Detection Systems (IDSs) . . . . . . . . . . . . 28
5.6. Implementation of the Mobile Node . . . . . . . . . . . . 28
5.7. Non-IPsec VPN Protocols . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6.1. Internal Network Detection . . . . . . . . . . . . . . . . 29
6.2. Mobile IPv4 versus IPsec . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Packet Flow Examples . . . . . . . . . . . . . . . . 34
A.1. Connection Setup for Access Mode 'cvc' . . . . . . . . . . 34
3.2.4. 登録ベースの内部のネットワーク監視. . . . 17 3.3。 アルゴリズム. . . . . . . . . . . . . . . . . . . . 19 3.4を提案しました。 信じられたネットワークは(TNC)拡大. . . . . . . 20 3.5を構成しました。 導入問題. . . . . . . . . . . . . . . . . . 20 3.6。 デザイン選択. . . . . . . . . . . . . . . 21 3.6.1のための原理。 ファイアウォール構成必要条件. . . . . . . . . 21 3.6.2。 登録ベースの内部のネットワーク監視. . . . 22 3.6.3。 内面の.223.7であることの暗号化がありません。 改良. . . . . . . . . . . . . . . . . . . . . . . 22 4。 要件. . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1。 モバイルノード要件. . . . . . . . . . . . . . . . . 23 4.2。 VPNデバイス要件. . . . . . . . . . . . . . . . . 23 4.3。 ホームエージェント要件. . . . . . . . . . . . . . . . . 24 5。 分析. . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1。 ガイドライン. . . . . . . . . . . . . . 24 5.2に対する比較。 パケットオーバーヘッド. . . . . . . . . . . . . . . . . . . . . 26 5.3。 潜在問題. . . . . . . . . . . . . . . . . . 27 5.4。 ファイアウォール州の問題. . . . . . . . . . . . . . 27 5.5。 侵入検知システム(IDSs).285.6。 モバイルノード. . . . . . . . . . . . 28 5.7の実装。 非IPsec VPNプロトコル. . . . . . . . . . . . . . . . . 28 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 29 6.1。 内部のネットワーク検出. . . . . . . . . . . . . . . . 29 6.2。 モバイルIPv4対IPsec. . . . . . . . . . . . . . . . . 30 7 IANA問題. . . . . . . . . . . . . . . . . . . . . 31 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 31 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 32 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 33付録A.パケット流れの例. . . . . . . . . . . . . . . . 34のA.1。 アクセス・モード'cvc'.34のための接続設定
Vaarala & Klovning Standards Track [Page 2] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[2ページ]。
1. Introduction
1. 序論
The Mobile IP working group set out to explore the problem and solution spaces of IPsec and Mobile IP coexistence. The problem statement and solution requirements for Mobile IPv4 case were first documented in [RFC4093]. This document outlines a solution for IPv4.
モバイルIPワーキンググループは、IPsecとモバイルIP共存の問題とソリューション空間を探り始めました。 モバイルIPv4のための声明とソリューション要件がケースに入れる問題は最初に、[RFC4093]に記録されました。 このドキュメントはIPv4のためにソリューションについて概説します。
The document contains two parts:
ドキュメントは2つの部品を含んでいます:
o a basic solution that is an applicability statement of Mobile IPv4
and IPsec to provide session mobility between enterprise intranets
and external networks, intended for enterprise mobile users; and
o 企業イントラネットの間にセッションの移動性を提供するモバイルIPv4とIPsecの適用性証明と企業のモバイルユーザのために意図する外部のネットワークである基本解決法。 そして
o a technical specification and a set of requirements for secure
detection of the internal and the external networks, including a
new extension that must be implemented by a mobile node and a home
agent situated inside the enterprise network.
o 内部のネットワークとモバイルノードで実装しなければならない新しい拡大と企業網の中に位置したホームのエージェントを含む外部のネットワークの安全な検出のための要件の技術仕様書とセット
There are many useful ways to combine Mobile IPv4 and IPsec. The solution specified in this document is most applicable when the assumptions documented in the problem statement [RFC4093] are valid; among others that the solution:
モバイルIPv4とIPsecを結合する多くの役に立つ方法があります。 問題声明[RFC4093]に記録された仮定が有効であるときに、本書では指定される中でソリューションは最も適切です。 特にそれ、ソリューション:
o must minimize changes to existing firewall/VPN/DMZ (DeMilitarized
Zone) deployments;
o 既存のファイアウォール/VPN/DMZ(DeMilitarized Zone)展開への変化を最小にしなければなりません。
o must ensure that traffic is not routed through the DMZ when the
mobile node is inside (to avoid scalability and management
issues);
o モバイルノードが中(スケーラビリティと管理問題を避ける)にあるとき、トラフィックがDMZを通して発送されないのを確実にしなければなりません。
o must support foreign networks with only foreign agent access;
o 外国エージェントアクセスだけで外国ネットワークをサポートしなければなりません。
o should not require changes to existing IPsec or key exchange
protocols;
o 既存のIPsecか主要な交換プロトコルへの変化を必要とするべきではありません。
o must comply with the Mobile IPv4 protocol (but may require new
extensions or multiple instances of Mobile IPv4); and
o モバイルIPv4プロトコル(しかし、モバイルIPv4の新しい拡大か複数のインスタンスを必要とするかもしれない)に従わなければなりません。 そして
o must propose a mechanism to avoid or minimize IPsec re-negotiation
when the mobile node moves.
o モバイルノードが移行すると、IPsec再交渉を避けるか、または最小にするためにメカニズムを提案しなければなりません。
1.1. Overview
1.1. 概要
Typical corporate networks consist of three different domains: the Internet (untrusted external network), the intranet (trusted internal network), and the DMZ, which connects the two networks. Access to the internal network is guarded both by a firewall and a VPN device;
典型的な企業ネットワークは3つの異なったドメインから成ります: インターネット(信頼されていない外部のネットワーク)、イントラネット(内部のネットワークを信じる)、およびDMZ。(そのDMZは2つのネットワークを接続します)。 内部のネットワークへのアクセスはファイアウォールとVPNデバイスによって警備されます。
Vaarala & Klovning Standards Track [Page 3] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[3ページ]。
access is only allowed if both firewall and VPN security policies are respected.
ファイアウォールとVPN安全保障政策の両方が尊敬される場合にだけ、アクセスは許されています。
Enterprise mobile users benefit from unrestricted seamless session mobility between subnets, regardless of whether the subnets are part of the internal or the external network. Unfortunately, the current Mobile IPv4 and IPsec standards alone do not provide such a service [tessier].
エンタープライズのモバイルユーザはサブネットの間の無制限なシームレスのセッションの移動性の利益を得ます、サブネットが内部のネットワークか外部のネットワークの一部であるかどうかにかかわらず。 残念ながら、現在のモバイルIPv4とIPsec規格だけがそのようなサービス[tessier]を提供しません。
The solution is to use standard Mobile IPv4 (except for a new extension used by the home agent in the internal network to aid in network detection) when the mobile node is in the internal network, and to use the VPN tunnel endpoint address for the Mobile IPv4 registration when outside. IPsec-based VPN tunnels require re- negotiation after movement. To overcome this limitation, another layer of Mobile IPv4 is used underneath IPsec, in effect making IPsec unaware of movement. Thus, the mobile node can freely move in the external network without disrupting the VPN connection.
ソリューションは内部のネットワークと、そして、外であることのときにVPNトンネル終点がモバイルIPv4登録のために演説する使用にモバイルノードがあるとき、標準のモバイルIPv4(ネットワーク検出で支援するのに内部のネットワークのホームのエージェントによって使用された新しい拡張子を除いた)を使用することです。 IPsecベースのVPNトンネルは動きの後に再交渉を必要とします。 この限界を克服するために、事実上IPsecを動きに気づかなくして、モバイルIPv4の別の層はIPsecの下で使用されます。 したがって、VPN接続を中断しないで、モバイルノードは自由に外部のネットワークに入って来ることができます。
Briefly, when outside, the mobile node:
外部、簡潔にモバイルノードであるときに:
o detects that it is outside (Section 3);
o 検出、(セクション3)の外にそれはあります。
o registers its co-located or foreign agent care-of address with the
external home agent;
o 共同見つけられたか外国人のエージェントを登録する、注意、-、外部のホームのエージェントとのアドレス。
o establishes a VPN tunnel using, e.g., Internet Key Exchange
Protocol (IKE) (or IKEv2) if security associations are not already
available;
o セキュリティ協会が既に利用可能でないなら、VPNトンネル使用、例えば、インターネット・キー・エクスチェンジプロトコル(IKE)(または、IKEv2)は設立します。
o registers the VPN tunnel address as its co-located care-of address
with the internal home agent; this registration request is sent
inside the IPsec tunnel.
o それが共同見つけられたのでVPNトンネルアドレスを登録する、注意、-、内部のホームのエージェントとのアドレス。 IPsecトンネルの中でこの登録要求を送ります。
The solution requires control over the protocol layers in the mobile node. It must be capable of (1) detecting whether it is inside or outside in a secure fashion, and (2) controlling the protocol layers accordingly. For instance, if the mobile node is inside, the IPsec layer needs to become dormant.
ソリューションはモバイルノードのプロトコル層のコントロールを必要とします。 (1) それが安全なファッション、および(2)の中か外にあるかどうか検出するのがそれはそれに従って、プロトコル層を制御できなければなりません。 例えば、モバイルノードが中にあるなら、IPsec層は、眠るようになる必要があります。
Except for the new Mobile IPv4 extension to improve security of internal network detection, current Mobile IPv4 and IPsec standards, when used in a suitable combination, are sufficient to implement the solution. No changes are required to existing VPN devices or foreign agents.
改良する新しいモバイルIPv4拡張子を除いて、適当な組み合わせに使用されると、内部のネットワーク検出、現在のモバイルIPv4、およびIPsec規格のセキュリティは、ソリューションを実現するために十分です。 変化は全く既存のVPNデバイスか外国人のエージェントに必要ではありません。
The solution described is compatible with different kinds of IPsec- based VPNs, and no particular kind of VPN is required. Because the
説明されたソリューションはIPsecのベースのVPNsの異種と互換性があります、そして、VPNのどんな特定の種類も必要ではありません。 the
Vaarala & Klovning Standards Track [Page 4] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[4ページ]。
appropriate Security Policy Database (SPD) entries and other IKE and IPsec specifics differ between deployed IPsec-based VPN products, these details are not discussed in the document.
適切なSecurity Policy Database(SPD)エントリー、他のIKE、およびIPsec詳細は配布しているIPsecベースのVPN製品の間で異なって、ドキュメントでこれらの詳細について議論しません。
1.2. Scope
1.2. 範囲
This document describes a solution for IPv4 only. The downside of the described approach is that an external home agent is required and that the packet overhead (see Section 5) and overall complexity increase. Optimizations would require significant changes to Mobile IPv4 and/or IPsec, and are out of scope of this document.
このドキュメントはIPv4だけのためにソリューションについて説明します。 説明されたアプローチの下落傾向は外部のホームのエージェントが必要であり、パケットオーバーヘッド(セクション5を見る)と総合的な複雑さが上がるということです。 最適化は、モバイルIPv4、そして/または、IPsecへの著しい変化を必要として、このドキュメントの範囲の外にあります。
VPN, in this document, refers to an IPsec-based remote access VPN. Other types of VPNs are out of scope.
VPNは本書ではIPsecベースの遠隔アクセスのVPNについて言及します。 範囲の外にVPNsの他のタイプがあります。
1.3. Related Work
1.3. 関連仕事
Related work has been done on Mobile IPv6 in [RFC3776], which discusses the interaction of IPsec and Mobile IPv6 in protecting Mobile IPv6 signaling. The document also discusses dynamic updating of the IPsec endpoint based on Mobile IP signaling packets.
[RFC3776]のモバイルIPv6で関連仕事をしました。(]はモバイルIPv6シグナリングを保護する際にIPsecとモバイルIPv6の相互作用について議論します)。 また、ドキュメントはモバイルIPシグナリングパケットに基づくIPsec終点のダイナミックなアップデートについて議論します。
The "transient pseudo-NAT" attack, described in [pseudonat] and [mipnat], affects any approach that attempts to provide security of mobility signaling in conjunction with NAT devices. In many cases, one cannot assume any cooperation from NAT devices, which thus have to be treated as any other networking entity.
[pseudonat]と[mipnat]で説明された「一時的な疑似NAT」攻撃はNATデバイスに関連して移動性シグナリングのセキュリティを提供するのを試みるどんなアプローチにも影響します。 多くの場合、人はNATデバイスから少しの協力も仮定できません。(その結果、デバイスはいかなる他のネットワーク実体としても扱われなければなりません)。
The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555] provides better mobility for IPsec. This would allow the external Mobile IPv4 layer described in this specification to be removed. However, deploying MOBIKE requires changes to VPN devices, and is thus out of scope of this specification.
IKEv2 MobilityとMultihomingプロトコル(MOBIKE)[RFC4555]は、より良い移動性をIPsecに供給します。 これは、この仕様で説明された外部のモバイルIPv4層が取り除かれるのを許容するでしょう。 しかしながら、その結果、MOBIKEが必要とする展開は、VPNデバイスに変化して、この仕様の範囲の外にあります。
1.4. Terms and Abbreviations
1.4. 用語と略語
co-CoA: co-located care-of address.
ココア: 共同見つけられている、注意、-、アドレス。
DMZ: (DeMilitarized Zone) a small network inserted as a "neutral
zone" between a company's private network and the outside public
network to prevent outside users from getting direct access to the
company's private network.
非武装地帯: (非武装地帯) ユーザの外で会社の私設のネットワークにダイレクトに近づく手段を得るのを防ぐ会社の私設のネットワークと外の公衆通信回線の間の「ニュートラルゾーン」として挿入された小さいネットワーク。
external network: the untrusted network (i.e., Internet). Note
that a private network (e.g., another corporate network) other
than the mobile node's internal network is considered an external
network.
外部のネットワーク: 信頼されていないネットワーク(すなわち、インターネット)。 モバイルノードの内部のネットワーク以外の私設のネットワーク(例えば、別の企業ネットワーク)が外部のネットワークであると考えられることに注意してください。
Vaarala & Klovning Standards Track [Page 5] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[5ページ]。
FA: mobile IPv4 foreign agent.
ファ: モバイルIPv4外国人のエージェント。
FA-CoA: foreign agent care-of address.
ファ-CoA: 外国人のエージェント、注意、-、アドレス。
FW: firewall.
fw: ファイアウォール。
internal network: the trusted network; for instance, a physically
secure corporate network where the i-HA is located.
内部のネットワーク: 信じられたネットワーク。 例えば、i-HAが位置している肉体的に安全な企業ネットワーク。
i-FA: Mobile IPv4 foreign agent residing in the internal network.
i-ファ: 内部のネットワークで住んでいるモバイルIPv4外国人のエージェント。
i-HA: Mobile IPv4 home agent residing in the internal network;
typically has a private address [privaddr].
i、-、ハ、: 内部のネットワークで住んでいるモバイルIPv4ホームのエージェント。 プライベート・アドレス[privaddr]を通常持っています。
i-HoA: home address of the mobile node in the internal home agent.
i-HoA: 内部のホームのエージェントのモバイルノードに関するホームアドレス。
MN: mobile node.
ミネソタ: モバイルノード。
NAI: Network Access Identifier [RFC4282].
NAI: アクセス識別子[RFC4282]をネットワークでつないでください。
R: router.
R: ルータ。
VPN: Virtual Private Network based on IPsec.
VPN: 仮想の兵士のNetworkはIPsecを基礎づけました。
VPN-TIA: VPN tunnel inner address, the address(es) negotiated
during IKE phase 2 (quick mode), assigned manually, using IPsec-
DHCP [RFC3456], using the "de facto" standard Internet Security
Association and Key Management Protocol (ISAKMP) configuration
mode, or by some other means. Some VPN clients use their current
care-of address as their Tunnel Inner Address (TIA) for
architectural reasons.
VPN-ティア: VPNは内側のアドレス、手動で割り当てられたIKE段階2(迅速なモード)の間にIPsec- DHCP[RFC3456]を使用することで交渉されたアドレス(es)にトンネルを堀ります、「事実上」の標準のインターネットSecurity AssociationとKey Managementプロトコル(ISAKMP)構成モードを使用するか、またはある他の手段で。 何人かのVPNクライアントが彼らの電流を使用する、注意、-、彼らのTunnel Inner Addressとして、建築理由で(TIA)を扱ってください。
VPN tunnel: an IPsec-based tunnel; for instance, IPsec tunnel mode
IPsec connection, or Layer 2 Tunneling Protocol (L2TP) combined
with IPsec transport connection.
VPNはトンネルを堀ります: IPsecベースのトンネル。 例えば、IPsecはモードIPsec接続にトンネルを堀るか、またはLayer2Tunnelingプロトコル(L2TP)はIPsec輸送接続に結合しました。
x-FA: Mobile IPv4 foreign agent residing in the external network.
x-ファ: 外部のネットワークで住んでいるモバイルIPv4外国人のエージェント。
x-HA: Mobile IPv4 home agent residing in the external network.
x、-、ハ、: 外部のネットワークで住んでいるモバイルIPv4ホームのエージェント。
x-HoA: home address of the mobile node in the external home agent.
x-HoA: 外部のホームのエージェントのモバイルノードに関するホームアドレス。
1.5. Requirement Levels
1.5. 要件レベル
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
Vaarala & Klovning Standards Track [Page 6] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[6ページ]。
1.6. Assumptions and Rationale
1.6. 仮定と原理
The solution is an attempt to solve the problem described in [RFC4093]. The major assumptions and their rationale is summarized below.
ソリューションは[RFC4093]で説明された問題を解決する試みです。 主要な仮定とそれらの原理は以下へまとめられます。
Changes to existing firewall and VPN deployments should be minimized:
既存のファイアウォールとVPN展開への変化は最小にされるべきです:
o The current deployment of firewalls and IPsec-based VPNs is much
larger than corresponding Mobile IPv4 elements. Thus, a solution
should work within the existing VPN infrastructure.
o ファイアウォールとIPsecベースのVPNsの現在の展開は対応するモバイルIPv4要素よりはるかに大きいです。 したがって、ソリューションは既存のVPNインフラストラクチャの中で働くべきです。
o Current enterprise network deployments typically centralize
management of security and network access into a compact DMZ.
o 現在の企業網展開はセキュリティとネットワークアクセスの管理をコンパクトなDMZに通常集結します。
When the mobile node is inside, traffic should not go through the DMZ network:
モバイルノードが中にあるとき、トラフィックはDMZネットワークに直面するべきではありません:
o Routing all mobile node traffic through the DMZ is seen as a
performance problem in existing deployments of firewalls. The
more sophisticated firewall technology is used (e.g., content
scanning), the more serious the performance problem is.
o DMZを通してすべてのモバイルノードトラフィックを発送するのはファイアウォールの既存の展開における性能問題と考えられます。 より多くの高度なファイアウォール技術が使用されれば(例えば内容がスキャンされて)使用するほど、性能問題は、より重大です。
o Current deployments of firewalls and DMZs in general have been
optimized for the case where only a small minority of total
enterprise traffic goes through the DMZ. Furthermore, users of
current VPN remote access solutions do not route their traffic
through the DMZ when connected to an internal network.
o ファイアウォールと一般に、DMZsの現在の展開は総企業トラフィックのわずかな数の小数だけがDMZを通るケースのために最適化されました。 その上、内部のネットワークに関連づけられる場合、現在のVPN遠隔アクセスのソリューションのユーザはDMZを通してそれらのトラフィックを発送しません。
A home agent inside the enterprise cannot be reached directly from outside, even if the home agent contains IPsec functionality:
ホームのエージェントがIPsecの機能性を含んでも、直接外部から企業の中のホームのエージェントに連絡できません:
o Deployment of current combined IPsec/MIPv4 solutions are not
common in large installations.
o 現在の結合したIPsec/MIPv4ソリューションの展開は大きいインストールで一般的ではありません。
o Doing decryption in the home agents "deep inside" the enterprise
effectively means having a security perimeter much larger than the
typical, compact DMZ used by a majority of enterprises today.
o 有効に「中で深い」ホームのエージェントの復号化に企業をするのは、セキュリティ周辺を今日企業の大部分によって使用されている典型的で、コンパクトなDMZよりはるかに大きくすることを意味します。
o In order to maintain a security level equal to current firewall/
DMZ deployments, every home agent decapsulating IPsec would need
to do the same firewalling as the current DMZ firewalls (content
scanning, connection tracking, etc.).
o 現在のファイアウォール/DMZ展開と等しくセキュリティー・レベルを維持するために、あらゆるホームのエージェントdecapsulating IPsecが、現在のDMZファイアウォール(満足しているスキャン、接続追跡など)としてfirewallingしながら同じようにする必要があるでしょう。
Vaarala & Klovning Standards Track [Page 7] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[7ページ]。
Traffic cannot be encrypted when the mobile node is inside:
モバイルノードが以下にあるとき、トラフィックを暗号化できません。
o There is a considerable performance impact on home agents (which
currently do rather light processing) and mobile nodes (especially
for small devices). Note that traffic throughput inside the
enterprise is typically an order (or more) of magnitude larger
than the remote access traffic through a VPN.
o ホームのエージェント(現在、かなり軽い処理をします)とモバイルノード(特に小さいデバイスのための)の上にかなりの性能影響があります。 通常、企業の中のトラフィックスループットがVPNを通して、遠く離れたアクセス交通量より大きい大きさの注文(さらに)であることに注意してください。
o Encryption consumes processing power and has a significant impact
on device battery life.
o 暗号化は、デバイスのバッテリーの寿命で処理能力を消費して、重要な影響を与えます。
o There is also a usability issue involved; the user needs to
authenticate the connection to the IPsec layer in the home agent
to gain access. For interactive authentication mechanisms (e.g.,
SecurID), this always means user interaction.
o また、かかわったユーザビリティ問題があります。 ユーザは、アクセサリーを獲得するためにホームのエージェントでIPsec層に接続を認証する必要があります。 対話的な認証機構(例えば、SecurID)のために、これはいつもユーザ相互作用を意味します。
o Furthermore, if there is a separate VPN device in the DMZ for
remote access, the user needs to authenticate to both devices, and
might need to have separate credentials for both.
o その上、別々のVPNデバイスが遠隔アクセスのためのDMZにあれば、ユーザは、両方にデバイスを認証するのが必要であり、両方のための別々の資格証明書を必要とするかもしれません。
o Current Mobile IPv4 home agents do not typically incorporate IPsec
functionality, which is relevant for the solution when we assume
zero or minimal changes to existing Mobile IPv4 nodes.
o 現在のモバイルIPv4ホームのエージェントはIPsecの機能性を通常取り入れません。(私たちがゼロか最小量の変化を仮定するとき、ソリューションにおいて、それは、既存のモバイルIPv4ノードに関連しています)。
o Note, however, that the assumption (no encryption when inside)
does not necessarily apply to all solutions in the solution space;
if the above mentioned problems were resolved, there is no
fundamental reason why encryption could not be applied when
inside.
o しかしながら、仮定(内部であることの暗号化がない)が必ずソリューションスペースのすべてのソリューションに適用されるというわけではないことに注意してください。 上記の問題が解決されたなら、内部であるときに暗号化を適用できなかった基本的な理由が全くありません。
1.7. Why IPsec Lacks Mobility
1.7. IPsecが機動性を欠く理由
IPsec, as currently specified [RFC4301], requires that a new IKE negotiation be done whenever an IPsec peer moves, i.e., changes care-of address. The main reason is that a security association is unidirectional and identified by a triplet consisting of (1) the destination address (which is the outer address when tunnel mode is used), (2) the security protocol (Encapsulating Security Payload (ESP) or Authentication Header (AH)), and (3) the Security Parameter Index (SPI) ([RFC4301], Section 4.1). Although an implementation is not required to use all of these for its own Security Associations (SAs), an implementation cannot assume that a peer does not.
現在指定されているとしてのIPsec[RFC4301]は、IPsec同輩が移行するときはいつも、新しいIKE交渉をするのを必要とします、すなわち、変化、注意、-、アドレス。 (2) 主な理由はセキュリティ協会が単方向ということです、そして、(1) 送付先アドレス(トンネルモードが使用されているとき、外側のアドレスである)から成る三つ子によって特定されて、セキュリティは(Security有効搭載量(超能力)かAuthentication Header(AH)と、(3)がSecurity Parameter Index(SPI)[RFC4301]であるとカプセル化するセクション4.1)について議定書の中で述べます。 実装はそれ自身のSecurity Associations(SAs)にこれらをすべて、使用するのに必要ではありませんが、実装は、同輩がそうしないと仮定できません。
When a mobile IPsec peer sends packets to a stationary IPsec peer, there is no problem; the SA is "owned" by the stationary IPsec peer, and therefore the destination address does not need to change. The (outer) source address should be ignored by the stationary peer (although some implementations do check the source address as well).
モバイルIPsec同輩が静止したIPsec同輩にパケットを送るとき、問題が全くありません。 SAは静止したIPsec同輩によって「所有されています」、そして、したがって、送付先アドレスは変化する必要はありません。 (外側)のソースアドレスは静止した同輩によって無視されるべきです(いくつかの実装がまた、ソースアドレスをチェックしますが)。
Vaarala & Klovning Standards Track [Page 8] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[8ページ]。
The problem arises when packets are sent from the stationary peer to the mobile peer. The destination address of this SA (SAs are unidirectional) is established during IKE negotiation, and is effectively the care-of address of the mobile peer at time of negotiation. Therefore, the packets will be sent to the original care-of address, not a changed care-of address.
静止した同輩からモバイル同輩にパケットを送るとき、問題は起こります。 このSA(SAsは単方向である)の送付先アドレスがIKE交渉の間、設立されて、事実上、設立される、注意、-、交渉の時間のモバイル同輩のアドレス。 したがって、パケットを送る、オリジナル、注意、-、アドレス、aが変化した、注意、-、アドレス
The IPsec NAT traversal mechanism can also be used for limited mobility, but UDP tunneling needs to be used even when there is no NAT in the route between the mobile and the stationary peers. Furthermore, support for changes in current NAT mapping is not required by the NAT traversal specification [RFC3947].
また、限られた移動性にIPsec NAT縦断メカニズムを使用できますが、UDPトンネリングは、NAT全くモバイルと静止した同輩の間のルートにないときさえ、使用される必要があります。 その上、現在のNATマッピングにおける変化のサポートはNAT縦断仕様[RFC3947]によって必要とされません。
In summary, although the IPsec standard does not as such prevent mobility (in the sense of updating security associations on-the-fly), the standard does not include a built-in mechanism (explicit or implicit) for doing so. Therefore, it is assumed throughout this document that any change in the addresses comprising the identity of an SA requires IKE re-negotiation, which implies too heavy computation and too large latency for useful mobility.
概要では、IPsec規格はそういうものとして、移動性(急いでセキュリティ協会をアップデートするという意味における)を防ぎませんが、規格はそうするのにおける、(明白であるか暗黙)の内蔵のメカニズムを含んでいません。 したがって、このドキュメント中でSAのアイデンティティを包括するアドレスにおけるどんな変化もIKE再交渉を必要とすると思われます。(交渉は役に立つ移動性のために重過ぎる計算と大き過ぎる潜在を含意します)。
The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555] provides better mobility for IPsec. This would allow the external Mobile IPv4 layer described in this specification to be removed. However, deploying MOBIKE requires changes to VPN devices, and is thus out of scope of this specification.
IKEv2 MobilityとMultihomingプロトコル(MOBIKE)[RFC4555]は、より良い移動性をIPsecに供給します。 これは、この仕様で説明された外部のモバイルIPv4層が取り除かれるのを許容するでしょう。 しかしながら、その結果、MOBIKEが必要とする展開は、VPNデバイスに変化して、この仕様の範囲の外にあります。
2. The Network Environment
2. ネットワーク環境
Enterprise users will access both the internal and external networks using different networking technologies. In some networks, the MN will use FAs and in others it will anchor at the HA using co-located mode. The following figure describes an example network topology illustrating the relationship between the internal and external networks, and the possible locations of the mobile node (i.e., (MN)).
異なったネットワーク・テクノロジーを使用することでエンタープライズユーザは両方の内部の、そして、外部のネットワークにアクセスするでしょう。 いくつかのネットワークでは、ミネソタはFAsを使用するでしょう、そして、他のものでは、それは、HAで共同見つけられたモードを使用することで投錨されるでしょう。 以下の図は内部の、そして、外部のネットワークと、モバイルノードの可能な位置(すなわち、(ミネソタ))との関係を例証する例のネットワーク形態について説明します。
Vaarala & Klovning Standards Track [Page 9] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[9ページ]。
(MN) {fvc} {home} (MN) [i-HA]
! \ /
.--+---. .-+---+-.
( ) ( )
`--+---' [VPN] `--+----'
\ ! !
[R/FA] [x-HA] .--+--. [R]
\ / ( DMZ ) !
.-+-------+--. `--+--' .-----+------.
( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( )
`--+---------' `---+---+----'
/ / \
[DHCP] [R] [DHCP] [R] [R] [i-FA]
\ / \ / \ /
.+--+---. .-+-+--. .--+--+-.
( ) ( ) ( )
`---+---' `--+---' `---+---'
! ! !
(MN) {cvc} (MN) {c} (MN) {f}
(ミネソタ)fvcが家へ帰る、(ミネソタ)[i、-、ハ、]、\/、--、+---. .-+---+-. ( ) ( ) `--+---'[VPN]'--+、'----'\![R/ファ]、[x、-、ハ、]. . [R] --+--\/(非武装地帯!).-+、'-------+--. `--+--' .-----+------. ( ) ! ( ) (外部が+--[R]を網で覆う、-、-、--、[FW] ----[R]--+ 内部のネット) ( ) ( ) `--+---------' `---+---+----'//\[DHCP][R][DHCP][R][R][i-ファ]\/\/\/+--+'---. .-+-+--. .--+--+-. ( ) ( ) ( ) `---+---' `--+---' `---+---'(Mn)cvc(ミネソタ)c(ミネソタ)'f
Figure 1: Basic topology, possible MN locations, and access modes
図1: 基本的なトポロジー、可能なミネソタの位置、およびアクセス・モード
In every possible location described in the figure, the mobile node can establish a connection to the corresponding HA(s) by using a suitable "access mode". An access mode is here defined to consist of:
図で説明されたあらゆる可能な位置では、モバイルノードが、適当な「アクセス・モード」を使用することによって、対応するHA(s)に取引関係を築くことができます。 以下から成るように定義されて、アクセス・モードがここにあります。
1. a composition of the mobile node networking stack (i-MIP or
x-MIP/VPN/i-MIP); and
1. モバイルノードネットワークスタック(i-MIPかx-MIP/VPN/i-MIP)の構成。 そして
2. registration mode(s) of i-MIP and x-MIP (if used); i.e., co-
located care-of address or foreign agent care-of address.
2. i-MIPとx-MIP(使用されるなら)の登録モード。 すなわち、共同、-、場所を見つける、注意、-、アドレスか外国人のエージェント、注意、-、アドレス。
Each possible access mode is encoded as "xyz", where:
それぞれの可能なアクセス・モードは"xyz"、どことしてコード化されるか:
o "x" indicates whether the x-MIP layer is used, and if used, the
mode ("f" indicates FA-CoA, "c" indicates co-CoA, absence
indicates not used);
o x-MIP層が使用されていて、使用されるなら「x」が示す、モード(「f」は、FA-CoA、「c」が共同CoAを示すのを示します、と使用されて、不在は示しません)。
o "y" indicates whether the VPN layer is used ("v" indicates VPN
used, absence indicates not used); and
o 「y」は、VPN層が使用されているかどうかを(使用されて、不在は、「v」が、VPNが使用したのを示すのを示しません)示します。 そして
o "z" indicates mode of i-MIP layer ("f" indicates FA-CoA, "c"
indicates co-CoA).
o 「z」はi-MIP層のモードを示します(「f」は、FA-CoA、「c」が共同CoAを示すのを示します)。
Vaarala & Klovning Standards Track [Page 10] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[10ページ]。
This results in four access modes:
これは4つのアクセス・モードをもたらします:
c: i-MIP with co-CoA
f: i-MIP with FA-CoA
cvc: x-MIP with co-CoA, VPN-TIA as i-MIP co-CoA
fvc: x-MIP with FA-CoA, VPN-TIA as i-MIP co-CoA
c: 共同CoA fとi-MIP: FA-CoA cvcとi-MIP: 共同CoAとx-MIP、i-MIP共同CoA fvcとしてのVPN-TIA: ファ-CoAとx-MIP、i-MIPココアとしてのVPN-TIA
This notation is more useful when optimizations to protocol layers are considered. The notation is preserved here so that work on the optimizations can refer to a common notation.
プロトコル層への最適化が考えられるとき、この記法は、より役に立ちます。 記法は、最適化に対する仕事が一般的な記法を示すことができるように、ここに保存されます。
The internal network is typically a multi-subnetted network using private addressing [privaddr]. Subnets may contain internal home agent(s), DHCP server(s), and/or foreign agent(s). Current IEEE 802.11 wireless LANs are typically deployed in the external network or the DMZ because of security concerns.
通常、内部のネットワークは個人的なアドレシング[privaddr]を使用するマルチサブネット化したネットワークです。 サブネットは内部のホームのエージェント、DHCPサーバ、そして/または、外国人のエージェントを含むかもしれません。 現在のIEEE802.11無線LANは安全上の配慮のために外部のネットワークかDMZで通常配布されます。
The figure leaves out a few details worth noticing:
図は気付く価値があるいくつかの詳細を省きます:
o There may be multiple NAT devices anywhere in the diagram.
o 複数のNATデバイスがどこでもダイヤグラムであるかもしれません。
* When the MN is outside, the NAT devices may be placed between
the MN and the x-HA or the x-HA and the VPN.
* ミネソタが外にあるとき、NATデバイスはミネソタとx-HAかx-HAとVPNの間に置かれるかもしれません。
* There may also be NAT(s) between the VPN and the i-HA, or a NAT
integrated into the VPN. In essence, any router in the figure
may be considered to represent zero or more routers, each
possibly performing NAT and/or ingress filtering.
* また、VPNとi-HAの間には、NATがあったかもしれませんか、またはNATはVPNと統合されました。 本質では、図のどんなルータもゼロを表すと考えられるかもしれませんか、または、より多くのルータ、それぞれのことによると働いているNAT、そして/または、イングレスはフィルターにかけています。
* When the MN is inside, there may be NAT devices between the MN
and the i-HA.
* ミネソタが中にあるとき、ミネソタとi-HAの間には、NATデバイスがあるかもしれません。
o Site-to-site VPN tunnels are not shown. Although mostly
transparent, IPsec endpoints may perform ingress filtering as part
of enforcing their policy.
o サイトからサイトへのVPNトンネルは見せられません。 ほとんど透明ですが、IPsec終点は実施の一部としてそれらの方針をフィルターにかけるイングレスを実行するかもしれません。
o The figure represents a topology where each functional entity is
illustrated as a separate device. However, it is possible that
several network functions are co-located in a single device. In
fact, all three server components (x-HA, VPN, and i-HA) may be co-
located in a single physical device.
o 図はそれぞれの機能的な実体が別々のデバイスとして例証されるトポロジーを表します。 しかしながら、いくつかのネットワーク機能が単一のデバイスに共同位置しているのは、可能です。 事実上、すべての3つのサーバコンポーネント(x-HA、VPN、およびi-HA)が単一のフィジカル・デバイスに共同位置するかもしれません。
The following issues are also important when considering enterprise mobile users:
また、企業のモバイルユーザを考えるとき、以下の問題も重要です:
o Some firewalls are configured to block ICMP messages and/or
fragments. Such firewalls (routers) cannot be detected reliably.
o いくつかのファイアウォールが、ICMPメッセージ、そして/または、断片を妨げるために構成されます。 そのようなファイアウォール(ルータ)を確かに検出できません。
Vaarala & Klovning Standards Track [Page 11] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[11ページ]。
o Some networks contain transparent application proxies, especially
for HTTP. Like firewalls, such proxies cannot be detected
reliably in general. IPsec and Mobile IPv4 are incompatible with
such networks.
o 特にHTTPのための透明なアプリケーションプロキシを含むネットワークもあります。 一般に、ファイアウォールのように、そのようなプロキシを確かに検出できません。 IPsecとモバイルIPv4はそのようなネットワークと非互換です。
Whenever a mobile node obtains either a co-CoA or an FA-CoA, the following conceptual steps take place:
モバイルノードが共同CoAかFA-CoAのどちらかを入手するときはいつも、以下の概念的なステップは行われます:
o The mobile node detects whether the subnet where the care-of
address was obtained belongs to the internal or the external
network using the method described in Section 3 (or a vendor-
specific mechanism fulfilling the requirements described).
o モバイルノードが検出する、サブネット、どこ、注意、-、アドレス、得たか、セクション3(または、要求にこたえるのが説明したベンダーの特定のメカニズム)で説明されたメソッドを使用することで内部のネットワークか外部のネットワークに属します。
o The mobile node performs necessary registrations and other
connection setup signaling for the protocol layers (in the
following order):
o モバイルノードはプロトコル層(以下のオーダーにおける)のために必要な登録証明書と他の接続設定シグナリングを実行します:
* x-MIP (if used);
* x-MIP(使用されるなら)。
* VPN (if used); and
* VPN(使用されるなら)。 そして
* i-MIP.
* i-MIP。
Note that these two tasks are intertwined to some extent: detection of the internal network results in a successful registration to the i-HA using the proposed network detection algorithm. An improved network detection mechanism not based on Mobile IPv4 registration messages might not have this side effect.
これらの2つのタスクがある程度からみ合うことに注意してください: 内部のネットワークの検出は、提案されたネットワーク検出アルゴリズムを使用することでi-HAへのうまくいっている登録をもたらします。 モバイルIPv4登録メッセージに基づかない改良されたネットワーク検出メカニズムはこの副作用を持っていないかもしれません。
The following subsections describe the different access modes and the requirements for registration and connection setup phase.
以下の小区分は登録と接続設定のためのモードと要件が位相を合わせる異なったアクセスについて説明します。
2.1. Access Mode: 'c'
2.1. モードにアクセスしてください: 'c'
This access mode is standard Mobile IPv4 [RFC3344] with a co-located address, except that:
このアクセス・モードはそれを除いた共同見つけられたアドレスがある標準のモバイルIPv4[RFC3344]です:
o the mobile node MUST detect that it is in the internal network;
and
o ノードが検出しなければならない内部のネットワークにはそれがあるモバイル。 そして
o the mobile node MUST re-register periodically (with a configurable
interval) to ensure it is still inside the internal network (see
Section 4).
o モバイルノードは、まだ内部のネットワークの中にそれがあるのを(セクション4を見てください)保証するために定期的(構成可能な間隔で)に再登録しなければなりません。
Vaarala & Klovning Standards Track [Page 12] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[12ページ]。
2.2. Access Mode: 'f'
2.2. モードにアクセスしてください: 'f'
This access mode is standard Mobile IPv4 [RFC3344] with a foreign agent care-of address, except that
このアクセス・モードが外国人のエージェントがいる標準のモバイルIPv4[RFC3344]である、注意、-、それを除いたアドレス
o the mobile node MUST detect that it is in the internal network;
and
o ノードが検出しなければならない内部のネットワークにはそれがあるモバイル。 そして
o the mobile node MUST re-register periodically (with a configurable
interval) to ensure it is still inside the internal network (see
Section 4).
o モバイルノードは、まだ内部のネットワークの中にそれがあるのを(セクション4を見てください)保証するために定期的(構成可能な間隔で)に再登録しなければなりません。
2.3. Access Mode: 'cvc'
2.3. モードにアクセスしてください: 'cvc'
Steps:
以下のステップ:
o The mobile node obtains a care-of address.
o モバイルノードがaを得る、注意、-、アドレス。
o The mobile node detects it is not inside and registers with the
x-HA, where
o モバイルノードが検出する、それは、x-HA、どこがある内部とレジスタでないか。
* T-bit MAY be set (reverse tunneling), which minimizes the
probability of firewall-related connectivity problems
* T-ビット(ファイアウォール関連の接続性問題の確率を最小にする)は設定されるかもしれません(トンネリングを逆にします)。
o If the mobile node does not have an existing IPsec security
association, it uses IKE to set up an IPsec security association
with the VPN gateway, using the x-HoA as the IP address for IKE/
IPsec communication. How the VPN-TIA is assigned is outside the
scope of this document.
o モバイルノードに既存のIPsecセキュリティ協会がないなら、VPNゲートウェイとのIPsecセキュリティ協会を設立するのにIKEを使用します、IKE/ IPsecコミュニケーションにIPアドレスとしてx-HoAを使用して。 このドキュメントの範囲の外にVPN-TIAがどう割り当てられるかがあります。
o The mobile node sends a MIPv4 Registration Request (RRQ) to the
i-HA, registering the VPN-TIA as a co-located care-of address,
where
o モバイルノードがi-HA、aとしてのVPN-TIAが共同場所を見つけた登録にMIPv4 Registration Request(RRQ)を送る、注意、-、アドレス、どこ
* T-bit SHOULD be set (reverse tunneling) (see discussion below)
* セットが(逆のトンネリング)であったならSHOULDにt噛み付きます。(以下での議論を見ます)
Reverse tunneling in the inner Mobile IPv4 layer is often required because of IPsec security policy limitations. IPsec selectors define allowed IP addresses for packets sent inside the IPsec tunnel. Typical IPsec remote VPN selectors restrict the client address to be VPN-TIA (remote address is often unrestricted). If reverse tunneling is not used, the source address of a packet sent by the MN will be the MN's home address (registered with i-HA), which is different from the VPN-TIA, thus violating IPsec security policy. Consequently, the packet will be dropped, resulting in a connection black hole.
内側のモバイルIPv4層の逆のトンネリングがIPsec安全保障政策制限のためにしばしば必要です。 IPsecセレクタはIPsecトンネルの中で送られたパケットのための許容IPアドレスを定義します。 典型的なIPsecリモートVPNセレクタは、VPN-TIAになるようにクライアントアドレスを制限します(リモートアドレスはしばしば無制限です)。 逆のトンネリングが使用されていないと、ミネソタによって送られたパケットのソースアドレスはミネソタのホームアドレスになるでしょう(i-HAとともに記名します)、その結果、IPsec安全保障政策に違反します。(それは、VPN-TIAと異なっています)。 その結果、接続ブラックホールをもたらすと、パケットは下げられるでしょう。
Vaarala & Klovning Standards Track [Page 13] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[13ページ]。
Some types of IPsec-based VPNs, in particular L2TP/IPsec VPNs (PPP- over-L2TP-over-IPsec), do not have this limitation and can use triangular routing.
IPsecベースのVPNsの何人かのタイプ(特にL2TP/IPsec VPNs(PPP過剰L2TP過剰IPsec))が、この制限を持たないで、三角形のルーティングを使用できます。
Note that although the MN can use triangular routing, i.e., skip the inner MIPv4 layer, it MUST NOT skip the VPN layer for security reasons.
ミネソタが三角形のルーティング、すなわち、内側のMIPv4が層にするスキップを使用できますが、安全保障上の理由でVPN層をスキップしてはいけないことに注意してください。
2.4. Access Mode: 'fvc'
2.4. モードにアクセスしてください: 'fvc'
Steps:
以下のステップ:
o The mobile node obtains a foreign agent advertisement from the
local network.
o モバイルノードは企業内情報通信網から外国エージェント広告を得ます。
o The mobile node detects it is outside and registers with the x-HA,
where
o モバイルノードが検出する、それは、x-HA、どこがある外部とレジスタであるか。
* T-bit MAY be set (reverse tunneling), which minimizes the
probability of firewall-related connectivity problems
* T-ビット(ファイアウォール関連の接続性問題の確率を最小にする)は設定されるかもしれません(トンネリングを逆にします)。
o If necessary, the mobile node uses IKE to set up an IPsec
connection with the VPN gateway, using the x-HoA as the IP address
for IKE/IPsec communication. How the VPN-TIA is assigned is
outside the scope of this document.
o 必要なら、モバイルノードはVPNゲートウェイとのIPsec接続をセットアップするのにIKEを使用します、IKE/IPsecコミュニケーションにIPアドレスとしてx-HoAを使用して。 このドキュメントの範囲の外にVPN-TIAがどう割り当てられるかがあります。
o The mobile node sends a MIPv4 RRQ to the i-HA, registering the
VPN-TIA as a co-located care-of address, where
o モバイルノードがi-HA、aとしてのVPN-TIAが共同場所を見つけた登録にMIPv4 RRQを送る、注意、-、アドレス、どこ
* T-bit SHOULD be set (reverse tunneling) (see discussion in
Section 2.3)
* セットが(逆のトンネリング)であったならSHOULDにt噛み付きます。(セクション2.3で議論を見ます)
Note that although the MN can use triangular routing, i.e., skip the inner MIPv4 layer, it MUST NOT skip the VPN layer for security reasons.
ミネソタが三角形のルーティング、すなわち、内側のMIPv4が層にするスキップを使用できますが、安全保障上の理由でVPN層をスキップしてはいけないことに注意してください。
2.5. NAT Traversal
2.5. NAT縦断
NAT devices may affect each layer independently. Mobile IPv4 NAT traversal [mipnat] SHOULD be supported for x-MIP and i-MIP layers, while IPsec NAT traversal [RFC3947][RFC3948] SHOULD be supported for the VPN layer.
NATデバイスは独自に各層に影響するかもしれません。 モバイルIPv4NAT縦断[mipnat]SHOULDがx-MIPとi-MIP層のためにサポートされて、VPN層のためにIPsec NAT縦断[RFC3947][RFC3948]SHOULDである間、サポートされてください。
Note that NAT traversal for the internal MIPv4 layer may be necessary even when there is no separate NAT device between the VPN gateway and the internal network. Some VPN implementations NAT VPN tunnel inner addresses before routing traffic to the intranet. Sometimes this is done to make a deployment easier, but in some cases this approach
VPNゲートウェイと内部のネットワークの間にどんな別々のNATデバイスさえもないときさえ、内部のMIPv4層のためのNAT縦断が必要であるかもしれないことに注意してください。 トラフィックをイントラネットに発送する前に、いくらかのVPN実装NAT VPNが内側のアドレスにトンネルを堀ります。 時々、展開をより簡単にするようにこれをして、いくつかの場合唯一のこれはアプローチです。
Vaarala & Klovning Standards Track [Page 14] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[14ページ]。
makes VPN client implementation easier. Mobile IPv4 NAT traversal is required to establish a MIPv4 session in this case.
VPNクライアント実装をより簡単にします。 モバイルIPv4NAT縦断が、この場合MIPv4セッションを確立するのに必要です。
3. Internal Network Detection
3. 内部のネットワーク検出
Secure detection of the internal network is critical to prevent plaintext traffic from being sent over an untrusted network. In other words, the overall security (confidentiality and integrity of user data) relies on the security of the internal network detection mechanism in addition to IPsec. For this reason, security requirements are described in this section.
内部のネットワークの安全な検出は、平文トラフィックが信頼されていないネットワークの上に送られるのを防ぐために重要です。 言い換えれば、総合的なセキュリティ(利用者データの秘密性と保全)はIPsecに加えた内部のネットワーク検出メカニズムのセキュリティを当てにします。 この理由で、セキュリティ要件はこのセクションで説明されます。
In addition to detecting entry into the internal network, the mobile node must also detect when it has left the internal network. Entry into the internal network is easier security-wise: the mobile node can ensure that it is inside the internal network before sending any plaintext traffic. Exit from the internal network is more difficult to detect, and the MN may accidentally leak plaintext packets if the event is not detected in time.
また、内部のネットワークにエントリーを検出することに加えて、モバイルノードは、それがいつ内部のネットワークを出たかを検出しなければなりません。 セキュリティが教えた状態で、内部のネットワークへのエントリーは、より簡単です: モバイルノードは、どんな平文トラフィックも送る前に、内部のネットワークの中にそれがあるのを確実にすることができます。 内部のネットワークからの出口は検出するのが、より難しいです、そして、イベントが時間内に検出されないなら、ミネソタは偶然平文パケットを漏らすかもしれません。
Several events can cause the mobile node to leave the internal network, including:
いくつかのイベントで、モバイルノードは内部のネットワーク、包含を残すことができます:
o a routing change upstream;
o ルーティング変化上流。
o a reassociation of 802.11 on layer 2 that the mobile node software
does not detect;
o モバイルノードソフトウェアが検出しない層2の802.11の「再-協会」。
o a physical cable disconnect and reconnect that the mobile node
software does not detect.
o 物理ケーブルは、それから切断して、再接続します。ソフトウェアが検出しないモバイルノード。
Whether the mobile node can detect such changes in the current connection reliably depends on the implementation and the networking technology. For instance, some mobile nodes may be implemented as pure layer three entities. Even if the mobile node software has access to layer 2 information, such information is not trustworthy security-wise, and depends on the network interface driver.
モバイルノードが現在の接続におけるそのような変化を検出できるかどうかが実装とネットワーク・テクノロジーに確かによります。 例えば、いくつかのモバイルノードが純粋な層threeの実体として実装されるかもしれません。 モバイルノードソフトウェアに2情報を層にするアクセスがあっても、そのような情報は、セキュリティが教えた状態で信頼できないで、ネットワーク・インターフェースドライバーに頼っています。
If the mobile node does not detect these events properly, it may leak plaintext traffic into an untrusted network. A number of approaches can be used to detect exit from the internal network, ranging from frequent re-registration to the use of layer two information.
モバイルノードが適切にこれらのイベントを検出しないなら、それは平文トラフィックを信頼されていないネットワークに漏らすかもしれません。 内部のネットワークから出口を検出するのに多くのアプローチを使用できます、層の使用への頻繁な再登録2情報から変化して。
A mobile node MUST implement a detection mechanism fulfilling the requirements described in Section 3.2; this ensures that basic security requirements are fulfilled. The basic algorithm described in Section 3.3 is one way to do that, but alternative methods may be used instead or in conjunction. The assumptions that the
モバイルノードは要求にこたえるのがセクション3.2で説明した検出メカニズムを実装しなければなりません。 これは、基本のセキュリティ要件が実現するのを確実にします。 セクション3.3で説明された基本的なアルゴリズムはそれをすることにおいて一方通行ですが、別法は代わりにか接続詞に使用されるかもしれません。 仮定、それ
Vaarala & Klovning Standards Track [Page 15] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[15ページ]。
requirements and the proposed mechanism rely upon are described in Section 3.1.
メカニズムが当てにする要件と提案はセクション3.1で説明されます。
3.1. Assumptions
3.1. 仮定
The enterprise firewall MUST be configured to block traffic originating from external networks going to the i-HA. In other words, the mobile node MUST NOT be able to perform a successful Registration Request/Registration Reply (RRQ/RRP) exchange (without using IPsec) unless it is connected to the trusted internal network; the mobile node can then stop using IPsec without compromising data confidentiality.
i-HAに行く外部のネットワークから発しながら交通の妨害になるように企業ファイアウォールを構成しなければなりません。 言い換えれば、それが信じられた内部のネットワークに関連づけられない場合、モバイルノードはうまくいっているRegistration Request/登録Reply(RRQ/RRP)交換(IPsecを使用することのない)を実行できるはずがありません。 そして、モバイルノードは、データが秘密性であると感染しないIPsecを使用するのを止めることができます。
If this assumption does not hold, data confidentiality is compromised in a potentially silent and thus dangerous manner. To minimize the impact of this scenario, the i-HA is also required to check the source address of any RRQ to determine whether it comes from a trusted (internal network) address. The i-HA needs to indicate to the MN that it supports the checking of trusted source addresses by including a Trusted Networks Configured extension in its registration reply. This new extension, which needs to be implemented by both i-HA and the MN, is described in Section 3.4.
この仮定が成立しないなら、潜在的に静かでその結果、危険な方法でデータの機密性は感染されます。 また、このシナリオの影響を最小にするために、i-HAはそれが信じられた(内部のネットワーク)アドレスから来るかどうか決定するためにどんなRRQのソースアドレスもチェックしなければなりません。 i-HAは、登録回答におけるTrusted Networks Configured拡張子を含んでいることによって信頼できるソースアドレスの照合をサポートするのをミネソタに示す必要があります。 この新しい拡張子(i-HAとミネソタの両方によって実装される必要がある)はセクション3.4で説明されます。
The firewall MAY be configured to block registration traffic to the x-HA originating from within the internal network, which makes the network detection algorithm simpler and more robust. However, as the registration request is basically UDP traffic, an ordinary firewall (even a stateful one) would typically allow the registration request to be sent and a registration reply to be received through the firewall.
ファイアウォールは、中からネットワーク検出アルゴリズムをより簡単でより強健にする内部のネットワークを溯源するx-HAに登録トラフィックを妨げるために構成されるかもしれません。 しかしながら、登録要求が基本的にUDPトラフィックであるので、普通のファイアウォール(stateful1つさえ)は、送られるという登録要求と登録回答がファイアウォールを通して受け取られるのを通常許容するでしょう。
3.2. Implementation Requirements
3.2. 実装要件
Any mechanism used to detect the internal network MUST fulfill the requirements described in this section. An example of a network detection mechanism fulfilling these requirements is given in Section 3.3.
内部のネットワークを検出するのに使用されるどんなメカニズムもこのセクションで説明された要件を実現させなければなりません。 これらの要件を実現させるネットワーク検出メカニズムに関する例はセクション3.3で出されます。
3.2.1. Separate Tracking of Network Interfaces
3.2.1. ネットワーク・インターフェースの別々の追跡
The mobile node implementation MUST track each network interface separately. Successful registration with the i-HA through interface X does not imply anything about the status of interface Y.
モバイルノード実装は別々に各ネットワーク・インターフェースを追跡しなければなりません。 インタフェースXを通してi-HAがあるうまくいっている登録はインタフェースYの状態に関して何も含意しません。
3.2.2. Connection Status Change
3.2.2. 接続形態変化
When the mobile node detects that its connection status on a certain network interface changes, the mobile node MUST:
モバイルノードがそれを検出するとき、あるネットワーク・インターフェースの接続形態は変化して、モバイルノードはそうしなければなりません:
Vaarala & Klovning Standards Track [Page 16] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[16ページ]。
o immediately stop relaying user data packets;
o 至急、ユーザデータ・パケットをリレーするのを止めてください。
o detect whether this interface is connected to the internal or the
external network; and
o このインタフェースが内部のネットワークか外部のネットワークに関連づけられるかどうか検出してください。 そして
o resume data traffic only after the internal network detection and
necessary registrations and VPN tunnel establishment have been
completed.
o 内部のネットワーク検出、必要な登録証明書、およびVPNトンネル設立が終了した後にだけデータ通信量を再開してください。
The mechanisms used to detect a connection status change depends on the mobile node implementation, the networking technology, and the access mode.
接続形態変化を検出するのに使用されるメカニズムはモバイルノード実装、ネットワーク・テクノロジー、およびアクセス・モードに依存します。
3.2.3. Registration-Based Internal Network Detection
3.2.3. 登録ベースの内部のネットワーク検出
The mobile node MUST NOT infer that an interface is connected to the internal network unless a successful registration has been completed through that particular interface to the i-HA, the i-HA registration reply contained a Trusted Networks Configured extension (Section 3.4), and the connection status of the interface has not changed since.
うまくいっている登録がその特定のインタフェースを通してi-HAに終了して、i-HA登録回答がTrusted Networks Configured拡張子(セクション3.4)を含んで、インタフェースの接続形態が以来変化している場合、モバイルノードは、インタフェースが内部のネットワークに関連づけられると推論してはいけません。
3.2.4. Registration-Based Internal Network Monitoring
3.2.4. 登録ベースの内部のネットワーク監視
Some leak of plaintext packets to a (potentially) untrusted network cannot always be completely prevented; this depends heavily on the client implementation. In some cases, the client cannot detect such a change, e.g., if upstream routing is changed.
完全にいつも(潜在的に)信頼されていないネットワークへの平文パケットのいくつかの漏出を防ぐことができるというわけではありません。 これは大いにクライアント実装によります。 いくつかの場合、例えば、上流のルーティングを変えるなら、クライアントはそのような変化を検出できません。
More frequent re-registrations when the MN is inside is a simple way to ensure that the MN is still inside. The MN SHOULD start re- registration every (T_MONITOR - N) seconds when inside, where N is a grace period that ensures that re-registration is completed before T_MONITOR seconds are up. To bound the maximum amount of time that a plaintext leak may persist, the mobile node must fulfill the following security requirements when inside:
ミネソタが中にあるとき、より頻繁な再登録証明書はミネソタがまだ中にあるのを保証する簡単な方法です。 MN SHOULDが再登録を始める、あらゆる、(T_MONITOR--N) Nがどこのその再登録を確実にする据置期間であるかがT_MONITOR秒以前中に完成するときの秒は上がっています。 以下にあるとき、平文漏出が持続するかもしれない最大の時間にバウンドするように、モバイルノードは以下のセキュリティ要件を実現させなければなりません。
o The mobile node MUST NOT send or receive a user data packet if
more than T_MONITOR seconds have elapsed since the last successful
(re-)registration with the i-HA.
o 最終以来T_MONITOR秒以上がうまくいった状態で経過しているなら、モバイルノードがユーザデータ・パケットを送ってはいけませんし、また受けてはいけない、(再、)、i-HAとの登録。
o If more than T_MONITOR seconds have elapsed, data packets MUST be
either dropped or queued. If the packets are queued, the queues
MUST NOT be processed until the re-registration has been
successfully completed without a connection status change.
o T_MONITOR秒以上が経過したなら、データ・パケットを下げられなければならないか、または列に並ばせなければなりません。 パケットが列に並ばせられるなら、再登録が接続形態変化なしで首尾よく終了するまで、待ち行列を処理してはいけません。
Vaarala & Klovning Standards Track [Page 17] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[17ページ]。
o The T_MONITOR parameter MUST be configurable, and have the default
value of 60 seconds. This default is a trade-off between traffic
overhead and a reasonable bound to exposure.
o T_MONITORパラメタは、構成可能であり、60秒のデフォルト値を持たなければなりません。 このデフォルトは暴露へのトラフィックオーバーヘッドと合理的なバウンドの間のトレードオフです。
This approach is reasonable for a wide range of mobile nodes (e.g., laptops), but has unnecessary overhead when the mobile node is idle (not sending or receiving packets). If re-registration does not complete before T_MONITOR seconds are up, data packets must be queued or dropped as specified above. Note that re-registration packets MUST be sent even if bidirectional user data traffic is being relayed: data packets are no substitute for an authenticated re- registration.
このアプローチには、さまざまなモバイルノード(例えば、ラップトップ)に妥当ですが、モバイルノードが無駄であるときに(パケットを送らないか、または受けないで)、不要なオーバーヘッドがあります。 T_MONITOR秒が上がっている前に再登録が完全でなくするなら、上で指定されるとしてデータ・パケットを列に並ばせられなければならないか、または下げなければなりません。 双方向のユーザデータ通信量がリレーすることにされるのであっても再登録パケットを送らなければならないことに注意してください: データ・パケットは認証された再登録の代用品ではありません。
To minimize traffic overhead when the mobile node is idle, re- registrations can be stopped when no traffic is being sent or received. If the mobile node subsequently receives or needs to send a packet, the packet must be dropped or queued (as specified above) until a re-registration with the i-HA has been successfully completed. Although this approach adds packet processing complexity, it may be appropriate for small, battery-powered devices, which may be idle much of the time. (Note that ordinary re-registration before the mobility binding lifetime is exhausted should still be done to keep the MN reachable.)
トラフィックを全く送りもしませんし、受け取ってもいないとき、モバイルノードが無駄であるときに、トラフィックオーバーヘッドを最小にするために、再登録証明書を止めることができます。 モバイルノードが、次に、受信するか、またはパケットを送る必要があるなら、i-HAとの再登録が首尾よく終了するまで、パケットを下げられなければならないか、または列に並ばせなければなりません(上で指定されるとして)。 このアプローチはパケット処理の複雑さを加えますが、小さくて、バッテリーによる動力付きのデバイスに、それは適切であるかもしれません。(デバイスはよく使用されていないかもしれません)。 (移動性の拘束力がある寿命が疲れ果てている前に届くようにミネソタを維持するためにまだ普通の再登録をしているべきであることに注意してください。)
T_MONITOR is required to be configurable so that an administrator can determine the required security level for the particular deployment. Configuring T_MONITOR in the order of a few seconds is not practical; alternative mechanisms need to be considered if such confidence is required.
管理者が特定の展開のために必要なセキュリティー・レベルを決定できるくらいT_MONITORが構成可能であることが必要です。 数秒の注文でT_MONITORを構成するのは実用的ではありません。 そのような信用が必要であるなら、代替のメカニズムは、考えられる必要があります。
The re-registration mechanism is a worst-case fallback mechanism. If additional information (such as layer two triggers) is available to the mobile node, the mobile node SHOULD use the triggers to detect MN movement and restart the detection process to minimize exposure.
再登録メカニズムは最悪の場合後退メカニズムです。 追加情報(層twoの引き金などの)がモバイルノードに利用可能であるなら、モバイルノードSHOULDは、暴露を最小にするためにミネソタの運動を検出して、検出プロセスを再開するのに引き金を使用します。
Note that re-registration is required by Mobile IPv4 by default (except for the atypical case of an infinite binding lifetime); however, the re-registration interval may be much larger when using an ordinary Mobile IPv4 client. A shorter re-registration interval is usually not an issue, because the internal network is typically a fast, wired network, and the shortened re-registration interval applies only when the mobile node is inside the internal network. When outside, the ordinary Mobile IPv4 re-registration process (based on binding lifetime) is used.
再登録がデフォルトで(無限の拘束力がある生涯の非定型的なケースを除いて)モバイルIPv4によって必要とされることに注意してください。 しかしながら、普通のモバイルIPv4クライアントを使用するとき、再登録間隔ははるかに大きいかもしれません。 通常、より短い再登録間隔は問題ではありません、通常、内部のネットワークが速くて、ワイヤードなネットワークであり、内部のネットワークの中にモバイルノードがあるときだけ短くされた再登録間隔が適用されるので。 普通のモバイルIPv4再登録手続(拘束力がある生涯に基づいている)が外で使用されているとき。
Vaarala & Klovning Standards Track [Page 18] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[18ページ]。
3.3. Proposed Algorithm
3.3. 提案されたアルゴリズム
When the MN detects that it has changed its point of network attachment on a certain interface, it issues two simultaneous registration requests, one to the i-HA and another to the x-HA. These registration requests are periodically retransmitted if reply messages are not received.
ミネソタがそれを検出するとき、あるインタフェースでネットワーク付属のポイントを変えました、とそれは2つの同時の登録要求、i-HAと別のものへの1をx-HAに発行します。 応答メッセージが受信されていないなら、これらの登録要求は定期的に再送されます。
Registration replies are processed as follows:
登録回答は以下の通り処理されます:
o If a response from the x-HA is received, the MN stops
retransmitting its registration request to the x-HA and
tentatively determines it is outside. However, the MN MUST keep
on retransmitting its registration to the i-HA for a period of
time. The MN MAY postpone the IPsec connection setup for some
period of time while it waits for a (possible) response from the
i-HA.
o x-HAからの応答が受け取られているなら、ミネソタは、登録要求をx-HAに再送するのを止めて、それが外にあることを試験的に決定します。 しかしながら、ミネソタは、しばらくi-HAに登録を再送し続けなければなりません。 i-HAから(可能)の応答を待っていますが、ミネソタはいつかの期間の間IPsec接続設定を延期するかもしれません。
o If a response from the i-HA is received and the response contains
the Trusted Networks Configured extension (Section 3.4), the MN
SHOULD determine that it is inside. In any case, the MN MUST stop
retransmitting its registration requests to both i-HA and x-HA.
o i-HAからの応答が受け取られていて、応答がTrusted Networks Configured拡張子(セクション3.4)を含んでいるなら、MN SHOULDは、それが中にあることを決定します。 どのような場合でも、ミネソタは、i-HAとx-HAの両方に登録要求を再送するのを止めなければなりません。
o When successfully registered with the i-HA directly, MN SHOULD de-
register with the x-HA.
o 首尾よく直接i-HAに登録されると、MN SHOULDは反-x-HAに登録します。
If the MN ends up detecting that it is inside, it MUST re-register periodically (regardless of binding lifetime); see Section 3.2.4. If the re-registration fails, the MN MUST stop sending and receiving plaintext traffic, and MUST restart the detection algorithm.
ミネソタが結局それを検出するなら、それは中にあって、定期的(拘束力がある生涯にかかわらず)に再登録しなければなりません。 セクション3.2.4を見てください。 再登録が失敗するなら、ミネソタは、平文トラフィックを送って、受けるのを止めなければならなくて、検出アルゴリズムを再開しなければなりません。
Plaintext re-registration messages are always addressed either to the x-HA or the i-HA, not to both. This is because the MN knows, after initial registration, whether it is inside or outside. (However, when the mobile node is outside, it re-registers independently with the x-HA using plaintext, and with the i-HA through the VPN tunnel.)
平文再登録メッセージはいつも両方ではなく、x-HAかi-HAに扱われます。 これはミネソタが、新規登録の後にそれが中か外にあるかどうかを知っているからです。 (しかしながら、モバイルノードが外にあるとき、それは独自に平文を使用するx-HA、およびVPNトンネルを通るi-HAに再登録されます。)
Postponing the IPsec connection setup could prevent aborted IKE sessions. Aborting IKE sessions may be a problem in some cases because IKE does not provide a reliable, standardized, and mandatory- to-implement mechanism for terminating a session cleanly.
接続設定が防ぐことができたIPsecを延期すると、IKEセッションは中止になりました。 IKEが清潔に終わるための信頼できて、標準化されて、義務的な道具のメカニズムにセッションを供給しないので、いくつかの場合、IKEセッションを中止するのは、問題であるかもしれません。
If the x-HA is not reachable from inside (i.e., the firewall configuration is known), a detection period of zero is preferred, as it minimizes connection setup overhead and causes no timing problems. Should the assumption have been invalid and a response from the i-HA received after a response from the x-HA, the MN SHOULD re-register with the i-HA directly.
x-HAが内部から届かないなら(すなわち、ファイアウォール構成は知られています)、ゼロの検出の期間は都合がよいです、接続設定オーバーヘッドを最小にして、タイミング問題を全く引き起こさないとき。仮定が病人と応答の後にx-HAから受け取られたi-HAからの応答であるべきであったなら、MN SHOULDは直接i-HAに再登録します。
Vaarala & Klovning Standards Track [Page 19] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[19ページ]。
3.4. Trusted Networks Configured (TNC) Extension
3.4. 信じられたネットワークは(TNC)拡大を構成しました。
This extension is a skippable extension. An i-HA sending the extension must fulfill the requirements described in Section 4.3, while an MN processing the extension must fulfill the requirements described in Section 4.1. The format of the extension is described below. It adheres to the short extension format described in [RFC3344]:
この拡大はskippable拡張子です。 拡大を送るi-HAはセクション4.3で説明された要件を実現させなければなりません、拡大を処理するミネソタがセクション4.1で説明された要件を実現させなければなりませんが。 拡大の形式は以下で説明されます。 それは[RFC3344]で説明された短い拡大形式を固く守ります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サブタイプ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 149
149をタイプしてください。
Length 2
長さ2
Sub-Type 0
サブタイプ0
Reserved Set to 0 when sending, ignored when receiving
発信するとき、Setを0まで予約して、受信するとき、無視されます。
3.5. Implementation Issues
3.5. 導入問題
When the MN uses a parallel detection algorithm and is using an FA, the MN sends two registration requests through the same FA with the same Media Acces Control (MAC) address (or equivalent) and possibly even the same home address. Although this is not in conflict with existing specifications, it is an unusual scenario; hence some FA implementations may not work properly in such a situation. However, testing against deployed foreign agents seems to indicate that a majority of available foreign agents handle this situation.
ミネソタが平行な検出アルゴリズムを使用して、FAを使用しているとき、ミネソタは同じメディアAcces Control(MAC)アドレス(または、同等物)とことによると同じホームアドレスがあっても同じFAを通して2つの登録要求を送ります。 これは既存の仕様との闘争中ではありませんが、それは珍しいシナリオです。 したがって、いくつかのFA実装はそのような状況で適切に働かないかもしれません。 しかしながら、配布している外国人のエージェントに対するテストは手があいている外国人のエージェントの大部分がこの状況を扱うのを示すように思えます。
When the x-HA and i-HA addresses are the same, the scenario is even more difficult for the FA, and it is almost certain that existing FAs do not deal with the situation correctly. Therefore, it is required that x-HA and i-HA addresses MUST be different.
x-HAとi-HAアドレスが同じであるときに、FAには、シナリオはさらに難しいです、そして、既存のFAsが正しく時局に処しないのは、ほとんど確かです。 したがって、x-HAとi-HAアドレスが異なるに違いないのが必要です。
Regardless, if the MN detects that i-HA and x-HA have the same address, it MUST assume that it is in the external network and bypass network detection to avoid confusing the FA. Because the HA addresses are used at different layers, achieving connectivity is possible without address confusion.
不注意に、ミネソタがそのi-HAを検出して、x-HAに同じアドレスがあるなら、それは、外部のネットワークと迂回ネットワーク検出FAを混乱させるのを避けるために中であると仮定しなければなりません。 HAアドレスが異なった層で使用されるので、接続性を達成するのはアドレス混乱なしで可能です。
The mobile node MAY use the following hints to determine that it is inside, but MUST verify reachability of the i-HA anyway:
モバイルノードは、それが中にあることを決定するのに以下のヒントを使用するかもしれませんが、とにかくi-HAの可到達性について確かめなければなりません:
Vaarala & Klovning Standards Track [Page 20] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[20ページ]。
o a domain name in a DHCPDISCOVER / DHCPOFFER message
o DHCPDISCOVER / DHCPOFFERメッセージのドメイン名
o an NAI in a foreign agent advertisement
o 外国エージェント広告におけるNAI
o a list of default gateway MAC addresses that are known to reside
in the internal network (i.e., configured as such, or have been
previously verified to be inside)
o 内部のネットワークで住んでいるのが知られているデフォルトゲートウェイMACアドレスのリストすなわち、(そういうものとして構成するか、または以前にあるように確かめられた、)
For instance, if the MN has reason to believe it is inside, it MAY postpone sending a registration request to the x-HA for some time. Similarly, if the MN has reason to believe it is outside, it may start IPsec connection setup immediately after receiving a registration reply from the x-HA. However, should the MN receive a registration reply from the i-HA after IPsec connection setup has been started, the MN SHOULD still switch to using the i-HA directly.
例えば、ミネソタにそれが中にあると信じる理由があるなら、それは、しばらく登録要求をx-HAに送るのを延期するかもしれません。 同様に、ミネソタにそれが外にあると信じる理由があるなら、x-HAから登録回答を受け取る直後それはIPsec接続設定を始めるかもしれません。 しかしながら、MN SHOULDはIPsec接続設定が始められた後にミネソタがi-HAから登録回答を受け取るならまだ直接i-HAを使用するのに切り替わっています。
3.6. Rationale for Design Choices
3.6. デザイン選択のための原理
3.6.1. Firewall Configuration Requirements
3.6.1. ファイアウォール構成必要条件
The requirement that the i-HA cannot be reached from the external network is necessary. If not, a successful registration with the i-HA (without IPsec) cannot be used as a secure indication that the mobile node is inside. A possible solution to the obvious security problem would be to define and deploy a secure internal network detection mechanism based on, e.g., signed FA advertisement or signed DHCP messages.
i-HAに外部のネットワークから達することができないという要件が必要です。 そうでなければ、モバイルノードが中にあるという安全な指示としてi-HA(IPsecのない)とのうまくいっている登録を使用できません。 明白な警備上の問題への可能な解決は、安全な内部のネットワーク検出メカニズムがベースの、そして、例えば、署名しているFA広告か署名しているDHCPメッセージであると定義して、配布するだろうことです。
However, unless the mechanism is defined for both FA and DHCP messages and is deployed in every internal network, it has limited applicability. In other words, the mobile node MUST NOT assume it is in the internal network unless it receives a signed FA or DHCP message (regardless of whether or not it can register directly with the i-HA). If it receives an unsigned FA or DHCP message, it MUST use IPsec; otherwise, the mobile node can be easily tricked into using plaintext.
しかしながら、メカニズムがFAとDHCPメッセージの両方のために定義されて、あらゆる内部のネットワークで配布されるというわけではないなら、それは適用性を制限しました。 言い換えれば、モバイルノードは、署名しているFAかDHCPメッセージ(直接i-HAとともに記名することができるかどうかにかかわらず)を受け取らない場合内部のネットワークにはそれがあると仮定してはいけません。 未署名のFAかDHCPメッセージを受け取るなら、IPsecを使用しなければなりません。 さもなければ、平文を使用するように容易にモバイルノードをだますことができます。
Assuming that all FA and DHCP servers in the internal network are upgraded to support such a feature does not seem realistic; it is highly desirable to be able to take advantage of existing DHCP and FA deployments. Similar analysis seems to apply regardless of what kind of additional security mechanism is defined.
内部のネットワークにおけるすべてのFAとDHCPサーバがそのような特徴をサポートするためにアップグレードすると仮定するのは現実的に見えません。 既存のDHCPとFA展開を利用できるのは非常に望ましいです。 同様の分析はどういう追加担保メカニズムが定義されるかにかかわらず適用するように思えます。
Because a firewall configuration error can have catastrophic data security consequences (silent exposure of user data to external attackers), a separate protection mechanism is provided by the i-HA. The i-HA must be configured, by the administrator, with a list of trusted networks. The i-HA advertises that it knows which
ファイアウォール構成誤りが壊滅的なデータ機密保護結果(外部の攻撃者への利用者データの静かな暴露)を持つことができるので、別々の保護メカニズムはi-HAによって提供されます。 管理者は信じられたネットワークのリストでi-HAを構成しなければなりません。 i-HAは、どれを知っているかは広告を出します。
Vaarala & Klovning Standards Track [Page 21] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[21ページ]。
registration request source addresses are trusted, using a registration reply extension (Trusted Networks Configured extension, Section 3.4). Without this extension, an MN may not rely on a successful registration to indicate that it is connected to the internal network. This ensures that user data compromise does not occur unless both the firewall and the i-HA are configured incorrectly. Further, occurrences of registration requests from untrusted addresses should be logged by the i-HA, exposing them to administrator review.
登録回答拡張子(Networks Configured拡張子、セクション3.4を信じる)を使用して、登録要求ソースアドレスは信じられます。 この拡大がなければ、ミネソタは、それが内部のネットワークに関連づけられるのを示すためにうまくいっている登録に依存しないかもしれません。 これは、ファイアウォールとi-HAの両方が不当に構成されない場合利用者データ感染が起こらないのを確実にします。 管理者レビューにそれらを暴露して、さらに、信頼されていないアドレスからの登録要求の発生はi-HAによって登録されるはずです。
3.6.2. Registration-Based Internal Network Monitoring
3.6.2. 登録ベースの内部のネットワーク監視
This issue also affects IPsec client security. However, as IPsec specifications take no stand on how and when client IPsec policies are configured or changed (for instance, in response to a change in network connectivity), the issue is out of scope for IPsec. Because this document describes an algorithm and requirements for (secure) internal network detection, the issue is in scope of the document.
また、この問題はIPsecクライアントセキュリティに影響します。 しかしながら、IPsec仕様がクライアントIPsec方針が構成されるか、または変えられる(例えばネットワークの接続性における変化に対応して)どのように、時の態度を全く取らないかとき、IPsecのための範囲の外に問題があります。 このドキュメントが(安全)の内部のネットワーク検出のためのアルゴリズムと要件について説明するので、問題がドキュメントの範囲にあります。
The current requirement for internal network monitoring was added as a fallback mechanism.
内部のネットワーク監視のための現在の要件は後退メカニズムとして加えられました。
3.6.3. No Encryption When Inside
3.6.3. 内部であることの暗号化がありません。
If encryption was applied also when MN was inside, there would be no security reason to monitor the internal network periodically.
また、ミネソタが中にあったとき暗号化が適用されるなら、定期的に内部のネットワークをモニターするセキュリティ理由が全くないでしょうに。
The main rationale for why encryption cannot be applied when the MN is inside was given in Section 1.6. In short, the main issues are (1) power consumption; (2) extra CPU load, especially because internal networks are typically switched networks and a lot of data may be routinely transferred; (3) existing HA devices do not typically integrate IPsec functionality; (4) (IPsec) encryption requires user authentication, which may be interactive in some cases (e.g., SecurID) and thus a usability issue; and (5) user may need to have separate credentials for VPN devices in the DMZ and the HA.
セクション1.6でミネソタが中にあるとき暗号化を適用できない理由の主な原理を与えました。 要するに、本題は(1)電力消費量です。 (2) 特に、通常、内部のネットワークが交換網であり、きまりきって多くのデータを移すかもしれないので付加的なCPU荷重 (3) 既存のHAデバイスはIPsecの機能性を通常統合しません。 (4) (IPsec) 暗号化は、いくつかの場合、対話的であるかもしれないユーザー認証(例えば、SecurID)を必要として、その結果、ユーザビリティ問題を必要とします。 (5) そして、ユーザはDMZとHAでVPNデバイスのための別々の資格証明書を必要とするかもしれません。
3.7. Improvements
3.7. 改良
The registration process can be improved in many ways. One simple way is to make the x-HA detect whether a registration request came from inside or outside the enterprise network. If it came from inside the enterprise network, the x-HA can simply drop the registration request.
様々な意味で登録手続を改良できます。 1つの簡単な方法は登録要求が内部か企業網の外で来たかどうかx-HAに検出させることです。 企業網の中から来たなら、x-HAは単に登録要求を下げることができます。
This approach is feasible without protocol changes in scenarios where a corporation owns both the VPN and the x-HA. The x-HA can simply determine based on the incoming interface identifier (or the router
このアプローチは会社がVPNとx-HAの両方を所有しているシナリオにおけるプロトコル変化なしで可能です。 x-HAが入って来るインタフェース識別子に基づいて単に決定できる、(ルータ
Vaarala & Klovning Standards Track [Page 22] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[22ページ]。
that relayed the packet) whether or not the registration request came from inside.
それがリレーした、パケット) 登録要求は内部から来るのであったかどうか
In other scenarios, protocol changes may be needed. Such changes are out of scope of this document.
他のシナリオでは、プロトコル変化が必要であるかもしれません。 このドキュメントの範囲の外にそのような変化があります。
4. Requirements
4. 要件
4.1. Mobile Node Requirements
4.1. モバイルノード要件
The mobile node MUST implement an internal network detection algorithm fulfilling the requirements set forth in Section 3.2. A new configurable MN parameter, T_MONITOR, is required. The value of this parameter reflects a balance between security and the amount of signaling overhead, and thus needs to be configurable. In addition, when doing internal network detection, the MN MUST NOT disable IPsec protection unless the registration reply from the i-HA contains a Trusted Networks Configured extension (Section 3.4).
モバイルノードはセクション3.2に詳しく説明された要件を実現させる内部のネットワーク検出アルゴリズムを実装しなければなりません。 新しい構成可能なミネソタパラメタ(T_MONITOR)が必要です。 このパラメタの値は、シグナリングオーバーヘッドのセキュリティと量の間のバランスを反映して、その結果、構成可能である必要があります。 内部のネットワーク検出をするとき、さらに、i-HAからの登録回答がTrusted Networks Configured拡張子(セクション3.4)を含んでいない場合、ミネソタは、IPsecが防護物であると無効にしてはいけません。
The mobile node MUST support access modes c, f, cvc, fvc (Section 2).
モバイルノードは、アクセス・モードc、fがcvc、fvc(セクション2)であることを支えなければなりません。
The mobile node SHOULD support Mobile IPv4 NAT traversal [mipnat] for both internal and external Mobile IP.
モバイルノードSHOULDは、内部の、そして、外部の両方のモバイルIPのためにモバイルIPv4がNAT縦断[mipnat]であるとサポートします。
The mobile node SHOULD support IPsec NAT traversal [RFC3947] [RFC3948].
モバイルノードSHOULDは、IPsec NATが縦断[RFC3947]である[RFC3948]とサポートします。
When the mobile node has direct access to the i-HA, it SHOULD use only the inner Mobile IPv4 layer to minimize firewall and VPN impact.
いつモバイルノードがi-HAにダイレクトに近づく手段を持って、それが内側のモバイルIPv4だけがファイアウォールを最小にするために層にするSHOULD使用であるか、そして、VPNは影響を与えます。
When the mobile node is outside and using the VPN connection, IPsec policies MUST be configured to encrypt all traffic sent to and from the enterprise network. The particular Security Policy Database (SPD) entries depend on the type and configuration of the particular VPN (e.g., plain IPsec vs. L2TP/IPsec, full tunneling or split tunneling).
モバイルノードが外部とVPN接続を使用することであるとき、企業網と企業網から送られたすべてのトラフィックを暗号化するためにIPsec方針を構成しなければなりません。 特定のSecurity Policy Database(SPD)エントリーは特定のVPN(例えば、明瞭なIPsec対L2TP/IPsec、完全なトンネリングまたは分裂トンネリング)のタイプと構成に頼っています。
4.2. VPN Device Requirements
4.2. VPNデバイス要件
The VPN security policy MUST allow communication using UDP to the internal home agent(s), with home agent port 434 and any remote port. The security policy SHOULD allow IP-IP to internal home agent(s) in addition to UDP port 434.
内部のホームのエージェントにUDPを使用して、VPN安全保障政策はコミュニケーションを許容しなければなりません、ホームエージェント港434とどんな遠く離れたポートでも。 安全保障政策SHOULDはUDPポート434に加えて内部のホームのエージェントにIP-IPを許容します。
The VPN device SHOULD implement the IPsec NAT traversal mechanism described in [RFC3947] and [RFC3948].
VPNデバイスSHOULDは[RFC3947]と[RFC3948]で説明されたIPsec NAT縦断メカニズムを実装します。
Vaarala & Klovning Standards Track [Page 23] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[23ページ]。
4.3. Home Agent Requirements
4.3. ホームエージェント要件
The home agent SHOULD implement the Mobile IPv4 NAT traversal mechanism described in [mipnat]. (This also refers to the i-HA: NAT traversal is required to support VPNs that NAT VPN tunnel addresses or block IP-IP traffic.)
ホームのエージェントSHOULDは[mipnat]で説明されたモバイルIPv4NAT縦断メカニズムを実装します。 (また、これはi-HAを示します: NAT縦断がアドレスかブロックIP-IPトラフィックをNAT VPNがトンネルを堀るVPNsにサポートするのに必要です。)
To protect user data confidentiality against firewall configuration errors, the i-HA:
ファイアウォール構成誤り、i-HAに対してユーザデータの機密性を保護するために:
o MUST be configured with a list of trusted IP subnets (containing
only addresses from the internal network), with no subnets being
trusted by default.
o 信じられたIPサブネット(内部のネットワークからのアドレスだけを含んでいる)のリストで構成しなければなりません、デフォルトで信じられるサブネットなしで。
o MUST reject (drop silently) any registration request coming from a
source address that is not inside any of the configured trusted
subnets. These dropped registration requests SHOULD be logged.
o 構成された信じられたサブネットのいずれにはもないソースアドレスから来るどんな登録要求も拒絶しなければなりません(静かに、低下します)。 これらの下げられた登録は、SHOULDが登録されるよう要求します。
o MUST include a Trusted Networks Configured extension (Section 3.4)
in a registration reply sent in response to a registration request
coming from a trusted address.
o 信じられたアドレスから来て、登録要求に対応して送られた登録回答にTrusted Networks Configured拡張子(セクション3.4)を含まなければなりません。
5. Analysis
5. 分析
This section provides a comparison against guidelines described in Section 6 of the problem statement [RFC4093] and additional analysis of packet overhead with and without the optional mechanisms.
このセクションは任意のメカニズムのあるなしにかかわらずパケットオーバーヘッドの問題声明[RFC4093]と追加分析のセクション6で説明されたガイドラインに対して比較を提供します。
5.1. Comparison against Guidelines
5.1. ガイドラインに対する比較
Preservation of existing VPN infrastructure
既存のVPNインフラストラクチャの保存
o The solution does not mandate any changes to existing VPN
infrastructure, other than possibly changes in configuration to
avoid stateful filtering of traffic.
o ソリューションは、トラフィックのstatefulフィルタリングを避けるためにことによると構成における変化以外の既存のVPNインフラストラクチャへの少しの変化も強制しません。
Software upgrades to existing VPN clients and gateways
既存のVPNクライアントとゲートウェイへのソフトウェアの更新
o The solution described does not require any changes to VPN
gateways or Mobile IPv4 foreign agents.
o 説明されたソリューションはVPNゲートウェイかモバイルIPv4外国人のエージェントへの少しの変化も必要としません。
IPsec protocol
IPsecプロトコル
o The solution does not require any changes to existing IPsec or key
exchange standard protocols, and does not require implementation
of new protocols in the VPN device.
o ソリューションは、既存のIPsecか主要な交換標準プロトコルへの少しの変化も必要としないで、またVPNデバイスで新しいプロトコルの実装を必要としません。
Vaarala & Klovning Standards Track [Page 24] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[24ページ]。
Multi-vendor interoperability
マルチベンダ相互運用性
o The solution provides easy multi-vendor interoperability between
server components (VPN device, foreign agents, and home agents).
Indeed, these components need not be aware of each other.
o ソリューションはサーバコンポーネント(VPNデバイス、外国人のエージェント、およびホームのエージェント)の間に簡単なマルチベンダ相互運用性を提供します。 本当に、これらのコンポーネントは互いを意識している必要はありません。
o The mobile node networking stack is somewhat complex to implement,
which may be an issue for multi-vendor interoperability. However,
this is a purely software architecture issue, and there are no
known protocol limitations for multi-vendor interoperability.
o モバイルノードネットワークスタックは、実装するためにいくらか複雑です(マルチベンダ相互運用性のための問題であるかもしれません)。 しかしながら、これがそうである、純粋にソフトウェア・アーキテクチャ問題、マルチベンダ相互運用性のためのプロトコル制限は知られていません。
MIPv4 protocol
MIPv4プロトコル
o The solution adheres to the MIPv4 protocol, but requires the new
Trusted Networks Configured extension to improve the
trustworthiness of internal network detection.
o ソリューションは、内部のネットワーク検出の信頼できることを改良するためにMIPv4プロトコルを固く守りますが、新しいTrusted Networks Configured拡張子を必要とします。
o The solution requires the use of two parallel MIPv4 layers.
o ソリューションは2つの平行なMIPv4層の使用を必要とします。
Handoff overhead
移管オーバーヘッド
o The solution provides a mechanism to avoid VPN tunnel SA
renegotiation upon movement by using the external MIPv4 layer.
o ソリューションは、動きのときに外部のMIPv4層を使用することによってVPNトンネルSA renegotiationを避けるためにメカニズムを提供します。
Scalability, availability, reliability, and performance
スケーラビリティ、有用性、信頼性、および性能
o The solution complexity is linear with the number of MNs
registered and accessing resources inside the intranet.
o ソリューションの複雑さは、直線的、そして、MNsの数が示されている状態でイントラネットでリソースにアクセスします。
o Additional overhead is imposed by the solution.
o 追加オーバーヘッドはソリューションによって課されます。
Functional entities
機能的な実体
o The solution does not impose any new types of functional entities
or required changes to existing entities. However, an external HA
device is required.
o ソリューションは機能的な実体のどんな新しいタイプか既存の実体への必要な変化も課しません。 しかしながら、外部のHAデバイスが必要です。
Implications of intervening NAT gateways
介入しているNATゲートウェイの含意
o The solution leverages existing MIPv4 NAT traversal [mipnat] and
IPsec NAT traversal [RFC3947] [RFC3948] solutions and does not
require any new functionality to deal with NATs.
o ソリューションは、既存のMIPv4NATが縦断[mipnat]とIPsec NAT縦断[RFC3947][RFC3948]対策であると利用して、NATsに対処するために少しの新しい機能性も必要としません。
Security implications
セキュリティ含意
o The solution requires a new mechanism to detect whether the mobile
node is in the internal or the external network. The security of
this mechanism is critical in ensuring that the security level
o ソリューションは、内部のネットワークか外部のネットワークにはモバイルノードがあるかを検出するために新しいメカニズムを必要とします。 このメカニズムのセキュリティはセキュリティが平らにする確実にすることで重要です。
Vaarala & Klovning Standards Track [Page 25] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[25ページ]。
provided by IPsec is not compromised by a faulty detection
mechanism.
IPsecが不完全な検出メカニズムによって感染されないなら。
o When the mobile node is outside, the external Mobile IPv4 layer
may allow some traffic redirection attacks that plain IPsec does
not allow. Other than that, IPsec security is unchanged.
o モバイルノードが外にあるとき、外部のモバイルIPv4層は明瞭なIPsecが許さないいくつかのトラフィックリダイレクション攻撃を許すかもしれません。 それを除いて、IPsecセキュリティは変わりがありません。
o More security considerations are described in Section 6.
o より多くのセキュリティ問題がセクション6で説明されます。
5.2. Packet Overhead
5.2. パケットオーバーヘッド
The maximum packet overhead depends on access mode as follows:
最大のパケットオーバーヘッドを以下のアクセス・モードに依存します:
o f: 0 octets
o f: 0つの八重奏
o c: 20 octets
o c: 20の八重奏
o fvc: 77 octets
o fvc: 77の八重奏
o cvc: 97 octets
o cvc: 97の八重奏
The maximum overhead of 97 octets in the 'cvc' access mode consists of the following:
'cvc'アクセス・モードにおける、97の八重奏の最大のオーバーヘッドは以下から成ります:
o IP-IP for i-MIPv4: 20 octets
o i-MIPv4のためのIP-IP: 20の八重奏
o IPsec ESP: 57 octets total, consisting of 20 (new IP header),
4+4+8 = 16 (SPI, sequence number, cipher initialization vector),
7+2 = 9 (padding, padding length field, next header field), 12
(ESP authentication trailer)
o IPsec、超能力: 57の八重奏が20(新しいIPヘッダー)、4+4+8=16(SPI(一連番号)は初期化ベクトルを解く)から成る7+2=9(長さの分野、次のヘッダーフィールドを水増しして、そっと歩きます)、合計で12になります。(超能力認証トレーラ)
o IP-IP for x-MIPv4: 20 octets
o x-MIPv4のためのIP-IP: 20の八重奏
When IPsec is used, a variable amount of padding is present in each ESP packet. The figures were computed for a cipher with 64-bit block size, padding overhead of 9 octets (next header field, padding length field, and 7 octets of padding; see Section 2.4 of [RFC4303]), and ESP authentication field of 12 octets (HMAC-SHA1-96 or HMAC-MD5-96). Note that an IPsec implementation MAY pad with more than a minimum amount of octets.
IPsecが使用されているとき、可変量の詰め物がそれぞれの超能力パケットに存在しています。 数字は暗号のために64ビットのブロック・サイズで計算されました、9つの八重奏のオーバーヘッド(詰め物の次のヘッダーフィールド、詰め物長さの分野、および7つの八重奏; [RFC4303]のセクション2.4を見る)、および12の八重奏の超能力認証分野(HMAC-SHA1-96かHMAC-MD5-96)を水増しして。 IPsec実装が最小の量の八重奏以上でそっと歩くかもしれないことに注意してください。
NAT traversal overhead is not included, and adds 8 octets when IPsec NAT traversal [RFC3947] [RFC3948] is used and 12 octets when MIP NAT traversal [mipnat] is used. For instance, when using access mode cvc, the maximum NAT traversal overhead is 12+8+12 = 32 octets. Thus, the worst case scenario (with the above mentioned ESP assumptions) is 129 octets for cvc.
NAT縦断オーバーヘッドは、含まれていなくて、MIP NAT縦断[mipnat]が使用されているとき、IPsec NAT縦断[RFC3947][RFC3948]が使用されているときの8つの八重奏と12の八重奏を加えます。 例えば、アクセス・モードcvcを使用するとき、最大のNAT縦断オーバーヘッドは32の12+8+12=八重奏です。 したがって、最悪の場合(上記の超能力仮定がある)はcvcのための129の八重奏です。
Vaarala & Klovning Standards Track [Page 26] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[26ページ]。
5.3. Latency Considerations
5.3. 潜在問題
When the MN is inside, connection setup latency does not increase compared to standard MIPv4 if the MN implements the suggested parallel registration sequence (see Section 3.3). Exchange of RRQ/ RRP messages with the i-HA confirms the MN is inside, and the MN may start sending and receiving user traffic immediately. For the same reason, handovers in the internal network have no overhead relative to standard MIPv4.
ミネソタが中にあるとき、ミネソタが、提案された平行な登録が系列であると実装するなら(セクション3.3を見てください)標準のMIPv4と比べて、接続設定潜在は増加しません。 ミネソタは、i-HAとのRRQ/ RRPメッセージの交換が、ミネソタが中にあると確認して、すぐにユーザトラフィックを送って、受け始めるかもしれません。 同じ理由から、内部のネットワークにおける身柄の引き渡しには、標準のMIPv4に比例してオーバーヘッドが全くありません。
When the MN is outside, the situation is slightly different. Initial connection setup latency essentially consists of (1) registration with the x-HA, (2) optional detection delay (waiting for i-HA response), (3) IPsec connection setup (IKE), and (4) registration with the i-HA. All but (4) are in addition to standard MIPv4.
ミネソタが外にあるとき、状況はわずかに異なっています。 初期の接続設定潜在はx-HA、(2)の任意の検出遅れ(i-HA応答を待っている)、(3)IPsec接続設定(IKE)、およびi-HAとの(4)登録で(1) 登録から本質的には成ります。 (4)を除いたすべてが標準のMIPv4に加えています。
However, handovers in the external network have performance comparable to standard MIPv4. The MN simply re-registers with the x-HA and starts to send IPsec traffic to the VPN gateway from the new address.
しかしながら、外部のネットワークにおける身柄の引き渡しで、性能は標準のMIPv4に匹敵するようになります。 ミネソタは、単にx-HAに再登録して、VPNゲートウェイへのトラフィックを新しいアドレスからIPsecに送り始めます。
The MN may minimize latency by (1) not waiting for an i-HA response before triggering IKE if the x-HA registration succeeds and (2) sending first the RRQ most likely to succeed (e.g., if the MN is most likely outside). These can be done based on heuristics about the network, e.g., addresses, MAC address of the default gateway (which the mobile node may remember from previous access); based on the previous access network (i.e., optimize for inside-inside and outside-outside movement); etc.
ミネソタは、最初に、最も成功しそうなRRQを送りながら(例えば、ミネソタがたぶん外にあるなら)、x-HA登録が成功するならIKEの引き金となる前にi-HA応答を待たない(1)と(2)で潜在を最小にするかもしれません。 ネットワークに関する発見的教授法に基づいてこれらができます、例えば、アドレス、デフォルトゲートウェイ(モバイルノードが前のアクセスから覚えているかもしれない)のMACアドレス。 前のアクセスネットワーク(すなわち、内外面の外部の動きのために、最適化する)に基づいています。 など
5.4. Firewall State Considerations
5.4. ファイアウォール州の問題
A separate firewall device or an integrated firewall in the VPN gateway typically performs stateful inspection of user traffic. The firewall may, for instance, track TCP session status and block TCP segments not related to open connections. Other stateful inspection mechanisms also exist.
別々のファイアウォールデバイスかVPNゲートウェイの統合ファイアウォールがユーザトラフィックのステートフルインスペクションを通常実行します。 例えば、ファイアウォールはオープンな接続に関連しないTCPセッション状態とブロックTCPセグメントを追跡するかもしれません。 また、他のステートフルインスペクションメカニズムは存在しています。
Firewall state poses a problem when the mobile node moves between the internal and external networks. The mobile node may, for instance, initiate a TCP connection while inside, and later go outside while expecting to keep the connection alive. From the point of view of the firewall, the TCP connection has not been initiated, as it has not witnessed the TCP connection setup packets, thus potentially resulting in connectivity problems.
モバイルノードが内部の、そして、外部のネットワークの間で移行すると、ファイアウォール状態は問題を設定します。 例えば、接続を生かすと予想している間、モバイルノードは、内部である間、TCP接続を開始して、後で外に行くかもしれません。 ファイアウォールの観点から、TCP接続は開始されていません、TCP接続設定パケットを目撃していないとき、その結果、潜在的に、接続性問題をもたらします。
When the VPN-TIA is registered as a co-located care-of address with the i-HA, all mobile node traffic appears as IP-IP for the firewall.
VPN-TIAが共同見つけられたaとして登録される、注意、-、i-HAとのアドレス、すべてのモバイルノードトラフィックがファイアウォールへのIP-IPとして現れます。
Vaarala & Klovning Standards Track [Page 27] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[27ページ]。
Typically, firewalls do not continue inspection beyond the IP-IP tunnel, but support for deeper inspection is available in many products. In particular, an administrator can configure traffic policies in many firewall products even for IP-IP encapsulated traffic. If this is done, similar statefulness issues may arise.
通常、ファイアウォールはIP-IPトンネルを超えて点検を続けていませんが、より深い点検のサポートは多くの製品の中に利用可能です。 特に、管理者はトラフィックであるとカプセル化されたIP-IPのためにさえ多くのファイアウォール製品の中のトラフィック方針を構成できます。 これが完了しているなら、同様のstatefulness問題は起こるかもしれません。
In summary, the firewall must allow traffic coming from and going into the IPsec connection to be routed, even though they may not have successfully tracked the connection state. How this is done is out of scope of this document.
概要では、ファイアウォールは、IPsec接続を来て、入るトラフィックが発送されるのを許容しなければなりません、彼らは首尾よく接続状態を追跡していないかもしれませんが。 このドキュメントの範囲の外にこれがどう完了しているかがあります。
5.5. Intrusion Detection Systems (IDSs)
5.5. 侵入検知システム(IDSs)
Many firewalls incorporate intrusion detection systems monitoring network traffic for unusual patterns and clear signs of attack. Since traffic from a mobile node implementing this specification is UDP to i-HA port 434, and possibly IP-IP traffic to the i-HA address, existing IDSs may treat the traffic differently than ordinary VPN remote access traffic. Like firewalls, IDSs are not standardized, so it is impossible to guarantee interoperability with any particular IDS system.
多くのファイアウォールが攻撃の異常パターンと明確なサインのためにネットワークトラフィックをモニターする侵入検知システムを組み込みます。 この仕様を履行するモバイルノードからのトラフィックがi-HAポート434へのUDPと、ことによるとi-HAアドレスへのIP-IPトラフィックであるので、既存のIDSsは普通のVPN遠く離れたアクセス交通量と異なってトラフィックを扱うかもしれません。 ファイアウォールのように、IDSsが標準化されないので、どんな特定のIDSシステムでも相互運用性を保証するのは不可能です。
5.6. Implementation of the Mobile Node
5.6. モバイルノードの実装
Implementation of the mobile node requires the use of three tunneling layers, which may be used in various configurations depending on whether that particular interface is inside or outside. Note that it is possible that one interface is inside and another interface is outside, which requires a different layering for each interface at the same time.
モバイルノードの実装は3つのトンネリング層の使用を必要とします。(層はその特定のインタフェースが中か外にあるかどうかに依存する様々な構成に使用されるかもしれません)。 1つのインタフェースが中にあって、別のインタフェースが外にあるのが、可能であることに注意してください(同時に、各インタフェースのための異なったレイヤリングを必要とします)。
For multi-vendor implementation, the IPsec and MIPv4 layers need to interoperate in the same mobile node. This implies that a flexible framework for protocol layering (or protocol-specific APIs) is required.
マルチベンダ実装のために、IPsecとMIPv4層は、同じモバイルノードに共同利用する必要があります。 これは、プロトコルレイヤリング(または、プロトコル特有のAPI)のためのフレキシブルなフレームワークが必要であることを含意します。
5.7. Non-IPsec VPN Protocols
5.7. 非IPsec VPNプロトコル
The solution also works for VPN tunneling protocols that are not IPsec-based, provided that the mobile node is provided IPv4 connectivity with an address suitable for registration. However, such VPN protocols are not explicitly considered.
また、ソリューションはIPsecベースでないVPNトンネリングプロトコルのために働いています、モバイルノードは登録に適したアドレスにIPv4の接続性を提供すれば。 しかしながら、そのようなVPNプロトコルは明らかに考えられません。
Vaarala & Klovning Standards Track [Page 28] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[28ページ]。
6. Security Considerations
6. セキュリティ問題
6.1. Internal Network Detection
6.1. 内部のネットワーク検出
If the mobile node by mistake believes it is in the internal network and sends plaintext packets, it compromises IPsec security. For this reason, the overall security (confidentiality and integrity) of user data is a minimum of (1) IPsec security and (2) security of the internal network detection mechanism.
間違っているモバイルノードが内部のネットワークにはあって、平文パケットを送ると信じているなら、それは、IPsecがセキュリティであると感染します。 この理由で、利用者データの総合的なセキュリティ(秘密性と保全)は、内部のネットワーク検出メカニズムの最小(1)IPsecセキュリティと(2)セキュリティです。
Security of the internal network detection relies on a successful registration with the i-HA. For standard Mobile IPv4 [RFC3344], this means HMAC-MD5 and Mobile IPv4 replay protection. The solution also assumes that the i-HA is not directly reachable from the external network, requiring careful enterprise firewall configuration. To minimize the impact of a firewall configuration problem, the i-HA is separately required to be configured with trusted source addresses (i.e., addresses belonging to the internal network), and to include an indication of this in a new Trusted Networks Configured extension. The MN is required not to trust a registration as an indication of being connected to the internal network, unless this extension is present in the registration reply. Thus, to actually compromise user data confidentiality, both the enterprise firewall and the i-HA have to be configured incorrectly, which reduces the likelihood of the scenario.
内部のネットワーク検出のセキュリティはi-HAとのうまくいっている登録に依存します。 標準のモバイルIPv4[RFC3344]に関しては、これはHMAC-MD5とモバイルIPv4反復操作による保護を意味します。 また、慎重な企業ファイアウォール構成を必要として、ソリューションは、i-HAに外部のネットワークから直接届いていないと仮定します。 i-HAは、信頼できるソースアドレス(すなわち、内部のネットワークに属すアドレス)によって構成されて、ファイアウォール設定問題の影響を最小にするために、別々に新しいTrusted Networks Configured拡張子におけるこのしるしを含まなければなりません。 ミネソタが内部のネットワークに関連づけられるしるしとして登録を信じないように必要です、この拡大が登録回答で存在していない場合。 したがって、実際に感染ユーザデータの機密性に、企業ファイアウォールとi-HAの両方が不当に構成されなければなりません、シナリオの見込みを減少させるどれ。
When the mobile node sends a registration request to the i-HA from an untrusted network that does not go through the IPsec tunnel, it will reveal the i-HA's address, its own identity including the NAI and the home address, and the Authenticator value in the authentication extensions to the untrusted network. This may be a concern in some deployments.
モバイルノードが行かない信頼されていないネットワークからIPsecトンネルまで登録要求をi-HAに送るとき、それはi-HAのアドレス、認証拡大でNAI、ホームアドレス、およびAuthenticator値を信頼されていないネットワークに含むそれ自身のアイデンティティを明らかにするでしょう。 これはいくつかの展開で関心であるかもしれません。
When the connection status of an interface changes, an interface previously connected to the trusted internal network may suddenly be connected to an untrusted network. Although the same problem is also relevant to IPsec-based VPN implementations, the problem is especially relevant in the scope of this specification.
インタフェースの接続形態が変化するとき、以前に信じられた内部のネットワークに関連づけられたインタフェースは突然信頼されていないネットワークに関連づけられるかもしれません。 また、同じ問題もIPsecベースのVPN実装に関連していますが、問題はこの仕様の範囲で特に関連しています。
In most cases, mobile node implementations are expected to have layer 2 information available, making connection change detection both fast and robust. To cover cases where such information is not available (or fails for some reason), the mobile node is required to periodically re-register with the internal home agent to verify that it is still connected to the trusted network. It is also required that this re-registration interval be configurable, thus giving the administrator a parameter by which potential exposure may be controlled.
多くの場合、モバイルノード実装には利用可能な層2の情報があると予想されます、接続変化検出を速く、かつ強健にして。 そのような情報が利用可能でない(または、ある理由で、失敗します)ケースをカバーするために、モバイルノードはそれがまだ信じられたネットワークに関連づけられていることを確かめるために定期的に内部のホームのエージェントに再登録しなければなりません。 また、この再登録間隔が構成可能であることが必要です、その結果、潜在被曝が制御されるかもしれないパラメタを管理者に与えます。
Vaarala & Klovning Standards Track [Page 29] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[29ページ]。
6.2. Mobile IPv4 versus IPsec
6.2. モバイルIPv4対IPsec
MIPv4 and IPsec have different goals and approaches for providing security services. MIPv4 typically uses a shared secret for authentication of signaling traffic, while IPsec typically uses IKE (an authenticated Diffie-Hellman exchange) to set up session keys. Thus, the overall security properties of a combined MIPv4 and IPsec system depend on both mechanisms.
MIPv4とIPsecには、セキュリティー・サービスを提供するための異なった目標とアプローチがあります。 MIPv4はシグナリングトラフィックの認証に共有秘密キーを通常使用します、IPsecがセッションキーをセットアップするのに、IKE(認証されたディフィー-ヘルマンの交換)を通常使用しますが。 したがって、結合したMIPv4とIPsecシステムの総合的なセキュリティの特性は両方のメカニズムに依存します。
In the solution outlined in this document, the external MIPv4 layer provides mobility for IPsec traffic. If the security of MIPv4 is broken in this context, traffic redirection attacks against the IPsec traffic are possible. However, such routing attacks do not affect other IPsec properties (confidentiality, integrity, replay protection, etc.), because IPsec does not consider the network between two IPsec endpoints to be secure in any way.
本書では概説されたソリューションでは、外部のMIPv4層はIPsecトラフィックに移動性を提供します。 MIPv4のセキュリティがこのような関係においては壊れているなら、IPsecトラフィックに対するトラフィックリダイレクション攻撃は可能です。 しかしながら、そのようなルーティング攻撃は他のIPsecの特性(秘密性、保全、反復操作による保護など)に影響しません、IPsecが、2つのIPsec終点の間のネットワークが何らかの方法で安全であると考えないので。
Because MIPv4 shared secrets are usually configured manually, they may be weak if easily memorizable secrets are chosen, thus opening up redirection attacks described above. Note especially that a weak secret in the i-HA is fatal to security, as the mobile node can be fooled into dropping encryption if the i-HA secret is broken.
MIPv4共有秘密キーが通常手動で構成されるので、容易に暗記可能な秘密が選ばれているなら、それらは弱いかもしれません、その結果、上で説明されたリダイレクション攻撃を開けます。 i-HAの弱い秘密がセキュリティに致命的であることに特に注意してください、i-HA秘密が壊れているなら暗号化を下げるようにモバイルノードをだますことができるとき。
Assuming the MIPv4 shared secrets have sufficient entropy, there are still at least the following differences and similarities between MIPv4 and IPsec worth considering:
MIPv4共有秘密キーには十分なエントロピーがあると仮定して、考える価値があるMIPv4とIPsecの間には、少なくとも以下の違いと類似性がまだあります:
o Both IPsec and MIPv4 are susceptible to the "transient pseudo NAT"
attack described in [pseudonat] and [mipnat], assuming that NAT
traversal is enabled (which is typically the case). "Pseudo NAT"
attacks allow an attacker to redirect traffic flows, resulting in
resource consumption, lack of connectivity, and denial of service.
However, such attacks cannot compromise the confidentiality of
user data protected using IPsec.
o IPsecとMIPv4の両方が[pseudonat]と[mipnat]で説明された「一時的な疑似NAT」攻撃に影響されやすいです、NAT縦断が可能にされると仮定して(通常、ケースです)。 攻撃者は「疑似NAT」攻撃で交通の流れを向け直すことができます、リソース消費、接続性、およびサービスの否定の不足をもたらして。 しかしながら、そのような攻撃はIPsecを使用することで保護された利用者データの秘密性に感染することができません。
o When considering a "pseudo NAT" attack against standard IPsec and
standard MIP (with NAT traversal), redirection attacks against MIP
may be easier because:
o 標準のIPsecと標準のMIP(NAT縦断がある)に対して「疑似NAT」が攻撃であると考えるとき、MIPに対するリダイレクション攻撃が、より簡単であるかもしれない、:
* MIPv4 re-registrations typically occur more frequently than
IPsec SA setups (although this may not be the case for mobile
hosts).
* MIPv4再登録証明書はIPsec SAセットアップより頻繁に通常起こります(これがモバイルホストのためのそうでないかもしれませんが)。
* It suffices to catch and modify a single registration request,
whereas attacking IKE requires that multiple IKE packets are
caught and modified.
* それはただ一つの登録要求を捕らえて、変更するために十分ですが、IKEを攻撃するのは、複数のIKEパケットが捕らえられて、変更されるのを必要とします。
Vaarala & Klovning Standards Track [Page 30] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[30ページ]。
o There may be concerns about mixing of algorithms. For instance,
IPsec may be using HMAC-SHA1-96, while MIP is always using HMAC-
MD5 (RFC 3344) or prefix+suffix MD5 (RFC 2002). Furthermore,
while IPsec algorithms are typically configurable, MIPv4 clients
typically use only HMAC-MD5 or prefix+suffix MD5. Although this
is probably not a security problem as such, it is more difficult
to communicate to users.
o アルゴリズムを混合することに関する心配があるかもしれません。例えば、IPsecはHMAC-SHA1-96を使用しているかもしれません、MIPがいつもHMAC MD5(RFC3344)か接頭語+接尾語MD5(RFC2002)を使用している間。 その上、IPsecアルゴリズムが通常構成可能である間、MIPv4クライアントはHMAC-MD5か接頭語+接尾語MD5だけを通常使用します。 これはたぶんそういうものの警備上の問題ではありませんが、ユーザに交信するのは、より難しいです。
o When IPsec is used with a Public Key Infrastructure (PKI), the key
management properties are superior to those of basic MIPv4. Thus,
adding MIPv4 to the system makes key management more complex.
o IPsecが公開鍵暗号基盤(PKI)と共に使用されるとき、かぎ管理所有地は基本的なMIPv4のものより優れています。 したがって、MIPv4をシステムに追加するのに、かぎ管理は、より複雑になります。
o In general, adding new security mechanisms increases overall
complexity and makes the system more difficult to understand.
o 一般に、新しいセキュリティー対策を加えるのは、総合的な複雑さを増強して、システムを理解しているのをより難しくします。
7. IANA Considerations
7. IANA問題
This document specifies a new skippable extension (in the short format) in Section 3.4, whose Type and Sub-Type values have been assigned.
このドキュメントはTypeとSub-タイプ値を割り当ててあるセクション3.4で新しいskippable拡張子(短い形式の)を指定します。
Allocation of new Sub-Type values can be made via Expert Review and Specification Required [RFC5226].
Expert ReviewとSpecification Required[RFC5226]を通して新しいSub-タイプ値の配分をすることができます。
8. Acknowledgements
8. 承認
This document is a joint work of the contributing authors (in alphabetical order):
このドキュメントは貢献している作者(アルファベット順に)の共同作業です:
- Farid Adrangi (Intel Corporation)
- Nitsan Baider (Check Point Software Technologies, Inc.)
- Gopal Dommety (Cisco Systems)
- Eli Gelasco (Cisco Systems)
- Dorothy Gellert (Nokia Corporation)
- Espen Klovning (Birdstep)
- Milind Kulkarni (Cisco Systems)
- Henrik Levkowetz (ipUnplugged AB)
- Frode Nielsen (Birdstep)
- Sami Vaarala (Codebay)
- Qiang Zhang (Liqwid Networks, Inc.)
- ファリドAdrangi(インテル社)--Nitsan Baider(検査点ソフトウェア技術Inc.) - ゴパルDommety(シスコシステムズ)--イーライGelasco(シスコシステムズ)--ドロシー・ゲラート(ノキア社)--エスペンKlovning(Birdstep)--Milind Kulkarni(シスコシステムズ)--Henrik Levkowetz(ipUnplugged AB)--Frodeニールセン(Birdstep)--サミVaarala(Codebay)--Qiangチャン(LiqwidはInc.をネットワークでつなぎます)
The authors would like to thank the MIP/VPN design team, especially Mike Andrews, Gaetan Feige, Prakash Iyer, Brijesh Kumar, Joe Lau, Kent Leung, Gabriel Montenegro, Ranjit Narjala, Antti Nuopponen, Alan O'Neill, Alpesh Patel, Ilkka Pietikainen, Phil Roberts, Hans Sjostrand, and Serge Tessier for their continuous feedback and helping us improve this document. Special thanks to Radia Perlman for giving the document a thorough read and a security review. Tom
作者は、彼らの連続したフィードバックと私たちを助けるためのデザインチーム、特にマイク・アンドリュース、ガエタン・フェイジ、プラカシュ・アイヤル、Brijeshクマー、ジョー・ラウ、ケントレオン、ガブリエル・モンテネグロ、ランジットNarjala、Antti Nuopponen、アラン・オニール、Alpeshパテル、Ilkka Pietikainen、フィル・ロバーツ、ハンス・シェストランド、およびセルジュ・テシエがこのドキュメントを改良するのをMIP/VPNに感謝したがっています。 徹底的な読書とセキュリティをドキュメントに与えるためのRadiaパールマンへの特別な感謝は論評します。 トム
Vaarala & Klovning Standards Track [Page 31] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[31ページ]。
Hiller pointed out issues with battery-powered devices. We would also like to thank the previous Mobile IP working group chairs (Gabriel Montenegro, Basavaraj Patil, and Phil Roberts) for important feedback and guidance.
ヒラーはバッテリーによる動力付きのデバイスの問題を指摘しました。 また、重要なフィードバックと指導のための前のモバイルIPワーキンググループいす(ガブリエル・モンテネグロ、Basavarajパティル、およびフィル・ロバーツ)に感謝申し上げます。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4",
RFC 3344, August 2002.
[RFC3344] パーキンス、C.、エド、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A.、およびV.ボルペ、「IKEでのNAT縦断の交渉」、RFC3947、2005年1月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
M. Stenberg, "UDP Encapsulation of IPsec packets",
RFC 3948, January 2005.
[RFC3948]HuttunenとA.とSwanderとB.とボルペとV.とDiBurro、L.とM.Stenberg、「IPsecパケットのUDP Encapsulation」RFC3948(2005年1月)。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5226] Narten、T.、およびH.Alvestrand(「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
[mipnat] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519,
April 2003.
[mipnat]LevkowetzとH.とS.Vaarala、「ネットワークアドレス変換(NAT)デバイスのモバイルIP縦断」、RFC3519、2003年4月。
[privaddr] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[privaddr] Rekhter、Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
Vaarala & Klovning Standards Track [Page 32] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[32ページ]。
9.2. Informative References
9.2. 有益な参照
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002,
October 1996.
[RFC2002] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic
Host Configuration Protocol (DHCPv4) Configuration of
IPsec Tunnel Mode", RFC 3456, January 2003.
[RFC3456] パテル、B.、Aboba、B.、ケリー、S.、およびV.グプタ、「IPsecトンネル・モードのDynamic Host Configuration Protocol(DHCPv4)構成」、RFC3456(2003年1月)。
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec
to Protect Mobile IPv6 Signaling Between Mobile Nodes
and Home Agents", RFC 3776, June 2004.
[RFC3776] Arkko、J.、Devarapalli、V.、およびF.デュポン、「モバイルノードとホームのエージェントの間で合図するモバイルIPv6を保護するのにIPsecを使用します」、RFC3776(2004年6月)。
[RFC4093] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile
IPv4 Traversal of Virtual Private Network (VPN)
Gateways", RFC 4093, August 2005.
[RFC4093] Adrangi、F.、およびH.Levkowetz、「問題声明:」 「仮想私設網(VPN)ゲートウェイのモバイルIPv4縦断」、RFC4093、2005年8月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
2005年12月の[RFC4282]AbobaとB.と用務員とM.とArkko、J.とP.Eronen、「ネットワークアクセス識別子」RFC4282。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC4555]Eronen、2006年6月のP.、「IKEv2移動性とマルチホーミングプロトコル(MOBIKE)」RFC4555。
[pseudonat] Dupont, F. and J. Bernard, "Transient pseudo-NAT attacks
or how NATs are even more evil than you believed", Work
in Progress, June 2004.
[pseudonat] デュポン、F.、およびJ.バーナード、「一時的な疑似NAT攻撃かNATsがあなたよりどうさらに不吉であるかが信じていました」、ProgressのWork、2004年6月。
[tessier] Tessier, S., "Guidelines for Mobile IP and IPsec VPN
Usage", Work in Progress, December 2002.
[tessier] テシエ、S.、「モバイルIPとIPsec VPN用法のためのガイドライン」が進歩、2002年12月に働いています。
Vaarala & Klovning Standards Track [Page 33] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[33ページ]。
Appendix A. Packet Flow Examples
付録A.パケット流れの例
A.1. Connection Setup for Access Mode 'cvc'
A.1。 アクセス・モード'cvc'のための接続設定
The following figure illustrates connection setup when the mobile node is outside and using a co-located care-of address. IKE connection setup is not shown in full, and involves multiple round trips (4.5 round trips when using main mode followed by quick mode).
以下の図が可動のノードが外にあるときの接続設定とaが共同場所を見つけた使用を例証する、注意、-、アドレス。 IKE接続設定は、すべて示されないで、複数の周遊旅行を伴います(主なモードを使用するとき、迅速なモードで4.5の周遊旅行が続きました)。
Vaarala & Klovning Standards Track [Page 34] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[34ページ]。
MN-APP MN x-HA VPN i-HA CN
! ! ! ! ! !
! ! -------> ! ! ! !
! ! rrq ! ! ! !
! ! -----------------X ! ! ! rrq not
! ! rrq ! ! ! ! received
! ! ! ! ! ! by i-HA
! ! <------- ! ! ! !
! ! rrp ! ! ! !
! ! ! ! ! !
! [wait for detection period for response from i-HA] !
! [may also retransmit to i-HA, depending on config] ! no rrp
! ! ! ! ! ! from i-HA
! ! ==(1)==> ! ! ! !
! ! ike {1a}! -------> ! ! !
! ! ! ike ! ! !
! ! ! <------- ! ! !
! ! <==(1)== ! ike ! ! !
! ! ike ! ! ! !
: : : : : :
: : : : : :
! ! ! ! ! !
! ! ==(2)==> ! ! ! !
! ! rrq {2a}! ==(1)==> ! ! !
! ! ! rrq {2b}! -------> ! !
! ! ! ! rrq {2c}! !
! ! ! ! <------- ! !
! ! ! <==(1)== ! rrp ! !
! ! <==(2)== ! rrp ! ! !
! ! rrp ! ! ! !
! ! ! ! ! !
[[--- connection setup ok, bidirectional connection up ---]]
! ! ! ! ! !
! -------> ! ! ! ! !
! pkt {3a}! ==(3)==> ! ! ! !
! ! pkt {3b}! ==(2)==> ! ! !
! ! ! pkt {3c}! ==(1)==> ! !
! ! ! ! pkt {3d}! -------> !
! ! ! ! ! pkt {3e}!
! ! ! ! ! <------- !
! ! ! ! <==(1)== ! pkt !
! ! ! <==(2)== ! pkt ! !
! ! <==(3)== ! pkt ! ! !
! <------ ! pkt ! ! ! !
! pkt ! ! ! ! !
: : : : : :
: : : : : :
ミネソタ-APPミネソタ、x、-、ハ、VPN i、-、ハ、CN!------->!rrq!-----------------X!rrqにそうしない、!rrq!が受信された、!i-HA!<。------- ! ! ! ! ! ! また、i-HAに再送するかもしれません、コンフィグ] どんな小売希望価格にもよらないで!小売希望価格![検出の期間、応答はi-HAから待っています] i-HA=(1)=!から、[>!は1aをikeします! ------->!ike!<。------- ! ! ! ! ! <=(1)== ! ike!ike!: : : : : : : : : : : : ! ! ! ! ! ! ! ! ==(2)==>!rrq2a! ==(1)==>!rrq2b! ------->!rrq2c! ! ! ! ! ! <、-、-、-、-、-、-- ! ! ! ! ! <=(1)== ! 小売希望価格!<=(2)=!小売希望価格!小売希望価格!、[-、--、接続設定の間違いなくて、双方向の接続が上である-、--、]------->!pkt3a! ==(3)==>!pkt3b! ==(2)==>!pkt3c! ==(1)==>!pkt3d! ------->!pkt3e! ! ! ! ! ! <、-、-、-、-、-、-- ! ! ! ! ! <=(1)== ! pkt!<=(2)=!pkt!<=(3)=!pkt!<。------ ! pkt!pkt!: : : : : : : : : : : :
Vaarala & Klovning Standards Track [Page 35] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[35ページ]。
The notation "==(N)==>" or "<==(N)==" indicates that the innermost packet has been encapsulated N times, using IP-IP, ESP, or MIP NAT traversal.
記法「=(N)=>」か「<=(N)=」が、最も奥深いパケットがN回カプセルに入れられたのを示します、IP-IP、超能力、またはMIP NAT縦断を使用して。
Packets marked with {xx} are shown in more detail below. Each area
represents a protocol header (labeled). Source and destination
addresses or ports are shown underneath the protocol name when
applicable. Note that there are no NAT traversal headers in the
example packets.
xxでマークされたパケットはさらに詳細に以下で見せられます。 各領域はプロトコルヘッダー(ラベルされる)の代理をします。 適切であるときに、ソースと送付先アドレスかポートがプロトコル名の下で見せられます。 NAT縦断ヘッダーが全く例のパケットにないことに注意してください。
Packet {1a}
.------------------------------------.
! IP ! IP ! UDP ! IKE !
! co-CoA ! x-HoA ! 500 ! !
! x-HA ! VPN-GW ! 500 ! !
`------------------------------------'
パケット1a。------------------------------------. ! IP!'IP!UDP!IKE!ココア!x-HoA500!、x、-、ハ、VPN-GW500!!‘------------------------------------'
Packet {2a}
.--------------------------------------------------------.
! IP ! IP ! ESP ! IP ! UDP ! MIP RRQ !
! co-CoA ! x-HoA ! ! VPN-TIA ! ANY ! !
! x-HA ! VPN-GW ! ! i-HA ! 434 ! !
`--------------------------------------------------------'
パケット2a。--------------------------------------------------------. ! IP!'IP!超能力!IP!UDP!MIP RRQ!ココア!x-HoA!VPN-TIA!いずれ!、もx、-、ハ、VPN-GW!、i、-、ハ、434!‘--------------------------------------------------------'
Packet {2b}
.----------------------------------------------.
! IP ! ESP ! IP ! UDP ! MIP RRQ !
! x-HoA ! ! VPN-TIA ! ANY ! !
! VPN-GW ! ! i-HA ! 434 ! !
`----------------------------------------------'
パケット2b。----------------------------------------------. ! 'IP!超能力!IP!UDP!MIP RRQ!x-HoA!VPN-TIA!いずれ!、もVPN-GW!、i、-、ハ、434!‘----------------------------------------------'
Packet {2c}
.----------------------------.
! IP ! UDP ! MIP RRQ !
! VPN-TIA ! ANY ! !
! i-HA ! 434 ! !
`----------------------------'
パケット2c。----------------------------. ! IP!'UDP!MIP RRQ!VPN-TIA!いずれ!、もi、-、ハ、434!‘----------------------------'
Packet {3a}
.-------------------.
! IP ! user !
! i-HoA ! protocol !
! CN ! !
`-------------------'
パケット3a。-------------------. ! IP!'ユーザ!i-HoA!プロトコル!CN‘!-------------------'
Vaarala & Klovning Standards Track [Page 36] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[36ページ]。
Packet {3b}
.------------------------------------------------------- -
! IP ! IP ! ESP ! IP ! IP ! user \
! co-CoA ! x-HoA ! ! VPN-TIA ! i-HoA ! protocol../
! x-HA ! VPN-GW ! ! i-HA ! CN ! \
`------------------------------------------------------- -
- - -----------------.
\..user ! ESP !
/ protocol ! trailer !
\ ! !
- - -----------------'
パケット3b。------------------------------------------------------- - ! \!共同CoA!IP!IP!超能力!IP!IP!ユーザx-HoA!VPN-TIA!i-HoA!は議定書を作ります。'/!、x、-、ハ、VPN-GW!、i、-、ハ、CN!\‘------------------------------------------------------- - - - -----------------. \..ユーザ!超能力!/プロトコル!トレーラ!\!、--、------------------'
Packet {3c}
.--------------------------------------------------------.
! IP ! ESP ! IP ! IP ! user ! ESP !
! x-HoA ! ! VPN-TIA ! i-HoA ! protocol ! trailer !
! VPN-GW ! ! i-HA ! CN ! ! !
`--------------------------------------------------------'
パケット3c。--------------------------------------------------------. ! IP!'超能力!IP!IP!ユーザ!超能力!x-HoA!VPN-TIA!i-HoA!プロトコル!トレーラ!VPN-GW!i-HA!CN‘!--------------------------------------------------------'
Packet {3d}
.------------------------------.
! IP ! IP ! user !
! VPN-TIA ! i-HoA ! protocol !
! i-HA ! CN ! !
`------------------------------'
パケット3d。------------------------------. ! IP!'IP!ユーザ!VPN-TIA!i-HoA!プロトコル!i-HA!CN‘!------------------------------'
Packet {3e}
.-------------------.
! IP ! user !
! i-HoA ! protocol !
! CN ! !
`-------------------'
パケット3e。-------------------. ! IP!'ユーザ!i-HoA!プロトコル!CN‘!-------------------'
Vaarala & Klovning Standards Track [Page 37] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[37ページ]。
Packet {3b} with all NAT traversal headers (x-MIP, ESP, and i-MIP) is
shown below for comparison.
すべてのNAT縦断ヘッダー(x-MIP、超能力、およびi-MIP)があるパケット3bは比較のために以下で見せられます。
Packet {3b} (with NAT traversal headers)
.------------------------------------------------- -
! IP ! UDP ! MIP ! IP ! UDP ! ESP.. \
! co-CoA ! ANY ! tunnel ! x-HoA ! 4500 ! /
! x-HA ! 434 ! data ! VPN-GW ! 4500 ! \
`------------------------------------------------- -
<=== external MIPv4 ====> <=== IPsec ESP ======== = =
パケット3b(NAT縦断ヘッダーがある)。------------------------------------------------- - ! IP!UDP!MIP!IP!UDP!特に。 '\!共同CoA!どんなVPN-GW!x-HA434!!データ!x-HoA4500!!/!トンネル!4500!円‘------------------------------------------------- - <== 外部のMIPv4====><== IPsec、超能力======== = =
- - ------------------------------------------------ -
\..ESP ! IP ! UDP ! MIP ! IP ! user \
/ ! VPN-TIA ! ANY ! tunnel ! i-HoA ! protocol../
\ ! i-HA ! 434 ! data ! CN ! \
- - ------------------------------------------------ -
= ===> <==== internal MIPv4 ====> <== user packet == =
- - ------------------------------------------------ - \..超能力!IP!UDP!MIP!IP!ユーザ\/!VPN-TIA!何でも、トンネル!i-HoA!は議定書の中で述べます。/、\!i-HA434!!データ!CN!\--、------------------------------------------------- - = ===><== 内部のMIPv4====><= ユーザパケット==
- - -----------------.
\..user ! ESP !
/ protocol ! trailer !
\ ! !
- - -----------------'
= = ======> <= ESP =>
- - -----------------. \..ユーザ!超能力!/プロトコル!トレーラ!\!、--、------------------' = = ======><= 超能力は>と等しいです。
Authors' Addresses
作者のアドレス
Sami Vaarala Codebay P.O. Box 63 Espoo 02601 FINLAND
サミVaarala Codebay P.O. Box63エスポー02601フィンランド
Phone: +358 (0)50 5733 862 EMail: sami.vaarala@iki.fi
以下に電話をしてください。 +358 (0)50 5733 862はメールされます: sami.vaarala@iki.fi
Espen Klovning Birdstep Bryggegata 7 Oslo 0250 NORWAY
エスペンKlovning Birdstep Bryggegata7オスロ0250ノルウェー
Phone: +47 95 20 26 29 EMail: espen@birdstep.com
以下に電話をしてください。 +47 95 20 26 29はメールされます: espen@birdstep.com
Vaarala & Klovning Standards Track [Page 38] RFC 5265 MIPv4-VPN June 2008
Vaarala&Klovning規格はMIPv4-VPN2008年6月にRFC5265を追跡します[38ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を記述してください。
Vaarala & Klovning Standards Track [Page 39]
Vaarala&Klovning標準化過程[39ページ]
一覧
スポンサーリンク
