[要約] 要約：RFC 5265は、IPsecベースのVPNゲートウェイを介したモバイルIPv4トラバーサルに関する仕様です。 目的：このRFCの目的は、モバイルデバイスがIPsecベースのVPNゲートウェイを通過する際のIPv4トラバーサルの問題を解決するためのガイドラインを提供することです。
Network Working Group S. Vaarala
Request for Comments: 5265 Codebay
Category: Standards Track E. Klovning
Birdstep
June 2008
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
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
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
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（非武装ゾーン）の展開の変更を最小限に抑える必要があります。
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の再交渉を回避または最小化するメカニズムを提案する必要があります。
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;
典型的な企業ネットワークは、インターネット（信頼できない外部ネットワーク）、イントラネット（信頼できる内部ネットワーク）、および2つのネットワークを接続するDMZの3つの異なるドメインで構成されています。内部ネットワークへのアクセスは、ファイアウォールとVPNデバイスの両方によってガードされます。
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.
ソリューションは、モバイルノードが内部ネットワークにあるときに標準のモバイルIPv4（ネットワーク検出を支援するために内部ネットワークのホームエージェントが使用する新しい拡張機能を除く）、およびモバイルにVPNトンネルエンドポイントアドレスを使用することです。外部のIPv4登録。IPSECベースのVPNトンネルには、移動後に再交渉が必要です。この制限を克服するために、モバイルIPv4の別の層がIPSECの下で使用され、実際には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 セキュリティ関連がまだ利用できない場合は、インターネットキーエクスチェンジプロトコル（IKE）（またはIKEV2）を使用して、VPNトンネルを確立します。
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 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.
説明されているソリューションは、さまざまな種類のIPSECベースのVPNと互換性があり、特定の種類のVPNは必要ありません。適切なセキュリティポリシーデータベース（SPD）エントリとその他のIKEおよびIPSECの詳細は、展開されたIPSECベースのVPN製品間で異なるため、これらの詳細についてはドキュメントで説明しません。
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を指します。他のタイプのVPNは範囲外です。
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デバイスからの協力を想定することはできません。したがって、他のネットワーキングエンティティとして扱わなければなりません。
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モビリティとマルチホミングプロトコル（MOBIKE）[RFC4555]は、IPSECにより優れたモビリティを提供します。これにより、この仕様で説明されている外部モバイルIPv4レイヤーを削除できます。ただし、Mobikeの展開にはVPNデバイスの変更が必要であるため、この仕様の範囲外です。
co-CoA: co-located care-of address.
Co-Coa：共同住所のケアオブアドレス。
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.
DMZ ：（非武装ゾーン）外部ユーザーが会社のプライベートネットワークに直接アクセスできないようにするために、企業のプライベートネットワークと外部パブリックネットワークの間に「中立ゾーン」として挿入された小さなネットワーク。
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.
外部ネットワーク：信頼されていないネットワーク（つまり、インターネット）。モバイルノードの内部ネットワーク以外のプライベートネットワーク（別のコーポレートネットワークなど）は、外部ネットワークと見なされることに注意してください。
FA: mobile IPv4 foreign agent.
FA：モバイルIPv4外国人エージェント。
FA-CoA: foreign agent care-of address.
FA-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-FA：内部ネットワークに居住するモバイルIPv4外国人エージェント。
i-HA: Mobile IPv4 home agent residing in the internal network; typically has a private address [privaddr].
I-HA：内部ネットワークに住むモバイルIPv4ホームエージェント。通常、プライベートアドレス[privaddr]があります。
i-HoA: home address of the mobile node in the internal home agent.
I-HOA：内部ホームエージェントのモバイルノードのホームアドレス。
MN: mobile node.
MN：モバイルノード。
NAI: Network Access Identifier [RFC4282].
NAI：ネットワークアクセス識別子[RFC4282]。
R: router.
R：ルーター。
VPN: Virtual Private Network based on IPsec.
VPN：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-TIA：VPNトンネル内側アドレス、IKEフェーズ2（クイックモード）中にネゴシエートされたアドレス（ES）は、「事実上」標準的なインターネットセキュリティ協会と主要な管理プロトコルを使用して、IPSEC-DHCP [RFC3456]を使用して手動で割り当てられ、手動で割り当てられました。ISAKMP）構成モード、または他の手段による。一部のVPNクライアントは、建築上の理由で現在のケアオブアドレスをトンネル内側の住所（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接続、またはIPSEC輸送接続と組み合わせたレイヤー2トンネルプロトコル（L2TP）。
x-FA: Mobile IPv4 foreign agent residing in the external network.
X-FA：外部ネットワークに居住するモバイルIPv4外国エージェント。
x-HA: Mobile IPv4 home agent residing in the external network.
X-HA：外部ネットワークに住むモバイルIPv4ホームエージェント。
x-HoA: home address of the mobile node in the external home agent.
X-HOA：外部ホームエージェントのモバイルノードのホームアドレス。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。
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ベースのVPNの現在の展開は、対応するモバイル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 一般的にファイアウォールとDMZの現在の展開は、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の展開に等しいセキュリティレベルを維持するために、IPSECを脱カプセル化するすべてのホームエージェントは、現在のDMZファイアウォール（コンテンツスキャン、接続追跡など）と同じファイアウォールを行う必要があります。
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 さらに、リモートアクセスのためにDMZに個別のVPNデバイスがある場合、ユーザーは両方のデバイスに認証する必要があり、両方に対して個別の資格情報が必要な場合があります。
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 ただし、仮定（内部の場合は暗号化なし）は、ソリューションスペースのすべてのソリューションに必ずしも適用されないことに注意してください。上記の問題が解決した場合、内部に暗号化を適用できなかった根本的な理由はありません。
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.
現在指定されている[RFC4301]のIPSECでは、IPSECのピアが移動するたびに新しいIKE交渉を行う必要があります。つまり、住所のケアを変更します。主な理由は、セキュリティ協会が一方向であり、（1）宛先アドレス（トンネルモードを使用するときの外側のアドレス）、（2）セキュリティプロトコル（セキュリティペイロード（ESP）のカプセル化（ESP）または）で構成されるトリプレットによって識別されることです。認証ヘッダー（AH））、および（3）セキュリティパラメーターインデックス（SPI）（[RFC4301]、セクション4.1）。これらすべてを独自のセキュリティ協会（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ピアによって「所有」されるため、宛先アドレスを変更する必要はありません。（外側の）ソースアドレスは、固定ピアによって無視される必要があります（ただし、一部の実装もソースアドレスを確認します）。
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の交渉中に確立され、交渉時のモバイルピアのケアのケアです。したがって、パケットは、変更された住所ではなく、元の住所に送信されます。
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トラバーサルメカニズムは、モビリティが限られているためにも使用できますが、モバイルと固定ピアの間にNATがない場合でも、UDPトンネルを使用する必要があります。さらに、NATトラバーサル仕様[RFC3947]では、現在のNATマッピングの変化のサポートは必要ありません。
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モビリティとマルチホミングプロトコル（MOBIKE）[RFC4555]は、IPSECにより優れたモビリティを提供します。これにより、この仕様で説明されている外部モバイルIPv4レイヤーを削除できます。ただし、Mobikeの展開にはVPNデバイスの変更が必要であるため、この仕様の範囲外です。
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)).
エンタープライズユーザーは、異なるネットワークテクノロジーを使用して、内部ネットワークと外部ネットワークの両方にアクセスします。一部のネットワークでは、MNはFASを使用し、他のネットワークでは、共同配置モードを使用してHAで固定します。次の図は、内部ネットワークと外部ネットワークの関係、およびモバイルノードの可能な位置（つまり（MN））の可能な場所を示すネットワークトポロジの例を説明しています。
(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}
Figure 1: Basic topology, possible MN locations, and access modes
図1：基本的なトポロジ、可能なMNロケーション、およびアクセスモード
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」はX-MIP層が使用されているかどうかを示し、使用するとモード（ "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"はCo-Coaを示します）。
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：Co-CoA FとのI-MIP：I-MIPとFA-COA CVC：X-MIP CO-COA、VPN-TIAをI-MIP CO-COA FVC：X-MIP with FA-COA、VPN-i-mip co-coaとしての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サーバー、および/または外国人エージェントが含まれる場合があります。現在のIEEE 802.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.
* MNが外側にある場合、NATデバイスはMNと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（S）、またはVPNに統合されたNATがある場合があります。本質的に、図のルーターは、それぞれがゼロ以上のルーターを表すと見なされる場合があり、それぞれがNATおよび/またはイングレスフィルタリングを実行する可能性があります。
* When the MN is inside, there may be NAT devices between the MN and the i-HA.
* MNが中にあるとき、MNと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メッセージおよび/またはフラグメントをブロックするように構成されています。このようなファイアウォール（ルーター）は確実に検出できません。
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:
モバイルノードがCo-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ミップ。
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.
次のサブセクションでは、さまざまなアクセスモードと登録および接続セットアップフェーズの要件について説明します。
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を参照）。
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を参照）。
Steps:
ステップ：
o The mobile node obtains a care-of address.
o モバイルノードは、ケアオブアドレスを取得します。
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-BITは設定されている場合があります（逆トンネリング）。これにより、ファイアウォール関連の接続の問題の確率が最小限に抑えることができます
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セキュリティアソシエーションがない場合、IKEを使用して、X-HOAをIKE/ IPSEC通信のIPアドレスとして使用して、VPNゲートウェイとIPSECセキュリティアソシエーションをセットアップします。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 モバイルノードは、MIPV4登録要求（RRQ）をI-HAに送信し、VPN-TIAを共同開催のケアオブアドレスとして登録します。
* T-bit SHOULD be set (reverse tunneling) (see discussion below)
* T-Bitを設定する必要があります（逆トンネリング）（以下の説明を参照）
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.
IPSECセキュリティポリシーの制限のため、多くの場合、内側のモバイルIPv4レイヤーの逆トンネルが必要です。IPSECセレクターは、IPSECトンネル内で送信されたパケットの許可されたIPアドレスを定義します。典型的なIPSECリモートVPNセレクターは、クライアントアドレスをVPN-TIAに制限します（リモートアドレスはしばしば無制限です）。逆トンネリングが使用されない場合、MNが送信したパケットのソースアドレスは、VPN-TIAとは異なるMNのホームアドレス（I-HAに登録）になり、IPSECセキュリティポリシーに違反します。その結果、パケットがドロップされ、接続ブラックホールが発生します。
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ベースのVPN、特にL2TP/IPSEC VPN（PPP-Over-L2TP-Over-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.
MNは三角形のルーティング、つまり内側のMIPV4レイヤーをスキップすることはできますが、セキュリティ上の理由でVPNレイヤーをスキップしてはなりません。
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-BITは設定されている場合があります（逆トンネリング）。これにより、ファイアウォール関連の接続の問題の確率が最小限に抑えることができます
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 必要に応じて、モバイルノードはIKEを使用して、IKE/IPSEC通信のIPアドレスとしてX-HOAを使用して、VPNゲートウェイとのIPSEC接続を設定します。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 モバイルノードはMIPV4 RRQをI-HAに送信し、VPN-TIAを共同住所のケアオブアドレスとして登録します。
* T-bit SHOULD be set (reverse tunneling) (see discussion in Section 2.3)
* T-Bitを設定する必要があります（逆トンネリング）（セクション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.
MNは三角形のルーティング、つまり内側のMIPV4レイヤーをスキップすることはできますが、セキュリティ上の理由でVPNレイヤーをスキップしてはなりません。
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デバイスは、各レイヤーに個別に影響を与える可能性があります。モバイルIPv4 NATトラバーサル[MIPNAT]はX-MIPおよびI-MIPレイヤーにサポートされ、IPSEC NATトラバーサル[RFC3947] [RFC3948]はVPN層に対してサポートする必要があります。
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 makes VPN client implementation easier. Mobile IPv4 NAT traversal is required to establish a MIPv4 session in this case.
VPNゲートウェイと内部ネットワークの間に個別のNATデバイスがない場合でも、内部MIPV4レイヤーのNATトラバーサルが必要になる場合があることに注意してください。いくつかのVPN実装は、イントラネットにトラフィックをルーティングする前に、NAT VPNトンネル内側アドレスをアドレス指定します。これは展開を容易にするために行われる場合がありますが、場合によっては、このアプローチによりVPNクライアントの実装が容易になります。この場合、MIPV4セッションを確立するには、モバイルIPv4 NATトラバーサルが必要です。
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.
内部ネットワークへのエントリを検出することに加えて、モバイルノードは内部ネットワークを離れるときにも検出する必要があります。内部ネットワークへのエントリはセキュリティの方が簡単です。モバイルノードは、プレーンテキストトラフィックを送信する前に内部ネットワーク内にあることを確認できます。内部ネットワークからの終了を検出するのはより困難であり、イベントが時間内に検出されない場合、MNは誤ってプレーンテキストパケットをリークする可能性があります。
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.
モバイルノードが現在の接続のこのような変更を確実に検出できるかどうかは、実装とネットワークテクノロジーに依存します。たとえば、一部のモバイルノードは、純粋なレイヤー3つのエンティティとして実装される場合があります。モバイルノードソフトウェアがレイヤー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.
モバイルノードがこれらのイベントを適切に検出しない場合、信頼できないネットワークにPlantextトラフィックを漏らす可能性があります。多くのアプローチを使用して、頻繁な再登録からレイヤー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 requirements and the proposed mechanism rely upon are described in Section 3.1.
モバイルノードは、セクション3.2で説明されている要件を満たす検出メカニズムを実装する必要があります。これにより、基本的なセキュリティ要件が満たされます。セクション3.3で説明されている基本的なアルゴリズムは、それを行う1つの方法ですが、代わりに代わりに、または組み合わせて使用できます。要件と提案されたメカニズムが依存しているという仮定は、セクション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に行く外部ネットワークから発信されるトラフィックをブロックするように構成する必要があります。言い換えれば、モバイルノードは、信頼できる内部ネットワークに接続されていない限り、登録要求/登録返信（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は、登録返信に信頼できるネットワーク構成拡張機能を含めることにより、信頼できるソースアドレスのチェックをサポートすることをMNに示す必要があります。I-HAとMNの両方で実装する必要があるこの新しい拡張機能は、セクション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トラフィックであるため、通常のファイアウォール（ステートフルなファイアーでも）は、通常、登録リクエストを送信し、登録返信をファイアウォールで受信することを許可します。
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に示します。
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のステータスについて何も意味しません。
When the mobile node detects that its connection status on a certain network interface changes, the mobile node MUST: o immediately stop relaying user data packets;
モバイルノードが特定のネットワークインターフェイスの接続ステータスが変更されることを検出すると、モバイルノードは次のことが必要です。
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.
接続ステータスの変更を検出するために使用されるメカニズムは、モバイルノードの実装、ネットワークテクノロジー、およびアクセスモードに依存します。
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登録の返信が信頼できるネットワークを構成した拡張機能（セクション3.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が内部にあるときのより頻繁な再登録は、MNがまだ中にあることを保証する簡単な方法です。MNは、内部のときに（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秒以上が経過している場合、データパケットをドロップまたはキューに削除する必要があります。パケットがキューに掲載されている場合、接続ステータスの変更なしに再登録が正常に完了するまで、キューを処理してはなりません。
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との再登録が正常に完了するまで、パケットをドロップまたはキューに（上記で指定したように）削除する必要があります。このアプローチはパケット処理の複雑さを追加しますが、小型のバッテリー駆動のデバイスに適している可能性があります。（MNに到達可能に保つために、モビリティ結合寿命が尽きる前の通常の再登録は尽きることに注意してください。）
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.
再登録メカニズムは、最悪のケースのフォールバックメカニズムです。モバイルノードでは追加情報（レイヤー2トリガーなど）が利用可能な場合、モバイルノードはトリガーを使用してMNの動きを検出し、検出プロセスを再起動して露出を最小限に抑える必要があります。
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の再登録プロセス（結合寿命に基づく）が使用されます。
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.
MNが特定のインターフェイスでネットワーク添付ファイルのポイントを変更したことを検出すると、2つの同時登録要求を発行します。これらの登録リクエストは、返信メッセージが受信されない場合、定期的に再送信されます。
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からの回答を受信した場合、MNはX-HAへの登録要求を再送信する停止を停止し、暫定的に外部にあると判断します。ただし、MNはしばらくの間、I-HAへの登録を再送信し続ける必要があります。MNは、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からの応答が受信され、応答に信頼できるネットワークが構成された拡張機能（セクション3.4）が含まれている場合、MNは内部にあると判断する必要があります。いずれにせよ、MNは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は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.
MNが内部にあることを検出することになった場合、定期的に再登録する必要があります（結合寿命に関係なく）。セクション3.2.4を参照してください。再登録が失敗した場合、MNはプレーンテキストトラフィックの送信と受信を停止する必要があり、検出アルゴリズムを再起動する必要があります。
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.)
Plantextの再登録メッセージは、常にX-HAまたはI-HAに対して、両方ではなく、常に対処されます。これは、MNが最初の登録後、内部であろうと外部であるかどうかを知っているためです。（ただし、モバイルノードが外側にある場合、プレーンテキストを使用して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セッションを中止することは、セッションをきれいに終了するための信頼性が高く、標準化された、必須の実装メカニズムを提供しないため、場合によっては問題になる可能性があります。
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はI-HAに直接再登録する必要があります。
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]:
この拡張機能は、スキップ可能な拡張機能です。拡張機能を送信する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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 149
タイプ149
Length 2
長さ2
Sub-Type 0
サブタイプ0
Reserved Set to 0 when sending, ignored when receiving
送信時に予約セットは0に設定され、受け取るときに無視されます
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.
MNが並列検出アルゴリズムを使用し、FAを使用している場合、MNは同じMedia 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にとってさらに困難であり、既存のFAが状況を正しく扱っていないことはほぼ確実です。したがって、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.
とにかく、MNが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: o a domain name in a DHCPDISCOVER / DHCPOFFER message
モバイルノードは、次のヒントを使用して内部にあると判断する場合がありますが、とにかくi-HAの到達可能性を検証する必要があります。
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.
たとえば、MNが内部にあると信じる理由がある場合、しばらくの間X-HAに登録要求の送信を延期する可能性があります。同様に、MNが外部にあると信じる理由がある場合、X-HAから登録返信を受信した直後にIPSEC接続のセットアップを開始する可能性があります。ただし、MNがIPSEC接続セットアップが開始された後、I-HAから登録返信を受け取った場合、MNはI-HAの使用に直接切り替える必要があります。
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を使用する必要があります。それ以外の場合、モバイルノードを簡単にトリックしてPlantextを使用できます。
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 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.
ファイアウォール構成エラーは、壊滅的なデータセキュリティの結果（外部攻撃者へのユーザーデータのサイレントエクスポージャー）をもたらす可能性があるため、I-HAによって個別の保護メカニズムが提供されます。I-HAは、管理者が信頼できるネットワークのリストで構成する必要があります。I-HAは、登録返信拡張子を使用して、登録要求ソースアドレスが信頼されていることを知っていることを宣伝しています（信頼できるネットワークは拡張機能を構成します、セクション3.4）。この拡張機能がなければ、MNは登録の成功に依存して、内部ネットワークに接続されていることを示すことはできません。これにより、ファイアウォールとI-HAの両方が誤って構成されていない限り、ユーザーデータの妥協が発生しないようにします。さらに、信頼されていないアドレスからの登録要求の発生は、I-HAによって記録され、管理者のレビューにさらされる必要があります。
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.
内部ネットワーク監視の現在の要件は、フォールバックメカニズムとして追加されました。
If encryption was applied also when MN was inside, there would be no security reason to monitor the internal network periodically.
MNが中にあるときにも暗号化が適用された場合、内部ネットワークを定期的に監視するセキュリティ理由はありません。
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.
MNが内部にあるときに暗号化を適用できない理由の主な理論的根拠は、セクション1.6で与えられました。要するに、主な問題は（1）電力消費です。（2）特に内部ネットワークは通常、ネットワークが切り替えられており、多くのデータが日常的に転送される可能性があるため、追加のCPU負荷。（3）既存のHAデバイスは通常、IPSEC機能を統合しません。（4）（IPSEC）暗号化にはユーザー認証が必要です。ユーザー認証は、場合によってはインタラクティブな場合（例：Securid）、したがって使いやすさの問題です。（5）ユーザーは、DMZとHAのVPNデバイスの個別の資格情報を持っている必要がある場合があります。
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 that relayed the packet) whether or not the registration request came from inside.
このアプローチは、企業がVPNとX-HAの両方を所有しているシナリオのプロトコルの変更なしに実行可能です。X-HAは、登録要求が内部から来たかどうかにかかわらず、着信インターフェイス識別子（またはパケットを中継したルーター）に基づいて単純に決定できます。
In other scenarios, protocol changes may be needed. Such changes are out of scope of this document.
他のシナリオでは、プロトコルの変更が必要になる場合があります。このような変更は、このドキュメントの範囲外です。
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に記載されている要件を満たす内部ネットワーク検出アルゴリズムを実装する必要があります。新しい構成可能なMNパラメーターであるT_MONITORが必要です。このパラメーターの値は、セキュリティとシグナリングオーバーヘッドの量のバランスを反映しているため、構成可能である必要があります。さらに、内部ネットワーク検出を行う場合、I-HAからの登録返信に信頼できるネットワーク構成拡張機能が含まれていない限り、MNはIPSEC保護を無効にしてはなりません（セクション3.4）。
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.
モバイルノードは、内部および外部モバイルIPの両方でモバイルIPv4 NATトラバーサル[MIPNAT]をサポートする必要があります。
The mobile node SHOULD support IPsec NAT traversal [RFC3947] [RFC3948].
モバイルノードは、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レイヤーのみを使用して、ファイアウォールと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ポリシーは、エンタープライズネットワークとの間で送信されるすべてのトラフィックを暗号化するように構成する必要があります。特定のセキュリティポリシーデータベース（SPD）エントリは、特定のVPNのタイプと構成に依存します（たとえば、プレーンIPSEC対L2TP/IPSEC、フルトンネルまたはスプリットトンネリング）。
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.
VPNセキュリティポリシーは、Home Agent Port 434および任意のリモートポートを使用して、UDPを内部ホームエージェントに使用する通信を許可する必要があります。セキュリティポリシーでは、UDPポート434に加えて、IP-IPが内部ホームエージェントに許可される必要があります。
The VPN device SHOULD implement the IPsec NAT traversal mechanism described in [RFC3947] and [RFC3948].
VPNデバイスは、[RFC3947]および[RFC3948]に記載されているIPSEC NATトラバーサルメカニズムを実装する必要があります。
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.)
ホームエージェントは、[MIPNAT]で説明されているモバイルIPv4 NATトラバーサルメカニズムを実装する必要があります。（これは、I-HAを指します。NATVPNトンネルがIP-IPトラフィックをブロックするVPNをサポートするには、NATトラバーサルが必要です。）
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 構成された信頼できるサブネットの内部にないソースアドレスから登録リクエストを拒否する必要があります。これらのドロップされた登録リクエストはログに記録する必要があります。
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 信頼できる住所からの登録要求に応じて送信された登録返信に、信頼できるネットワーク構成拡張機能（セクション3.4）を含める必要があります。
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で説明されているガイドラインと、オプションのメカニズムの有無にかかわらずパケット間接費の追加分析との比較を示します。
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 このソリューションは、トラフィックのステートフルなフィルタリングを回避するための構成の変更以外の既存の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デバイスでの新しいプロトコルの実装を必要としません。
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プロトコルに準拠していますが、内部ネットワーク検出の信頼性を向上させるために、新しい信頼できるネットワークが拡張機能を構成する必要があります。
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の再交渉を回避するメカニズムを提供します。
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 このソリューションは、既存のMIPV4 NATトラバーサル[MIPNAT]およびIPSEC NATトラバーサル[RFC3947] [RFC3948]ソリューションを活用し、NATに対処するために新しい機能を必要としません。
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 provided by IPsec is not compromised by a faulty detection mechanism.
o このソリューションでは、モバイルノードが内部ネットワークにあるか外部ネットワークにあるかを検出するための新しいメカニズムが必要です。このメカニズムのセキュリティは、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で説明します。
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 ESP：57オクテット合計、20（新しいIPヘッダー）、4 4 8 = 16（SPI、シーケンス番号、暗号初期化ベクトル）、7 2 = 9（パディング、パディング長、次のヘッダーフィールド）、12（ESP認証トレーラー）
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を使用すると、各ESPパケットにさまざまな量のパディングが存在します。図は、64ビットのブロックサイズ、9オクテットのオーバーヘッド（次のヘッダーフィールド、パディング長、パディングフィールド、パディングの7オクテット）のパディングのパディングで計算されました。[RFC4303]のセクション2.4を参照）、および12オクテットのESP認証フィールドを参照してください。（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トラバーサルオーバーヘッドは含まれておらず、IPSEC NAT Traversal [RFC3947] [RFC3948]が使用され、MIP NAT Traversal [MIPNAT]が使用される場合は12オクテットを使用する8オクテットを追加します。たとえば、アクセスモードCVCを使用する場合、最大NATトラバーサルオーバーヘッドは12 8 12 = 32オクテットです。したがって、最悪のシナリオ（上記のESP仮定を使用）は、CVCの129オクテットです。
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.
MNが内部にある場合、MNが提案された並列登録シーケンスを実装する場合、接続セットアップのレイテンシは標準MIPV4と比較して増加しません（セクション3.3を参照）。I-HAとのRRQ/ RRPメッセージを交換すると、MNが内部であることが確認され、MNはユーザートラフィックの送信と受信をすぐに開始する可能性があります。同じ理由で、内部ネットワークの携帯電話は、標準の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.
MNが外にあるとき、状況はわずかに異なります。初期接続のレイテンシーは、基本的に（1）X-HAとの登録、（2）オプションの検出遅延（I-HA応答を待機）、（3）IPSEC接続セットアップ（IKE）、および（4）iとの登録で構成されています。-ha。（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に匹敵するパフォーマンスを持っています。MNは単に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.
MNは、X-HA登録が成功した場合にIKEをトリガーする前にI-HA応答を待たずに（2）成功する可能性が最も高いRRQを送信する前にI-HA応答を待たないことによりレイテンシを最小限に抑えることができます（たとえば、MNが最も可能性が高い場合）。これらは、ネットワークに関するヒューリスティックに基づいて実行できます。たとえば、アドレス、デフォルトゲートウェイのMACアドレス（モバイルノードは以前のアクセスから覚えている場合があります）。以前のアクセスネットワークに基づいています（つまり、内側および外側の外側の動きに最適化）。等
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接続セットアップパケットを目撃していないため、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がI-HAとの共同配置されたケアオブアドレスとして登録されると、すべてのモバイルノードトラフィックがファイアウォールのIP-IPとして表示されます。
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カプセル化されたトラフィックでも、多くのファイアウォール製品でトラフィックポリシーを構成できます。これが行われた場合、同様の状態性の問題が発生する可能性があります。
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接続からのトラフィックをルーティングすることを許可する必要があります。これがどのように行われるかは、このドキュメントの範囲外です。
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.
多くのファイアウォールには、異常なパターンと攻撃の明確な兆候についてネットワークトラフィックを監視する侵入検知システムが組み込まれています。この仕様を実装するモバイルノードからのトラフィックは、UDPからI-HAポート434、場合によってはI-HAアドレスへのIP-IPトラフィックであるため、既存のIDSSは、通常のVPNリモートアクセストラフィックとは異なる方法でトラフィックを処理する可能性があります。ファイアウォールと同様に、IDSは標準化されていないため、特定のIDSシステムとの相互運用性を保証することは不可能です。
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）の柔軟なフレームワークが必要であることを意味します。
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.
このソリューションは、モバイルノードに登録に適したアドレスを備えたIPv4接続が提供されていれば、IPSECベースではないVPNトンネルプロトコルでも機能します。ただし、そのようなVPNプロトコルは明示的に考慮されていません。
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.
モバイルノードが誤ってそれが内部ネットワーク内にあると考え、Plantextパケットを送信すると、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は、信頼できるソースアドレス（つまり、内部ネットワークに属するアドレス）で構成する必要があり、新しい信頼できるネットワーク構成拡張機能にこれを示すことを含める必要があります。MNは、この拡張子が登録返信に存在しない限り、内部ネットワークに接続されることの兆候として登録を信頼しないようにする必要があります。したがって、ユーザーデータの機密性を実際に侵害するには、エンタープライズファイアウォールと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とホームアドレスを含む独自のアイデンティティ、および認証因子値が明らかになります信頼されていないネットワークへの認証拡張機能。これは、いくつかの展開の懸念事項かもしれません。
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の情報が利用可能であると予想され、接続変更の検出が高速かつ堅牢になります。そのような情報が利用できない（または何らかの理由で失敗する）ケースをカバーするには、モバイルノードが内部ホームエージェントと定期的に再登録して、信頼できるネットワークにまだ接続されていることを確認する必要があります。また、この再登録間隔を構成可能にする必要があります。したがって、管理者に潜在的な露出を制御できるパラメーターを提供します。
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（認証されたDiffie-Hellman Exchange）を使用してセッションキーをセットアップします。したがって、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が2つのIPSECエンドポイント間のネットワークを何らかの方法で安全であるとは考えていないため、他の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の弱い秘密はセキュリティにとって致命的であることに注意してください。IHAの秘密が壊れた場合、モバイルノードは暗号化のドロップにだまされる可能性があるためです。
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トラバーサルが有効であると仮定して（通常はそうです）。「Pseudo 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 Traversalを使用）を検討する場合、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パケットがキャッチおよび変更される必要があります。
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（RFC 3344）またはプレフィックス接尾辞MD5（RFC 2002）を使用しています。さらに、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）で使用される場合、主要な管理プロパティはBasic MIPV4のプロパティよりも優れています。したがって、MIPV4をシステムに追加すると、キー管理がより複雑になります。
o In general, adding new security mechanisms increases overall complexity and makes the system more difficult to understand.
o 一般に、新しいセキュリティメカニズムを追加すると、全体的な複雑さが向上し、システムの理解がより困難になります。
This document specifies a new skippable extension (in the short format) in Section 3.4, whose Type and Sub-Type values have been assigned.
このドキュメントは、セクション3.4の新しいスキップ可能な拡張機能（短い形式）を指定しています。そのタイプとサブタイプの値が割り当てられています。
Allocation of new Sub-Type values can be made via Expert Review and Specification Required [RFC5226].
新しいサブタイプの値の割り当ては、専門家のレビューと必要な仕様を介して行うことができます[RFC5226]。
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.)
- Farid Adrangi（Intel Corporation）-Nitsan Baididider（Check Point Software Technologies、Inc。）-Gopal Dommety（Cisco Systems）-Eli Gelasco（Cisco Systems） - Dorothy Gellert（Nokia Corporation） - Espen Kloving（Birdstep）-Milind Kulkarni（Ciscoシステム） - Henrik Levkowetz（IpunPlugged AB） - Frode Nielsen（Birdstep）-Sami Vaarala（CodeBay）-Qiang Zhang（Liqwid Networks、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 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.
著者は、MIP/VPNデザインチーム、特にマイク・アンドリュース、ガエタン・フェイジ、プラカシュ・アイアー、ブリエシュ・クマール、ジョー・ラウ、ケント・レオン、ガブリエル・モンテネグロ、ランジット・ナルジャラ、アントティ・ヌオッポネン、アラン・パテル、アルペシュ・パテル、アイリンPietikainen、Phil Roberts、Hans Sjostrand、Serge Tessierの継続的なフィードバックとこのドキュメントの改善を支援してくれました。ドキュメントに徹底的な読み物とセキュリティレビューを提供してくれたRadia Perlmanに感謝します。トム・ヒラーは、バッテリー駆動のデバイスに関する問題を指摘しました。また、重要なフィードバックとガイダンスについて、以前のモバイルIPワーキンググループチェア（Gabriel Montenegro、Basavaraj Patil、およびPhil Roberts）にも感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C.、ed。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[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. Volpe、「IKEにおけるNat-Traversalの交渉」、RFC 3947、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.、Volpe、V.、Diburro、L。、およびM. Stenberg、「IPSecパケットのUDPカプセル化」、RFC 3948、2005年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、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考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[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トラバーサル」、RFC 3519、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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス配分」、BCP 5、RFC 1918、1996年2月。
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[RFC2002] Perkins、C。、「IP Mobility Support」、RFC 2002、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] Patel、B.、Aboba、B.、Kelly、S。、およびV. Gupta、「Ipsecトンネルモードの動的ホスト構成プロトコル（DHCPV4）構成」、RFC 3456、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. Dupont、「IPSECを使用してモバイルノードとホームエージェント間のモバイルIPv6シグナル伝達を保護する」、2004年6月、RFC 3776。
[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トラバーサル」、RFC 4093、2005年8月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「ネットワークアクセス識別子」、RFC 4282、2005年12月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555] Eronen、P。、「IKEV2モビリティおよびマルチホミングプロトコル（MOBIKE）」、RFC 4555、2006年6月。
[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] Dupont、F。and J. Bernard、「一時的な擬似ナット攻撃またはあなたが信じていたよりもさらに邪悪である」、2004年6月、進行中の作業。
[tessier] Tessier, S., "Guidelines for Mobile IP and IPsec VPN Usage", Work in Progress, December 2002.
[Tessier] Tessier、S。、「モバイルIPおよびIPSEC VPN使用のガイドライン」、2002年12月、進行中の作業。
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).
次の図は、モバイルノードが外側にあり、コロアケアオブアドレスを使用しているときの接続セットアップを示しています。IKE接続のセットアップは完全には表示されず、複数のラウンド旅行（メインモードを使用してクイックモードを使用する場合の4.5ラウンドトリップ）が含まれます。
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 ! ! ! ! !
: : : : : :
: : : : : :
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）==」は、IP-IP、ESP、またはMIP NATトラバーサルを使用して、最も内側のパケットがn回カプセル化されていることを示します。
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 ! !
`------------------------------------'
Packet {2a}
.--------------------------------------------------------.
! IP ! IP ! ESP ! IP ! UDP ! MIP RRQ !
! co-CoA ! x-HoA ! ! VPN-TIA ! ANY ! !
! x-HA ! VPN-GW ! ! i-HA ! 434 ! !
`--------------------------------------------------------'
Packet {2b}
.----------------------------------------------.
! IP ! ESP ! IP ! UDP ! MIP RRQ !
! x-HoA ! ! VPN-TIA ! ANY ! !
! VPN-GW ! ! i-HA ! 434 ! !
`----------------------------------------------'
Packet {2c}
.----------------------------.
! IP ! UDP ! MIP RRQ !
! VPN-TIA ! ANY ! !
! i-HA ! 434 ! !
`----------------------------'
Packet {3a}
.-------------------.
! IP ! user !
! i-HoA ! protocol !
! CN ! !
`-------------------'
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 !
\ ! !
- - -----------------'
Packet {3c}
.--------------------------------------------------------.
! IP ! ESP ! IP ! IP ! user ! ESP !
! x-HoA ! ! VPN-TIA ! i-HoA ! protocol ! trailer !
! VPN-GW ! ! i-HA ! CN ! ! !
`--------------------------------------------------------'
Packet {3d}
.------------------------------.
! IP ! IP ! user !
! VPN-TIA ! i-HoA ! protocol !
! i-HA ! CN ! !
`------------------------------'
Packet {3e}
.-------------------.
! IP ! user !
! i-HoA ! protocol !
! CN ! !
`-------------------'
Packet {3b} with all NAT traversal headers (x-MIP, ESP, and i-MIP) is shown below for comparison.
比較のために、すべてのNATトラバーサルヘッダー（X-MIP、ESP、および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 ======== = =
- - ------------------------------------------------ -
\..ESP ! IP ! UDP ! MIP ! IP ! user \
/ ! VPN-TIA ! ANY ! tunnel ! i-HoA ! protocol../
\ ! i-HA ! 434 ! data ! CN ! \
- - ------------------------------------------------ -
= ===> <==== internal MIPv4 ====> <== user packet == =
- - -----------------.
\..user ! ESP !
/ protocol ! trailer !
\ ! !
- - -----------------'
= = ======> <= ESP =>
Authors' Addresses
著者のアドレス
Sami Vaarala Codebay P.O. Box 63 Espoo 02601 FINLAND
Sami Vaarala CodeBay P.O.Box 63 Espoo 02601フィンランド
Phone: +358 (0)50 5733 862
EMail: sami.vaarala@iki.fi
Espen Klovning Birdstep Bryggegata 7 Oslo 0250 NORWAY
espen klovning birdstep bryggegata 7 oslo 0250ノルウェー
Phone: +47 95 20 26 29
EMail: espen@birdstep.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。