[要約] RFC 2356は、SunのSKIPファイアウォールトラバーサルをモバイルIPに適用するための仕様です。このRFCの目的は、モバイルIP環境でのファイアウォールトラバーサルの問題を解決するための方法を提案することです。
Network Working Group G. Montenegro
Request for Comments: 2356 V. Gupta
Category: Informational Sun Microsystems, Inc.
June 1998
Sun's SKIP Firewall Traversal for Mobile IP
モバイルIP向けのSunのSKIPファイアウォールトラバーサル
Status of This Memo
本文書の状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。このメモは、いかなる種類のインターネット標準も指定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. Mobility implies higher security risks than static operation, because the traffic may at times take unforeseen network paths with unknown or unpredictable security characteristics. The Mobile IP specification makes no provisions for securing data traffic. The mechanisms described in this document allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network.
モバイルIP仕様は、モバイルホストがネットワークへの接続ポイントを変更するときに、同じIPアドレスを維持して使用できるようにするメカニズムを確立します。モビリティは、静的な操作よりもセキュリティリスクが高いことを意味します。これは、トラフィックが、未知の、または予測できないセキュリティ特性を持つ予期しないネットワークパスをたどることがあるためです。モバイルIP仕様では、データトラフィックを保護するための規定はありません。このドキュメントで説明されているメカニズムにより、インターネットの公共部門のモバイルノードがSKIPファイアウォールを通過するアクセスをネゴシエートし、そのホームネットワークへの安全なチャネルを構築できます。
In addition to securing traffic, our mechanisms allow a mobile node to roam into regions that (1) impose ingress filtering, and (2) use a different address space.
トラフィックの保護に加えて、モバイルノードは、（1）イングレスフィルタリングを適用し、（2）別のアドレススペースを使用するリージョンにモバイルノードがローミングできるようにします。
Table of Contents
目次
1. Introduction ............................................... 2
2. Mobility without a Firewall ................................ 4
3. Restrictions imposed by a Firewall ......................... 4
4. Two Firewall Options: Application relay and IP Security .... 5
4.1 SOCKS version 5 [4] ....................................... 5
4.2 SKIP [3] .................................................. 6
5. Agents and Mobile Node Configurations ...................... 8
6. Supporting Mobile IP: Secure Channel Configurations ........ 9
6.1 I: Encryption only Outside of Private Network ............. 9
6.2 II: End-to-End Encryption ................................. 10
6.3 III: End-to-End Encryption, Intermediate Authentication ... 10
6.4 IV: Encryption Inside and Outside ......................... 10
6.5 Choosing a Secure Channel Configuration ................... 11
7. Mobile IP Registration Procedure with a SKIP Firewall ...... 11
7.1. Registration Request through the Firewall ................ 12
7.1.1. On the Outside (Public) Network ........................ 13
7.1.2. On the Inside (Private) Network ........................ 14
7.2. Registration Reply through the Firewall .................. 14
7.2.1. On the Inside (Private) Network ........................ 15
7.2.2. On the Outside (Public) Network ........................ 15
7.3. Traversal Extension ...................................... 16
8. Data Transfer .............................................. 18
8.1. Data Packet From the Mobile Node to a Correspondent Node . 18
8.2. Data Packet From a Correspondent Node to the Mobile Node . 19
8.2.1 Within the Inside (Private) Network ..................... 20
8.2.2. On the Outside (Public) Network ........................ 21
9. Security Considerations .................................... 21
Acknowledgements .............................................. 22
References .................................................... 22
Authors' Addresses ............................................ 23
Full Copyright Statement ...................................... 24
This document specifies what support is required at the firewall, the Mobile IP [1] home agent and the Mobile IP mobile node to enable the latter to access a private network from the Internet. For example, a company employee could attach his/her laptop to some Internet access point by:
このドキュメントでは、ファイアウォール、モバイルIP [1]ホームエージェント、モバイルIPモバイルノードがインターネットからプライベートネットワークにアクセスできるようにするために、ファイアウォールでどのようなサポートが必要であるかを説明します。たとえば、会社の従業員は自分のラップトップをインターネットアクセスポイントに接続することができます。
a) Dialing into a PPP/SLIP account on an Internet service provider's network.
a) インターネットサービスプロバイダーのネットワーク上のPPP / SLIPアカウントにダイヤルする。
b) Connecting into a 10Base-T or similar LAN network available at, for example, an IETF terminal room, a local university, or another company's premises.
b) たとえば、IETFターミナルルーム、地元の大学、または別の会社の施設で利用可能な10Base-Tまたは同様のLANネットワークに接続する。
Notice that in these examples, the mobile node's relevant interface (PPP or 10Base-T) is configured with an IP address different from that which it uses "normally" (i.e. at the office). Furthermore, the IP address used is not necessarily a fixed assignment. It may be assigned temporarily and dynamically at the beginning of the session (e.g. by IPCP in the PPP case, or DHCP in the 10Base-T case).
これらの例では、モバイルノードの関連インターフェース（PPPまたは10Base-T）が、「通常」（オフィスなどで）使用するものとは異なるIPアドレスで構成されていることに注意してください。さらに、使用されるIPアドレスは必ずしも固定された割り当てではありません。セッションの開始時に一時的かつ動的に割り当てられる場合があります（PPPの場合はIPCP、10Base-Tの場合はDHCPによって）。
The following discussion assumes a network configuration consisting of a private network separated by a firewall from the general Internet or public network. The systems involved are:
以下の説明では、ファイアウォールによって一般的なインターネットまたはパブリックネットワークから分離されたプライベートネットワークで構成されるネットワーク構成を想定しています。関連するシステムは次のとおりです。
Private Network
プライベートネットワーク
A protected network separated from the Internet by hosts enforcing access restrictions (firewalls). A private network may use a private address space, and its addresses may not even be routable by the general internet.
アクセス制限（ファイアウォール）を実施するホストによってインターネットから分離された保護されたネットワーク。プライベートネットワークはプライベートアドレス空間を使用する場合があり、そのアドレスは一般的なインターネットでルーティングできない場合もあります。
Public Network
公共のネットワーク
The Internet at large. Hosts are able to communicate with each other throughout the public network without firewall-imposed restrictions.
インターネット全般。ホストは、ファイアウォールによる制限なしに、パブリックネットワーク全体で相互に通信できます。
Mobile Node (MN)
モバイルノード（MN）
Its permanent address falls within the range of the private network. The user removes the system from its home network, and connects it to the Internet at another point. The mechanisms outlined in this discussion render this mobility transparent: the mobile node continues accessing its home network and its resources exactly as if it were still within it. Notice that when the mobile node leaves its home network, it may migrate both within and outside of the private network's boundaries. As defined by Mobile IP [1], a mobile node uses a care-of address while roaming.
その恒久的なアドレスは、プライベートネットワークの範囲内にあります。ユーザーはシステムをホームネットワークから削除し、別のポイントでインターネットに接続します。この説明で概説されているメカニズムは、このモビリティを透過的にします。モバイルノードはホームネットワークとそのリソースに、まるでまだそこにいるかのようにアクセスし続けます。モバイルノードがホームネットワークを離れると、プライベートネットワークの境界の内外を移動する場合があります。モバイルIP [1]で定義されているように、モバイルノードはローミング中に気付アドレスを使用します。
Home Agent (HA) for the mobile node
モバイルノードのホームエージェント（HA）
Serves as a location registry and router as described in the Mobile IP IETF draft.
モバイルIP IETFドラフトで説明されているように、ロケーションレジストリおよびルーターとして機能します。
Foreign Agent (FA)
外国エージェント（FA）
Serves as a registration relayer and care of address for the mobile node as described in the Mobile IP IETF draft.
モバイルIP IETFドラフトで説明されているように、モバイルノードの登録リレーおよび気付アドレスとして機能します。
Correspondent Node (CH)
コレスポンデントノード（CH）
A system that is exchanging data packets with the mobile node.
モバイルノードとデータパケットを交換するシステム。
Firewall (FW)
ファイアウォール（FW）
The system (or collection of systems) that enforces access control between the private network and the general Internet. It may do so by a combination of functions such as application gatewaying, packet filtering and cryptographic techniques.
プライベートネットワークと一般的なインターネット間のアクセス制御を実施するシステム（またはシステムの集合）。これは、アプリケーションゲートウェイ、パケットフィルタリング、暗号化技術などの機能を組み合わせることで実現できます。
The mechanisms described in this document allow a mobile node out on a public sector of the network to negotiate access past a SKIP firewall, and construct a secure channel into its home network. This enables it to communicate with correspondent nodes that belong to the private network, and, if bi-directional tunnels are used, with external hosts that are reachable when the mobile node is at home. The mobile node enjoys the same level of connectivity and privacy as it does when it is in its home network.
このドキュメントで説明されているメカニズムにより、ネットワークのパブリックセクターにあるモバイルノードは、SKIPファイアウォールを通過するアクセスをネゴシエートし、ホームネットワークへの安全なチャネルを構築できます。これにより、プライベートネットワークに属する対応するノードと通信できます。双方向トンネルが使用されている場合は、モバイルノードが自宅にいるときに到達可能な外部ホストと通信できます。モバイルノードは、ホームネットワークにいるときと同じレベルの接続性とプライバシーを享受します。
This document does not address the scenario in which the mobile node attempts to access its private network, while within another private network.
このドキュメントでは、モバイルノードが別のプライベートネットワーク内でプライベートネットワークにアクセスしようとするシナリオは扱いません。
Sections 2 and 3 provide an overview of the environment being considered and the restrictions it imposes. Section 4 examines firewall technologies. Section 5 discusses the best mode of operation of the participating entities from the point of view of Mobile IP. Section 6 discusses possible configuration for the secure channel. Finally, packet formats are the topic of sections 7 and 8.
セクション2と3は、考慮されている環境の概要とそれが課す制限を提供します。セクション4では、ファイアウォールテクノロジーについて説明します。セクション5では、モバイルIPの観点から、参加エンティティの最適な運用モードについて説明します。セクション6では、セキュアチャネルの可能な構成について説明します。最後に、パケット形式はセクション7と8のトピックです。
Suppose the mobile node is roaming throughout the general Internet, but its home network is not protected by a firewall. This is typically found in academic environment as opposed to corporate networks.
モバイルノードが一般的なインターネット全体をローミングしているが、そのホームネットワークはファイアウォールで保護されていないとします。これは通常、企業ネットワークではなく、学術環境で見られます。
This works as prescribed by Mobile IP [1]. The only proviso is that the mobile node would most probably operate with a co-located address instead of using a separate foreign agent's care-of address. This is because, at least in the near term, it is far more likely to be able to secure a temporary care-of-address than it is to find a foreign agent already deployed at the site you are visiting. For example:
これはモバイルIP [1]で規定されているとおりに機能します。唯一の条件は、モバイルノードが、別の外部エージェントの気付アドレスを使用する代わりに、同じ場所にあるアドレスで動作する可能性が高いことです。これは、少なくとも短期的には、訪問しているサイトですでに展開されている外来エージェントを見つけるよりも、一時的な気付アドレスを確保できる可能性がはるかに高いためです。例えば：
- Internet Service Provider: pre-assigns customers IP addresses, or assigns them out dynamically via PPP's address negotiation.
- インターネットサービスプロバイダー：顧客のIPアドレスを事前に割り当てるか、PPPのアドレスネゴシエーションを介して動的に割り当てます。
- An IETF terminal room may pre-assign addresses for your use or offer DHCP services.
- IETFのターミナルルームは、使用するアドレスを事前に割り当てるか、DHCPサービスを提供する場合があります。
- Other locations probably would offer DHCP services.
- 他の場所はおそらくDHCPサービスを提供するでしょう。
The firewall imposes restrictions on packets entering or leaving the private network. Packets are not allowed through unless they conform to a filtering specification, or unless there is a negotiation involving some sort of authentication.
ファイアウォールは、プライベートネットワークに出入りするパケットに制限を課します。パケットは、フィルタリング仕様に準拠していない限り、または何らかの認証を伴うネゴシエーションがない限り、通過を許可されません。
Another restriction is imposed by the separation between private addresses and general Internet addresses. Strictly speaking, this is not imposed by a firewall, but by the characteristics of the private network. For example, if a packet destined to an internal address originates in the general Internet, it will probably not be delivered. It is not that the firewall drops it. Rather, the Internet's routing fabric is unable to process it. This elicits an ICMP host unreachable packet sent back to the originating node.
プライベートアドレスと一般的なインターネットアドレスの分離によって、別の制限が課されます。厳密に言うと、これはファイアウォールではなく、プライベートネットワークの特性によるものです。たとえば、内部アドレス宛てのパケットが一般的なインターネットから発信された場合、そのパケットはおそらく配信されません。ファイアウォールがそれを落とすということではありません。むしろ、インターネットのルーティングファブリックはそれを処理できません。これにより、ICMPホストの到達不能パケットが発信ノードに送り返されます。
Because of this, the firewall MUST be explicitly targeted as the destination node by outside packets seeking to enter the private network. The routing fabric in the general Internet will only see the public address of the firewall and route accordingly. Once the packet arrives at the firewall, the real packet destined to a private address is recovered.
このため、ファイアウォールは、プライベートネットワークに入ろうとする外部パケットによって、宛先ノードとして明示的にターゲットにする必要があります。一般的なインターネットのルーティングファブリックは、ファイアウォールのパブリックアドレスのみを認識し、それに応じてルーティングします。パケットがファイアウォールに到着すると、プライベートアドレス宛の実際のパケットが復元されます。
Before delving into any details, lets examine two technologies which may provide firewall support for mobile nodes:
詳細を説明する前に、モバイルノードにファイアウォールサポートを提供する可能性のある2つのテクノロジーを見てみましょう。
- application relaying or proxying, or
- アプリケーションのリレーまたはプロキシ、または
- IP Security.
- IPセキュリティ。
To understand the implications, let's examine two specific schemes to accomplish the above: SOCKS version 5 and SKIP.
その影響を理解するために、SOCKSバージョン5とSKIPの2つを検討して、上記を実現します。
There is an effort within the authenticated firewall traversal WG (aft) of the IETF to provide a common interface for application relays.
アプリケーションリレーに共通のインターフェイスを提供するために、IETFの認証されたファイアウォールトラバーサルWG（後方）内での取り組みがあります。
The solution being proposed is a revised specification of the SOCKS protocol. Version 5 has been extended to include UDP services as well. The SOCKS solution requires that the mobile node -- or another node on its behalf -- establish a TCP session to exchange UDP traffic with the FW. It also has to use the SOCKS library to encapsulate the traffic meant for the FW. The steps required by a SOCKS solution are:
提案されているソリューションは、SOCKSプロトコルの改訂仕様です。バージョン5が拡張され、UDPサービスも含まれるようになりました。 SOCKSソリューションでは、モバイルノードまたはその代わりの別のノードがTCPセッションを確立して、FWとUDPトラフィックを交換する必要があります。また、FW向けのトラフィックをカプセル化するためにSOCKSライブラリを使用する必要があります。 SOCKSソリューションで必要な手順は次のとおりです。
- TCP connection established to port 1080 (1.5 round trips)
- ポート1080へのTCP接続が確立されました（1.5往復）
- version identifier/method selection negotiation (1 round trip)
- バージョン識別子/メソッド選択ネゴシエーション（1往復）
- method-dependent negotiation. For example, the Username/Password Authentication [5] requires 1 round trip:
- メソッド依存の交渉。たとえば、ユーザー名/パスワード認証[5]では、1回の往復が必要です。
1. client sends a Username/Password request 2. FW (server) responds
1. クライアントがユーザー名/パスワード要求を送信2. FW（サーバー）が応答
The GSS-API negotiation requires at least 3 round trips:
GSS-APIネゴシエーションには、少なくとも3つの往復が必要です。
1. client context establishment (at least 1 round trip) 2. client initial token/server reply (1 round trip) 3. message protection subnegotiation (at least 1 round trip)
1. クライアントコンテキストの確立（少なくとも1往復）2.クライアントの初期トークン/サーバー応答（1往復）3.メッセージ保護サブネゴシエーション（少なくとも1往復）
- (finally) SOCKS request/reply (1 round trip)
- （最終的に）SOCKS要求/応答（1往復）
This is a minimum of 4 (6 with GSS-API) round-trips before the client is able to pass data through the FW using the following header:
これは、クライアントが次のヘッダーを使用してFWを介してデータを渡すことができるようになるまでに、最低4回（GSS-APIでは6回）のラウンドトリップです。
+----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+----+------+------+----------+----------+----------+
| 2 | 1 | 1 | Variable | 2 | Variable |
+----+------+------+----------+----------+----------+
Bear in mind that the above must be done each time the mobile registers a new care-of address. In addition to this inefficiency, this scheme requires that we use UDP to encapsulate IP datagrams. There is at least one commercial network that does this, but it is not the best solution.
上記は、モバイルが新しい気付アドレスを登録するたびに実行する必要があることに注意してください。この非効率性に加えて、このスキームでは、UDPを使用してIPデータグラムをカプセル化する必要があります。これを行う商用ネットワークが少なくとも1つありますが、これは最良のソリューションではありません。
Furthermore, SOCKS defines how to establish authenticated connections, but currently it does not provide a clear solution to the problem of encrypting the traffic.
さらに、SOCKSは認証された接続を確立する方法を定義しますが、現在はトラフィックの暗号化の問題に対する明確な解決策を提供していません。
This header contains the relay information needed by all parties involved to reach those not directly reachable.
このヘッダーには、直接到達できない当事者に到達するために関係するすべての当事者が必要とするリレー情報が含まれています。
Alternatively, traffic from the mobile node to the firewall could be encrypted and authenticated using a session-less IP security mechanism like SKIP. This obviates the need to set up a session just to exchange UDP traffic with the firewall.
または、モバイルノードからファイアウォールへのトラフィックは、SKIPなどのセッションレスIPセキュリティメカニズムを使用して暗号化および認証できます。これにより、UDPトラフィックをファイアウォールと交換するためだけにセッションをセットアップする必要がなくなります。
A solution based on SKIP is very attractive in this scenario, as no round trip times are incurred before the mobile node and the firewall achieve mutual trust: the firewall can start relaying packets for the mobile node as soon as it receives the first one. This, of course, implies that SKIP is being used with AH [7] so that authentication information is contained in each packet. Encryption by using ESP [6] is also assumed in this scenario, since the Internet at large is considered a hostile environment. An ESP transform that provides both authentication and encryption could be used, in which case the AH header need not be included.
このシナリオでは、モバイルノードとファイアウォールが相互信頼を確立する前にラウンドトリップ時間が発生しないため、SKIPに基づくソリューションは非常に魅力的です。モバイルノードが最初のパケットを受信するとすぐに、ファイアウォールはモバイルノードのパケットのリレーを開始できます。もちろん、これはSKIPがAH [7]と共に使用されているため、各パケットに認証情報が含まれていることを意味します。 ESP [6]を使用した暗号化も、このシナリオでは想定されています。これは、インターネット全体が悪意のある環境と見なされているためです。認証と暗号化の両方を提供するESPトランスフォームを使用できます。その場合、AHヘッダーを含める必要はありません。
The firewall and the mobile node may be previously configured with each other's authenticated Diffie-Hellman public components (also known as public values). Alternatively, they could exchange them in real-time using any of the mechanisms defined by the SKIP protocol (on-line certificate directory service or certificate discovery protocol). Home agents and the firewall also MUST have, be able to exchange or obtain each other's public components.
ファイアウォールとモバイルノードは、相互に認証されたDiffie-Hellmanパブリックコンポーネント（パブリック値とも呼ばれる）で事前に構成されている場合があります。あるいは、SKIPプロトコル（オンライン証明書ディレクトリサービスまたは証明書検出プロトコル）で定義されたメカニズムを使用して、リアルタイムで交換することもできます。ホームエージェントとファイアウォールも、互いのパブリックコンポーネントを交換または取得できる必要があります。
There are other proposals besides SKIP to achieve IP layer security. However, they are session-oriented key management solutions, and typically imply negotiations spanning several round-trip times before cryptographically secure communications are possible. In this respect they raise similar concerns to those outlined previously in the discussion on SOCKS-based solutions. Others have arrived at similar conclusions regarding the importance of session-less key management for Mobile IP applications [8].
IP層のセキュリティを実現するために、SKIP以外にも他の提案があります。ただし、これらはセッション指向の鍵管理ソリューションであり、通常、暗号化された安全な通信が可能になるまでに、数回のラウンドトリップ時間にわたる交渉を意味します。この点で、彼らは、SOCKSベースのソリューションに関する議論で前に概説したものと同様の懸念を提起します。モバイルIPアプリケーションのセッションレスキー管理の重要性に関して同様の結論に達した人もいます[8]。
Another advantage of SKIP is its support for nomadic applications. Typically, two hosts communicating via a secure IP layer channel use the IP source and destination addresses on incoming packets to arrive at the appropriate security association. The SKIP header can easily supersede this default mechanism by including the key ID the recipient must use to obtain the right certificate.
SKIPのもう1つの利点は、遊牧アプリケーションのサポートです。通常、安全なIP層チャネルを介して通信する2つのホストは、着信パケットのIP送信元アドレスと宛先アドレスを使用して、適切なセキュリティアソシエーションに到達します。 SKIPヘッダーは、受信者が正しい証明書を取得するために使用する必要のあるキーIDを含めることで、このデフォルトのメカニズムを簡単に置き換えることができます。
The key id is specified by two fields in the SKIP header:
キーIDは、SKIPヘッダーの2つのフィールドで指定されます。
1) a name space identifier (NSID) to indicate which of the possible name spaces is being used, and,
1）使用可能な名前空間のどれを使用しているかを示す名前空間識別子（NSID）、および
2) a master key identifier (MKID) that uniquely indicates (within the given name space) an id to use in fetching the proper certificate.
2）適切な証明書を取得する際に使用するIDを（特定の名前空間内で）一意に示すマスターキー識別子（MKID）。
As an example, by setting NSID to 1 and MKID to its home address, a mobile node tells a receiver "ignore the IP source and use my home address instead to look up my public component". Similarly, setting NSID to 8 enables using Unsigned Diffie-Hellman (UDH) certificates.
例として、NSIDを1に、MKIDをホームアドレスに設定することにより、モバイルノードは受信者に「IPソースを無視し、代わりにホームコンポーネントを使用してパブリックコンポーネントを検索する」ことを伝えます。同様に、NSIDを8に設定すると、Unsigned Diffie-Hellman（UDH）証明書を使用できるようになります。
In this case, the MKID is set to the MD5 hash of the DH public component [10].
この場合、MKIDはDHパブリックコンポーネントのMD5ハッシュに設定されます[10]。
In addition to the NSID/MKID feature, Mobile IP is best supported by an appropriate policy at the SKIP firewall in the form of a "nomadic" access control list entry. This is an entry which is filtered by key ID, instead of by IP source address, as is the usual case. It translates to "allow access from any IP source address for a given NSID/MKID combination". Furthermore, incoming packets MUST have an AH header, so that after properly authenticating them, the firewall establishes a "current address" or "dynamic binding" for the nomadic host. The NSID/MKID combination determines which key should be used with the nomadic host [9].
NSID / MKID機能に加えて、モバイルIPは、「ノマディック」アクセスコントロールリストエントリの形式で、SKIPファイアウォールの適切なポリシーによって最も適切にサポートされます。これは、通常のように、IP送信元アドレスではなく、キーIDでフィルタリングされるエントリです。これは、「特定のNSID / MKIDの組み合わせに対して、任意のIPソースアドレスからのアクセスを許可する」と解釈されます。さらに、着信パケットにはAHヘッダーが必要です。そのため、適切に認証された後、ファイアウォールは遊牧ホストの「現在のアドレス」または「動的バインディング」を確立します。 NSID / MKIDの組み合わせにより、遊牧ホストで使用するキーが決まります[9]。
Notice that this supports Mobile IP, because the mobile node always initiates contact. Hence, the SKIP firewall has a chance to learn the mobile node's "current address" from an incoming packet before it attempts to encrypt an outgoing packet.
モバイルノードは常に接続を開始するため、これはモバイルIPをサポートすることに注意してください。したがって、SKIPファイアウォールは、発信パケットを暗号化する前に、着信パケットからモバイルノードの「現在のアドレス」を学習する可能性があります。
However, this precludes the use of simultaneous bindings by a mobile node. At the firewall, the last Registration Request sent by the mobile node replaces the association between its permanent address and any prior care-of address. In order to support simultaneous bindings the firewall must be able to interpret Mobile IP registration messages.
ただし、これにより、モバイルノードによる同時バインディングの使用が排除されます。ファイアウォールでは、モバイルノードによって送信された最後のRegistration Requestが、永続アドレスと以前の気付アドレスの間の関連付けを置き換えます。同時バインディングをサポートするには、ファイアウォールがモバイルIP登録メッセージを解釈できる必要があります。
Section 7.2.2 discusses another advantage of making the firewall understand Mobile IP packet formats.
セクション7.2.2では、ファイアウォールにモバイルIPパケット形式を認識させることのもう1つの利点について説明します。
In what follows we assume a SKIP-based solution.
以下では、SKIPベースのソリューションを想定しています。
Depending on which address it uses as its tunnel endpoint, the Mobile IP protocol specifies two ways in which a mobile node can register a mobility binding with its home agent.
モバイルIPプロトコルは、トンネルエンドポイントとして使用するアドレスに応じて、モバイルノードがホームエージェントにモビリティバインディングを登録できる2つの方法を指定します。
a) an address advertised for that purpose by the foreign agent
a) 外国のエージェントがその目的のためにアドバタイズしたアドレス
b) an address belonging to one of the mobile node's interfaces (i.e. operation with a co-located address).
b) モバイルノードのインターフェースの1つに属するアドレス（つまり、同じ場所にあるアドレスでの操作）。
From the firewall's point of view, the main difference between these two cases hinges on which node prepares the outermost encrypting encapsulation. The firewall MUST be able to obtain the Diffie-Hellman public component of the node that creates the outermost SKIP header in an incoming packet. This is only possible to guarantee in case "b", because the mobile node and the firewall both belong to the same administrative domain. The problem is even more apparent when the mobile node attempts a Registration Request. Here, the foreign agent is not just a relayer, it actually examines the packet sent by the mobile node, and modifies its agent services accordingly. In short, assuming the current specification of Mobile IP and the current lack of trust in the internet at large, only case "b" is possible. Case "a" would require an extension (e.g. a "relay" Registration Request), and modifying code at the home agent, the firewall and the foreign agent.
ファイアウォールの観点から見ると、これら2つのケースの主な違いは、どのノードが最も外側の暗号化カプセル化を準備するかにかかっています。ファイアウォールは、着信パケットで最も外側のSKIPヘッダーを作成するノードのDiffie-Hellmanパブリックコンポーネントを取得できる必要があります。これは、モバイルノードとファイアウォールの両方が同じ管理ドメインに属しているため、ケース "b"の場合にのみ保証できます。この問題は、モバイルノードがRegistration Requestを試行したときにさらに顕著になります。ここで、外部エージェントは単なる中継器ではなく、モバイルノードによって送信されたパケットを実際に調べ、それに応じてエージェントサービスを変更します。要するに、モバイルIPの現在の仕様とインターネット全体に対する現在の信頼の欠如を想定すると、「b」の場合のみが可能です。ケース「a」には、拡張機能（「リレー」登録要求など）と、ホームエージェント、ファイアウォール、および外部エージェントでのコードの変更が必要です。
Assuming that the firewall offers a secure relay service (i.e. decapsulation and forwarding of packets), the mobile node can reach addresses internal to the private network by encapsulating the packets in a SKIP header and directing them to the firewall.
ファイアウォールが安全なリレーサービス（つまり、カプセル化解除とパケットの転送）を提供すると仮定すると、モバイルノードは、パケットをSKIPヘッダーにカプセル化してファイアウォールに転送することにより、プライベートネットワーク内部のアドレスに到達できます。
Therefore, It is simplest to assume that the mobile node operates with a co-located address.
したがって、モバイルノードが同じ場所に配置されたアドレスで動作すると想定するのが最も簡単です。
The mobile node participates in two different types of traffic: Mobile IP registration protocol and data. For the sake of simplicity, the following discussion evaluates different secure channel configurations by examining the initial Registration Request sent by the mobile node to its home agent.
モバイルノードは、モバイルIP登録プロトコルとデータの2種類のトラフィックに参加します。簡単にするために、次の説明では、モバイルノードからホームエージェントに送信された初期登録要求を調べることにより、さまざまなセキュアチャネル構成を評価します。
Assuming the mobile node operates with a co-located address, it can communicate directly with the firewall. The latter is able to reach the home agent in the private network. Also, the firewall MUST be able to authenticate the mobile node.
モバイルノードが同じ場所に配置されたアドレスで動作すると仮定すると、モバイルノードはファイアウォールと直接通信できます。後者は、プライベートネットワークのホームエージェントに到達できます。また、ファイアウォールはモバイルノードを認証できる必要があります。
The following channel configurations assume the mobile node operates with a co-located address. The region between the HA (home agent) and the FW (firewall) is a private network. The region between the FW and the MN (mobile node) is the outside or public network.
次のチャネル構成は、モバイルノードが同じ場所にあるアドレスで動作することを前提としています。 HA（ホームエージェント）とFW（ファイアウォール）の間の領域はプライベートネットワークです。 FWとMN（モバイルノード）の間の領域は、外部ネットワークまたはパブリックネットワークです。
HA FW MN
<=====================> SKIP (AH + ESP)
<-----------------------------------> Registration Request path
The traffic is only encrypted between the mobile node out on the general Internet, and the firewall's external interface. This is minimum required. It is the most desirable configuration as the more expensive encrypted channel is only used where it is necessary: on the public network.
トラフィックは、一般的なインターネット上のモバイルノードとファイアウォールの外部インターフェイスの間でのみ暗号化されます。これは最低限必要です。より高価な暗号化チャネルは、必要な場合（パブリックネットワーク上）でのみ使用されるため、これは最も望ましい構成です。
Another possible configuration extends the encrypted tunnel through the firewall:
別の可能な構成は、暗号化されたトンネルをファイアウォールを介して拡張します。
HA FW MN
<===================================> SKIP (AH + ESP)
<-----------------------------------> Registration Request path
This limits the firewall to perform a simple packet relay or gatewaying function. Even though this could be accomplished by using the proper destination NSID in the packet, in practice it is probably unrealizable. The reason is that this alternative is probably not very popular with computer security personnel, because authentication is not carried out by the firewall but by the home agent, and the latter's security is potentially much weaker than the former's.
これにより、ファイアウォールは単純なパケットリレーまたはゲートウェイ機能を実行するように制限されます。これは、パケットで適切な宛先NSIDを使用することで実現できますが、実際には実現不可能です。その理由は、認証はファイアウォールではなくホームエージェントによって実行され、後者のセキュリティは前者のセキュリティよりも潜在的に弱いため、この代替手段はおそらくコンピュータセキュリティ担当者にはあまり人気がないためです。
A third alternative is to allow the firewall to be party to the security association between the home agent and the mobile node. After verifying authentication (AH header), the firewall forwards the encrypted packet (ESP hdr) to the home agent.
3つ目の方法は、ファイアウォールをホームエージェントとモバイルノード間のセキュリティアソシエーションのパーティにすることです。ファイアウォールは認証（AHヘッダー）を確認した後、暗号化されたパケット（ESP hdr）をホームエージェントに転送します。
HA FW MN
<+++++++++++++++++++++> SKIP authentication
<===================================> SKIP encryption
<-----------------------------------> Registration Request path
Here, SKIP is used to provide intermediate authentication with end-to-end security. Although possible, this option implies that the participating entities disclose their pairwise long-term Diffie-Hellman shared secret to the intermediate node.
ここでは、エンドツーエンドのセキュリティを備えた中間認証を提供するためにSKIPが使用されています。可能ではありますが、このオプションは、参加エンティティがペアワイズの長期Diffie-Hellman共有秘密を中間ノードに開示することを意味します。
Whereas Option 2 above is probably not agreeable to security and system administration personnel, option 3 is unsavory to the end user.
上記のオプション2はセキュリティおよびシステム管理担当者にはおそらく不向きですが、オプション3はエンドユーザーに不快です。
HA FW MN
<============><=====================> SKIP (AH + ESP)
<-----------------------------------> Registration Request path
Traffic is encrypted on the public as well as on the private network. On the public network, encryption is dictated by a security association between the mobile node and the firewall. On the private network, it is dictated by a security association between the home agent and the firewall.
トラフィックは、パブリックネットワークとプライベートネットワークで暗号化されます。パブリックネットワークでは、モバイルノードとファイアウォール間のセキュリティアソシエーションによって暗号化が指示されます。プライベートネットワークでは、ホームエージェントとファイアウォールの間のセキュリティアソシエーションによって指示されます。
A potential problem in both options 2 and 3 is that their end-to-end channel components assume that the mobile node and the home agent can exchange IP traffic directly with each other. This is generally not the case, as the Internet routing fabric may not have routes to addresses that belong to private networks, and the private routing fabric may ignore how to route to public addresses -- or doing so may be administratively restricted. Therefore, it is necessary for packets to be addressed directly to the firewall, and indirectly -- via some tunneling or relaying capability -- to the real destination on the other side of the firewall.
オプション2と3の両方の潜在的な問題は、それらのエンドツーエンドチャネルコンポーネントが、モバイルノードとホームエージェントが互いにIPトラフィックを直接交換できると想定していることです。インターネットルーティングファブリックにはプライベートネットワークに属するアドレスへのルートがない可能性があり、プライベートルーティングファブリックはパブリックアドレスへのルーティング方法を無視する可能性があるため、これは通常は当てはまりません。したがって、パケットはファイアウォールに直接宛てられ、ファイアウォールの反対側にある実際の宛先に、何らかのトンネルまたはリレー機能を介して間接的に宛てられる必要があります。
Options 1 and 4 are essentially equivalent. The latter may be considered overkill, because it uses encryption even within the private network, and this is generally not necessary. What is necessary even within the private network is for the home agent to add an encapsulation (not necessarily encrypted) so as to direct datagrams to the mobile node via the firewall. The type of encapsulation used determines the difference between options 1 and 4. Whereas option 4 uses SKIP, option 1 uses a cleartext encapsulation mechanism. This is obtainable by, for example, using IP in IP encapsulation [2].
オプション1と4は本質的に同等です。後者はプライベートネットワーク内でも暗号化を使用するため、やり過ぎと見なされる可能性があり、通常、これは必要ありません。プライベートネットワーク内でも、ファイアウォールを介してモバイルノードにデータグラムを送信できるように、ホームエージェントがカプセル化（必ずしも暗号化されている必要はありません）を追加する必要があります。使用されるカプセル化のタイプによって、オプション1と4の違いが決まります。オプション4はSKIPを使用しますが、オプション1はクリアテキストのカプセル化メカニズムを使用します。これは、たとえばIPカプセル化でIPを使用することで取得できます[2]。
Options 1 and 4 are mostly interchangeable. The difference is, of course, that the former does not protect the data from eavesdroppers within the private network itself. This may be unacceptable in certain cases. Traffic from some departments in a company (for example payroll or legal) may need to be encrypted as it traverses other sections of the company.
オプション1と4はほとんど互換性があります。もちろん、前者はプライベートネットワーク自体の中の盗聴者からデータを保護しません。これは、特定のケースでは受け入れられない場合があります。会社の一部の部門（給与や法務など）からのトラフィックは、会社の他のセクションを通過するときに暗号化する必要がある場合があります。
In the interest of being conservative, in what follows we assume option 4 (i.e. traffic is encrypted on the general Internet, as well as within the private network.
保守的にするために、以下ではオプション4を想定しています（つまり、トラフィックは一般的なインターネット上とプライベートネットワーク内で暗号化されています。
Since the firewall is party to the security associations governing encryption on both the public and private networks, it is always able to inspect the traffic being exchanged by the home agent and the mobile node. If this is of any concern, the home agent and mobile node could set up a bi-directional tunnel and encrypt it.
ファイアウォールは、パブリックネットワークとプライベートネットワークの両方で暗号化を管理するセキュリティアソシエーションのパーティであるため、ホームエージェントとモバイルノードによって交換されるトラフィックを常に検査できます。これが問題になる場合は、ホームエージェントとモバイルノードが双方向トンネルを設定して暗号化できます。
When roaming within a private network, a mobile node sends Registration Requests directly to its home agent. On the public Internet, it MUST encapsulate the original Registration Request in a SKIP packet destined to the firewall. The mobile node MUST distinguish between "inside" and "outside" addresses. This could be accomplished by a set of rules defining the address ranges. Nevertheless, actual installations may present serious difficulties in defining exactly what is a private address and what is not.
プライベートネットワーク内をローミングする場合、モバイルノードは登録要求をホームエージェントに直接送信します。公衆インターネット上では、元の登録要求をファイアウォール宛てのSKIPパケットにカプセル化する必要があります。モバイルノードは、「内部」アドレスと「外部」アドレスを区別する必要があります。これは、アドレス範囲を定義する一連のルールによって実現できます。それでも、実際のインストールでは、プライベートアドレスと非プライベートアドレスを正確に定義するのが非常に難しい場合があります。
Direct human input is a very effective method: it may be obvious to the user that the current point of attachment is outside its private network, and it should be possible to communicate this knowledge to the mobile node software.
人間による直接入力は非常に効果的な方法です。現在の接続ポイントがプライベートネットワークの外にあることはユーザーには明らかであり、この知識をモバイルノードソフトウェアに伝えることができるはずです。
The home agent must also distinguish between "inside" and "outside" addresses, but lacks the potential benefit of direct user input. Accordingly, it should be possible for the mobile node to communicate that knowledge to the home agent. To accomplish this we define a Traversal Extension to the Registration Requests and Replies. This extension is also useful when traversing multiple firewalls.
ホームエージェントは、「内部」アドレスと「外部」アドレスを区別する必要もありますが、ユーザーが直接入力することによる潜在的な利点はありません。したがって、モバイルノードがその知識をホームエージェントに伝達することが可能であるべきである。これを実現するために、登録要求と応答へのトラバーサル拡張を定義します。この拡張機能は、複数のファイアウォールを通過するときにも役立ちます。
In spite of the above mechanisms, errors in judgement are to be expected. Accordingly, the firewall SHOULD be configured such that it will still perform its relaying duties even if they are unnecessarily required by a mobile node with an inside care-of address.
上記のメカニズムにもかかわらず、判断の誤りが予想されます。したがって、ファイアウォールは、内部気付アドレスを持つモバイルノードによって不必要に要求された場合でも、リレーの役割を実行するように構成する必要があります（SHOULD）。
Upon arriving at a foreign net and acquiring a care-of address, the mobile node must first -- before any data transfer is possible -- initiate a registration procedure. This consists of an authenticated exchange by which the mobile node informs its home agent of its current whereabouts (i.e. its current care-of address), and receives an acknowledgement. This first step of the protocol is very convenient, because the SKIP firewall can use it to dynamically configure its packet filter.
外部ネットに到着して気付アドレスを取得すると、モバイルノードは、データ転送が可能になる前に、まず登録手順を開始する必要があります。これは、モバイルノードがホームエージェントに現在の所在（つまり、現在の気付アドレス）を通知し、確認応答を受け取る認証された交換で構成されます。このプロトコルの最初のステップは、SKIPファイアウォールを使用してパケットフィルターを動的に構成できるため、非常に便利です。
The remainder of this section shows the packet formats used. Section 7.1 discusses how a mobile node sends a Registration Request to its home agent via the SKIP firewall. Section 7.2 discusses how the home agent send the corresponding Registration Reply to the mobile node. Section 7.3 defines the Traversal Extension for use with Registration Requests and Replies.
このセクションの残りの部分では、使用されるパケット形式を示します。セクション7.1では、モバイルノードがSKIPファイアウォール経由でホームエージェントにRegistration Requestを送信する方法について説明します。セクション7.2では、ホームエージェントが対応するRegistration Replyをモバイルノードに送信する方法について説明します。セクション7.3は、登録要求および応答で使用するための走査拡張を定義します。
The mobile node arrives at a foreign net, and using mechanisms defined by Mobile IP, discovers it has moved away from home. It acquires a local address at the foreign site, and composes a Registration Request meant for its home agent. The mobile node must decide whether this packet needs to be processed by SKIP or not.
モバイルノードは外部ネットに到達し、モバイルIPによって定義されたメカニズムを使用して、ホームから移動したことを検出します。外部サイトのローカルアドレスを取得し、ホームエージェント向けの登録要求を作成します。モバイルノードは、このパケットをSKIPで処理する必要があるかどうかを決定する必要があります。
This is not a simple rule triggered by a given destination address. It must be applied whenever the following conditions are met:
これは、特定の宛先アドレスによってトリガーされる単純なルールではありません。次の条件が満たされる場合は常に適用する必要があります。
a) the mobile node is using a care-of address that does not belong to the private network (i.e. the mobile node is currently "outside" its private network), and
a) モバイルノードがプライベートネットワークに属していない気付アドレスを使用している（つまり、モバイルノードは現在、プライベートネットワークの「外部」にある）。
b) either of:
b) のどちらか：
b1) the source address of the packet is the mobile node's home address (e.g. this packet's endpoints are dictated by a connection initiated while at home), or
b1）パケットの送信元アドレスがモバイルノードのホームアドレスである（たとえば、このパケットのエンドポイントは、在宅中に開始された接続によって指示されます）、または
b2) the source address of the packet is the care-of address and the destination address belongs to the private network
b2）パケットの送信元アドレスが気付アドレスであり、宛先アドレスがプライベートネットワークに属している
Since the above conditions are mobility related, it is best for the Mobile IP function in the node to evaluate them, and then request the appropriate security services from SKIP.
上記の条件はモビリティに関連しているため、ノードのモバイルIP機能がそれらを評価し、SKIPに適切なセキュリティサービスを要求することが最善です。
The SKIP module must use the firewall destination address and the firewall's certificate in order to address and encrypt the packet. It encrypts it using SKIP combined with the ESP [6] protocol and possibly the AH [7] protocol.
SKIPモジュールは、パケットのアドレス指定と暗号化を行うために、ファイアウォールの宛先アドレスとファイアウォールの証明書を使用する必要があります。 ESP [6]プロトコルとAH [7]プロトコルを組み合わせたSKIPを使用して暗号化します。
The SKIP header's source NSID equals 1, indicating that the Master Key-ID is the mobile node's home address. Notice that the IP packet's source address corresponds to the care-of address -- an address whose corresponding public component is unknown to the firewall.
SKIPヘッダーのソースNSIDは1で、マスターキーIDがモバイルノードのホームアドレスであることを示します。 IPパケットの送信元アドレスが気付アドレスに対応していることに注意してください-対応するパブリックコンポーネントがファイアウォールにとって未知のアドレスです。
It is also possible to use Unsigned Diffie-Hellman public components [10]. Doing so greatly reduces SKIP's infrastructure requirements, because there is no need for a Certificate Authority. Of course, for this to be possible the principals' names MUST be securely communicated.
Unsigned Diffie-Hellmanパブリックコンポーネントを使用することも可能です[10]。これにより、認証局が不要になるため、SKIPのインフラストラクチャ要件が大幅に削減されます。もちろん、これが可能であるためには、プリンシパルの名前を安全に通信する必要があります。
REGISTRATION REQUEST: BETWEEN THE MOBILE NODE AND THE FIREWALL
+---------------+----------+----+-----+--------------+--------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request |
+---------------+----------+----+-----+--------------+--------------+
IP Hdr (SKIP): Source mobile node's care-of address Destination firewall's public (outside) address
IP Hdr（SKIP）：ソースモバイルノードの気付アドレス宛先ファイアウォールのパブリック（外部）アドレス
SKIP Hdr: Source NSID = 1 Master Key-ID = IPv4 address of the mobile node Destination NSID = 0 Master Key-ID = none Inner IP Hdr: Source mobile node's care-of address Destination home agent's address
SKIP Hdr：ソースNSID = 1マスターキーID =モバイルノードのIPv4アドレス宛先NSID = 0マスターキーID =なし内部IP Hdr：ソースモバイルノードの気付アドレス宛先ホームエージェントのアドレス
The SKIP Firewall's dynamic packet filtering uses this information to establish a dynamic binding between the care-of address and the mobile node's permanent home address.
SKIPファイアウォールの動的パケットフィルタリングは、この情報を使用して、気付アドレスとモバイルノードの永続的なホームアドレス間の動的バインディングを確立します。
The destination NSID field in the above packet is zero, prompting the firewall to process the SKIP header and recover the internal packet. It then delivers the original packet to another outbound interface, because it is addressed to the home agent (an address within the private network). Assuming secure channel configuration number 4, the firewall encrypts the packet using SKIP before forwarding to the home agent.
上記のパケットの宛先NSIDフィールドはゼロであり、ファイアウォールがSKIPヘッダーを処理して内部パケットを回復するように促します。次に、元のパケットはホームエージェント（プライベートネットワーク内のアドレス）にアドレス指定されているため、別の送信インターフェイスに配信します。セキュアチャネル構成番号4を想定すると、ファイアウォールは、ホームエージェントに転送する前に、SKIPを使用してパケットを暗号化します。
REGISTRATION REQUEST: BETWEEN THE FIREWALL AND THE HOME AGENT
+---------------+----------+----+-----+--------------+--------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request |
+---------------+----------+----+-----+--------------+--------------+
IP Hdr (SKIP): Source firewall's private (inside) address Destination home agent's address
IP Hdr（SKIP）：送信元ファイアウォールのプライベート（内部）アドレス宛先ホームエージェントのアドレス
SKIP Hdr: Source NSID = 0 Master Key-ID = none Destination NSID = 0 Master Key-ID = none Inner IP Hdr: Source mobile node's care-of address Destination home agent's address
SKIP Hdr：ソースNSID = 0マスターキーID =なし宛先NSID = 0マスターキーID =なし内部IP Hdr：ソースモバイルノードの気付アドレス宛先ホームエージェントのアドレス
The home agent processes the Registration Request, and composes a Registration Reply. Before responding, it examines the care-of address reported by the mobile node, and determines whether or not it corresponds to an outside address. If so, the home agent needs to send all traffic back through the firewall. The home agent can accomplish this by encapsulating the original Registration Reply in a SKIP packet destined to the firewall (i.e. we assume secure channel configuration number 4).
ホームエージェントは登録要求を処理し、登録応答を作成します。応答する前に、モバイルノードから報告された気付アドレスを調べ、外部アドレスに対応しているかどうかを判断します。その場合、ホームエージェントはすべてのトラフィックをファイアウォール経由で送り返す必要があります。ホームエージェントは、元の登録応答をファイアウォール宛てのSKIPパケットにカプセル化することでこれを実現できます（つまり、安全なチャネル構成番号4を想定しています）。
The packet from the home agent to the mobile node via the SKIP Firewall has the same format as shown above. The relevant fields are:
ホームエージェントからSKIPファイアウォールを経由してモバイルノードに送信されるパケットのフォーマットは、上記と同じです。関連するフィールドは次のとおりです。
REGISTRATION REPLY: BETWEEN THE HOME AGENT AND THE FIREWALL
+---------------+----------+----+-----+--------------+------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply |
+---------------+----------+----+-----+--------------+------------+
IP Hdr (SKIP): Source home agent's address Destination firewall's private (inside) address
IP Hdr（SKIP）：ソースホームエージェントのアドレス宛先ファイアウォールのプライベート（内部）アドレス
SKIP Hdr: Source NSID = 0 Master Key-ID = none Destination NSID = 0 Master Key-ID = none Inner IP Hdr: Source home agent's address Destination mobile node's care-of address
SKIP Hdr：ソースNSID = 0マスターキーID =なし宛先NSID = 0マスターキーID =なし内部IP Hdr：ソースホームエージェントのアドレス宛先モバイルノードの気付アドレス
The SKIP Firewall recovers the original Registration Reply packet and looks at the destination address: the mobile node's care-of address.
SKIPファイアウォールは元のRegistration Replyパケットを復元し、宛先アドレス、つまりモバイルノードの気付アドレスを調べます。
The SKIP Firewall's dynamic packet filtering used the initial Registration Request (Secton 7.1) to establish a dynamic mapping between the care-of address and the mobile node's Master Key-ID. Hence, before forwarding the Registration Reply, it encrypts it using the mobile node's public component.
SKIPファイアウォールの動的パケットフィルタリングは、初期登録要求（Secton 7.1）を使用して、気付アドレスとモバイルノードのマスターキーIDの間の動的マッピングを確立しました。したがって、Registration Replyを転送する前に、モバイルノードのパブリックコンポーネントを使用してそれを暗号化します。
This dynamic binding capability and the use of tunneling mode ESP obviate the need to extend the Mobile IP protocol with a "relay Registration Request". However, it requires that the Registration Reply exit the private network through the same firewall that forwarded the corresponding Registration Request.
この動的バインディング機能とトンネリングモードESPの使用により、「リレー登録要求」でモバイルIPプロトコルを拡張する必要がなくなります。ただし、対応する登録要求を転送したのと同じファイアウォールを介して、登録応答がプライベートネットワークを出る必要があります。
Instead of obtaining the mobile node's permanent address from the dynamic binding, a Mobile IP aware firewall could also obtain it from the Registration Reply itself. This renders the firewall stateless, and lets Registration Requests and Replies traverse the periphery of the private network through different firewalls.
動的バインディングからモバイルノードの永続アドレスを取得する代わりに、モバイルIP対応ファイアウォールがRegistration Reply自体から取得することもできます。これにより、ファイアウォールがステートレスになり、Registration Requests and Repliesが異なるファイアウォールを介してプライベートネットワークの周辺を通過できるようになります。
REGISTRATION REPLY: BETWEEN THE FIREWALL AND THE MOBILE NODE
+---------------+----------+----+-----+--------------+------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply |
+---------------+----------+----+-----+--------------+------------+
IP Hdr (SKIP): Source firewall's public (outside) address Destination mobile node's care-of address
IP Hdr（SKIP）：送信元ファイアウォールのパブリック（外部）アドレス宛先モバイルノードの気付アドレス
SKIP Hdr: Source NSID = 0 Master Key-ID = none Destination NSID = 1 Master Key-ID = IPv4 addr of the mobile node Inner IP Hdr: Source home agent's address Destination mobile node's care-of address
SKIP Hdr：ソースNSID = 0マスターキーID =なし宛先NSID = 1マスターキーID =モバイルノードのIPv4アドレス内部IP Hdr：ソースホームエージェントのアドレス宛先モバイルノードの気付アドレス
The Traversal Extension MAY be included by mobile nodes in Registration Requests, and by home agents in Registration Replies. As per Section 3.6.1.3 of [1], the Traversal Extension must appear before the Mobile-Home Authentication Extension. A Traversal Extension is an explicit notification that there are one or more traversal points (firewalls, fireridges, etc) between the mobile node and its home agent. Negotiating access past these systems may imply a new authentication header, and possibly a new encapsulating header (perhaps as part of tunnel-mode ESP) whose IP destination address is the traversal address.
トラバーサル拡張機能は、登録リクエストのモバイルノードと登録応答のホームエージェントに含めることができます。 [1]のセクション3.6.1.3に従って、トラバーサル拡張機能はモバイルホーム認証拡張機能の前に表示される必要があります。トラバーサル拡張は、モバイルノードとそのホームエージェントの間に1つ以上のトラバーサルポイント（ファイアウォール、ファイアリッジなど）があることを示す明示的な通知です。これらのシステムを通過するアクセスのネゴシエーションは、新しい認証ヘッダー、およびおそらくIP宛先アドレスがトラバーサルアドレスである新しいカプセル化ヘッダー（おそらくトンネルモードESPの一部として）を暗示する可能性があります。
Negotiating access past traversal points does not necessarily require cryptographic techniques. For example, systems at the boundary between separate IP address spaces must be explicitly targetted (perhaps using unencrypted IP in IP encapsulation).
通過ポイントを越えたアクセスのネゴシエーションには、必ずしも暗号化技術は必要ありません。たとえば、個別のIPアドレススペース間の境界にあるシステムは、明示的にターゲットにする必要があります（おそらくIPカプセル化で暗号化されていないIPを使用します）。
A mobile node SHOULD include one Traversal Extension per traversal point in its Registration Requests. If present, their order MUST exactly match the order in which packets encounter them as they flow from the mobile node towards the home agent.
モバイルノードは、登録要求のトラバーサルポイントごとに1つのトラバーサル拡張を含める必要があります（SHOULD）。存在する場合、それらの順序は、モバイルノードからホームエージェントに向かって流れるときにパケットがパケットに遭遇する順序と正確に一致する必要があります。
Notice that there may be additional firewalls along the way, but the list of traversal points SHOULD only include those systems with which an explicit negotiation is required.
途中で追加のファイアウォールが存在する可能性がありますが、トラバーサルポイントのリストには、明示的なネゴシエーションが必要なシステムのみを含める必要があります。
Similarly, the home agent SHOULD include one Traversal Extension per traversal point in its Registration Replies. If present, their order MUST exactly match the order in which packets encounter them as they flow from the home agent to the mobile node.
同様に、ホームエージェントは、登録応答のトラバーサルポイントごとに1つのトラバーサル拡張を含める必要があります（SHOULD）。存在する場合、それらの順序は、パケットがホームエージェントからモバイルノードに流れるときにパケットが遭遇する順序と正確に一致する必要があります。
A Traversal Extension does not include any indication about how access is negotiated. Presumably, this information is obtained through separate means. This document does not attempt to solve the firewall discovery problem, that is, it does not specify how to discover the list of traversal points.
トラバーサル拡張には、アクセスのネゴシエート方法に関する指示は含まれていません。おそらく、この情報は別の方法で取得されます。このドキュメントでは、ファイアウォール検出の問題の解決は試みられていません。つまり、トラバーサルポイントのリストを検出する方法は指定されていません。
As per section 1.9 of [1], the fact that the type value falls within the range 128 to 255 implies that if a home agent or a mobile node encounter a Traversal Extension in a Registration Request or Reply, they may silently ignore it. This is consistent with the fact that the Traversal Extension is essentially a hint.
[1]のセクション1.9に従って、タイプ値が128〜255の範囲にあるという事実は、ホームエージェントまたはモバイルノードが登録要求または応答でトラバーサル拡張に遭遇した場合、黙ってそれを無視する可能性があることを意味します。これは、トラバーサル拡張機能が本質的にヒントであるという事実と一致しています。
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN to HA Traversal Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA to MN Traversal Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
129
１２９
Length
長さ
10
１０
Reserved
予約済み
0
０
MN to HA Traversal Address
MNからHAへのトラバーサルアドレス
The IP address of the an intermediate system or firewall encountered by datagrams sent by the mobile node towards the home agent. Typically, this is the external address of a firewall or firewall complex.
モバイルノードからホームエージェントに向けて送信されたデータグラムが遭遇する中間システムまたはファイアウォールのIPアドレス。通常、これはファイアウォールまたはファイアウォールコンプレックスの外部アドレスです。
This field MUST be initialized in Registration Requests. In Registration Replies, it is typically all 0's, otherwise, the mobile node SHOULD interpret it as a hint.
このフィールドは、登録要求で初期化する必要があります。 Registration Repliesでは、通常はすべて0です。それ以外の場合、モバイルノードはそれをヒントとして解釈する必要があります（SHOULD）。
HA to MN Traversal Address
HAからMNへのトラバーサルアドレス
The IP address of an intermediate system or firewall encountered by datagrams sent by the home agent towards the mobile node. Typically, this is the internal address of a firewall or firewall complex.
ホームエージェントからモバイルノードに送信されるデータグラムが遭遇する中間システムまたはファイアウォールのIPアドレス。通常、これはファイアウォールまたはファイアウォールコンプレックスの内部アドレスです。
This field MUST be initialized in Registration Replies. In Registration Requests, it is typically all 0's, otherwise, the home agent SHOULD interpret it as a hint.
このフィールドは、登録応答で初期化する必要があります。登録要求では、通常はすべて0です。それ以外の場合、ホームエージェントはそれをヒントとして解釈する必要があります（SHOULD）。
Data transfer proceeds along lines similar to the Registration Request outlined above. Section 8.1 discusses data traffic sent by a mobile node to a correspondent node. Section 8.2 shows packet formats for the reverse traffic being tunneled by the home agent to the mobile node.
データ転送は、上記で概説した登録要求と同様の方法で進行します。セクション8.1では、モバイルノードからコレスポンデントノードに送信されるデータトラフィックについて説明します。セクション8.2は、ホームエージェントによってモバイルノードにトンネリングされるリバーストラフィックのパケットフォーマットを示しています。
The mobile node composes a packet destined to a correspondent node located within the private network.
モバイルノードは、プライベートネットワーク内に配置されたコレスポンデントノード宛てのパケットを作成します。
The Mobile IP function in the mobile node examines the Inner IP header, and determines that it satisfies conditions "a" and "b1" from Section 7.1. The mobile node requests the proper encryption and encapsulation services from SKIP.
モバイルノードのモバイルIP機能は、内部IPヘッダーを調べ、セクション7.1の条件「a」と「b1」を満たしていると判断します。モバイルノードは、SKIPに適切な暗号化およびカプセル化サービスを要求します。
Thus, the mobile node with a co-located address sends encrypted traffic to the firewall, using the following format:
したがって、同じ場所に配置されたアドレスを持つモバイルノードは、次の形式を使用して、暗号化されたトラフィックをファイアウォールに送信します。
DATA PACKET: FROM THE MOBILE NODE VIA THE FIREWALL
+---------------+----------+----+-----+--------------+------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | ULP |
+---------------+----------+----+-----+--------------+------+
IP Hdr (SKIP): Source mobile node's care-of address Destination public (outside) address on the firewall
IP Hdr（SKIP）：ファイアウォール上の送信元モバイルノードの気付アドレス宛先パブリック（外部）アドレス
SKIP Hdr: Source NSID = 1 Master Key-ID = IPv4 address of the mobile node Destination NSID = 0 Master Key-ID = none Inner IP Hdr: Source mobile node's home address Destination correspondent node's address
SKIP Hdr：ソースNSID = 1マスターキーID =モバイルノードのIPv4アドレス宛先NSID = 0マスターキーID =なし内部IP Hdr：ソースモバイルノードのホームアドレス宛先コレスポンデントノードのアドレス
The SKIP Firewall intercepts this packet, decrypts the Inner IP Hdr and upper-layer payload (ULP) and checks the destination address. Since the packet is destined to a correspondent node in the private network, the "Inner" IP datagram is delivered internally. Once the SKIP firewall injects this packet into the private network, it is routed independently of its source address.
SKIPファイアウォールはこのパケットを傍受し、内部IP Hdrと上位層ペイロード（ULP）を復号化して、宛先アドレスを確認します。パケットの宛先はプライベートネットワークのコレスポンデントノードであるため、「内部」IPデータグラムは内部的に配信されます。 SKIPファイアウォールがこのパケットをプライベートネットワークに挿入すると、送信元アドレスとは無関係にルーティングされます。
As this last assumption is not always true, the mobile node may construct a bi-directional tunnel with its home agent. Doing so, guarantees that the "Inner IP Hdr" is:
この最後の仮定は常に当てはまるとは限らないため、モバイルノードはそのホームエージェントとの双方向トンネルを構築できます。そうすることで、「内部IP Hdr」が次のようになることが保証されます。
Inner IP Hdr: Source care-of address Destination home agent address
内部IP Hdr：送信元気付アドレス宛先ホームエージェントアドレス
When at home, communication between the the mobile node and certain external correspondent nodes may need to go through application-specific firewalls or proxies, different from the SKIP firewall. While on the public network, the mobile node's communication with these hosts, MUST use a bi-directional tunnel.
自宅にいるとき、モバイルノードと特定の外部コレスポンデントノード間の通信は、SKIPファイアウォールとは異なり、アプリケーション固有のファイアウォールまたはプロキシを通過する必要がある場合があります。パブリックネットワーク上では、モバイルノードとこれらのホストとの通信は、双方向トンネルを使用する必要があります。
The home agent intercepts a packet from a correspondent node to the mobile node. It encapsulates it such that the Mobile IP encapsulating IP header's source and destination addresses are the home agent and care-of addresses, respectively. This would suffice for delivery within the private network. Since the current care-of address of the mobile node is not within the private network, this packet MUST be sent via the firewall. The home agent can accomplish this by encapsulating the datagram in a SKIP packet destined to the firewall (i.e. we assume secure channel configuration number 4).
ホームエージェントは、コレスポンデントノードからモバイルノードへのパケットを傍受します。モバイルIPカプセル化IPヘッダーの送信元アドレスと宛先アドレスがそれぞれホームエージェントと気付アドレスになるようにカプセル化します。これは、プライベートネットワーク内での配信には十分です。モバイルノードの現在の気付アドレスはプライベートネットワーク内にないため、このパケットはファイアウォール経由で送信する必要があります。ホームエージェントは、ファイアウォールを宛先とするSKIPパケットにデータグラムをカプセル化することでこれを実現できます（つまり、セキュリティで保護されたチャネル構成番号4を想定しています）。
From the home agent to the private (inside) address of the firewall the packet format is:
ホームエージェントからファイアウォールのプライベート（内部）アドレスへのパケット形式は次のとおりです。
DATA PACKET: BETWEEN THE HOME AGENT AND THE FIREWALL
+--------+------+----+-----+--------+--------+-----+
| IP Hdr | SKIP | AH | ESP | mobip | Inner | ULP |
| (SKIP) | Hdr | | | IP Hdr | IP Hdr | |
+--------+------+----+-----+--------+--------+-----+
IP Hdr (SKIP): Source home agent's address Destination private (inside) address on the firewall
IP Hdr（SKIP）：ソースホームエージェントのアドレスファイアウォールの宛先プライベート（内部）アドレス
SKIP Hdr: Source NSID = 0 Master Key-ID = none Destination NSID = 0 Master Key-ID = none
SKIP Hdr：ソースNSID = 0マスターキーID =なし宛先NSID = 0マスターキーID =なし
Mobile-IP IP Hdr: Source home agent's address Destination care-of address
モバイルIP IP Hdr：ソースホームエージェントのアドレス宛先気付アドレス
Inner IP Hdr: Source correspondent node's address Destination mobile node's address
内部IP Hdr：ソースコレスポンデントノードのアドレス宛先モバイルノードのアドレス
ULP: upper-layer payload
ULP：上位層ペイロード
The packet format above does not require the firewall to have a dynamic binding. The association between the mobile node's permanent address and it care-of address can be deduced from the contents of the "Mobile-IP IP Hdr" and the "Inner IP Hdr".
上記のパケット形式では、ファイアウォールが動的バインディングを持つ必要はありません。モバイルノードのパーマネントアドレスとその気付アドレス間の関連付けは、「モバイルIP IP Hdr」と「内部IP Hdr」の内容から推定できます。
Nevertheless, a nomadic binding is an assurance that currently the mobile node is, in fact, at the care-of address.
それにもかかわらず、遊牧バインディングは、現在モバイルノードが実際に気付アドレスにあることを保証します。
The SKIP firewall intercepts the packet, and recovers the Mobile IP encapsulated datagram. Before sending it out, the dynamic packet filter configured by the original Registration Request triggers encryption of this packet, this time by the SKIP firewall for consumption by the mobile node. The resultant packet is:
SKIPファイアウォールはパケットを傍受し、モバイルIPカプセル化データグラムを回復します。送信する前に、元のRegistration Requestによって構成された動的パケットフィルターがこのパケットの暗号化をトリガーします。今回は、モバイルノードによる消費のためにSKIPファイアウォールによって暗号化されます。結果のパケットは次のとおりです。
DATA PACKET: BETWEEN THE FIREWALL AND THE MOBILE NODE
+--------+------+----+-----+--------+--------+-----+
| IP Hdr | SKIP | AH | ESP | mobip | Inner | ULP |
| (SKIP) | Hdr | | | IP Hdr | IP Hdr | |
+--------+------+----+-----+--------+--------+-----+
IP Hdr (SKIP): Source firewall's public (outside) address Destination mobile node's care-of address
IP Hdr（SKIP）：送信元ファイアウォールのパブリック（外部）アドレス宛先モバイルノードの気付アドレス
SKIP Hdr: Source NSID = 0 Master Key-ID = none Destination NSID = 1 Master Key-ID = IPv4 address of the mobile node
SKIP Hdr：ソースNSID = 0マスターキーID =なし宛先NSID = 1マスターキーID =モバイルノードのIPv4アドレス
Mobile-IP IP Hdr: Source home agent's address Destination care-of address
モバイルIP IP Hdr：ソースホームエージェントのアドレス宛先気付アドレス
Inner IP Hdr: Source correspondent node's address Destination mobile node's address
内部IP Hdr：ソースコレスポンデントノードのアドレス宛先モバイルノードのアドレス
ULP: upper-layer payload
ULP：上位層ペイロード
At the mobile node, SKIP processes the packets sent by the firewall. Eventually, the inner IP header and the upper-layer packet (ULP) are retrieved and passed on.
モバイルノードでは、ファイアウォールによって送信されたパケットをSKIPが処理します。最終的に、内部IPヘッダーと上位層パケット（ULP）が取得されて渡されます。
The topic of this document is security. Nevertheless, it is imperative to point out the perils involved in allowing a flow of IP packets through a firewall. In essence, the mobile host itself MUST also take on responsibility for securing the private network, because it extends its periphery. This does not mean it stops exchanging unencrypted IP packets with hosts on the public network. For example, it MAY have to do so in order to satisfy billing requirements imposed by the foreign site, or to renew its DHCP lease.
このドキュメントのトピックはセキュリティです。それにもかかわらず、ファイアウォールを通過するIPパケットのフローを許可することに関連する危険を指摘することは不可欠です。本質的に、モバイルホスト自体も周辺を拡張するため、プライベートネットワークを保護する責任を負う必要があります。これは、パブリックネットワーク上のホストとの暗号化されていないIPパケットの交換を停止するという意味ではありません。たとえば、外部サイトによって課される請求要件を満たすため、またはそのDHCPリースを更新するために、そうする必要がある場合があります。
In the latter case it might filter not only on IP source address, but also on protocol and port numbers.
後者の場合、IP送信元アドレスだけでなく、プロトコルおよびポート番号もフィルタリングする可能性があります。
Therefore, it MUST have some firewall capabilities, otherwise, any malicious individual that gains access to it will have gained access to the private network as well.
したがって、いくつかのファイアウォール機能を備えている必要があります。そうしないと、それにアクセスする悪意のある個人がプライベートネットワークにもアクセスすることになります。
Acknowledgements
謝辞
Ideas in this document have benefited from discussions with at least the following people: Bill Danielson, Martin Patterson, Tom Markson, Rich Skrenta, Atsushi Shimbo, Behfar Razavi, Avinash Agrawal, Tsutomu Shimomura and Don Hoffman. Jim Solomon has also provided many helpful comments on this document.
このドキュメントのアイデアは、少なくとも次の人々との議論から恩恵を受けています。 Jim Solomonは、このドキュメントに関する多くの役立つコメントも提供しています。
References
参考文献
[1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[1] パーキンス、C。、「IPモビリティサポート」、RFC 2002、1996年10月。
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[2] パーキンス、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[3] A. Aziz and M. Patterson, Design and Implementation of SKIP, available on-line at http://skip.incog.com/inet-95.ps. A previous version of the paper was presented at INET '95 under the title Simple Key Management for Internet Protocols (SKIP), and appears in the conference proceedings under that title.
[3] A. AzizおよびM. Patterson、SKIPの設計および実装。http：//skip.incog.com/inet-95.psでオンラインで入手できます。以前のバージョンの論文は、INET '95で「インターネットプロトコル用の単純なキー管理（SKIP）」というタイトルで発表され、そのタイトルで会議の議事録に掲載されました。
[4] Leech, M., Ganis, M., Lee, Y, Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[4] Leech、M.、Ganis、M.、Lee、Y、Kuris、R.、Koblas、D。、およびL. Jones、「SOCKS Protocol Version 5」、RFC 1928、1996年3月。
[5] Leech, M., "Username/Password Authentication for SOCKS V5", RFC 1929, March 1996.
[5] Leech、M。、「SOCKS V5のユーザー名/パスワード認証」、RFC 1929、1996年3月。
[6] Atkinson, R., "IP Encapsulating Payload", RFC 1827, August 1995.
[6] Atkinson、R。、「IP Encapsulating Payload」、RFC 1827、1995年8月。
[7] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[7] Atkinson、R。、「IP Authentication Header」、RFC 1826、1995年8月。
[8] Stephen Kent, message to the IETF's IPSEC mailing list, Message-Id: <v02130500ae569a3e904e@[128.89.30.29]>, September 6, 1996.
[8] Stephen Kent、IETFのIPSECメーリングリストへのメッセージ、Message-Id：<v02130500ae569a3e904e @ [128.89.30.29]>、1996年9月6日。
[9] Tom Markson, private communication, June 12, 1996.
[9] トムマークソン、プライベートコミュニケーション、1996年6月12日。
[10] A. Aziz, T. Markson, H. Prafullchandra. Encoding of an Unsigned Diffie-Hellman Public Value. Available on-line as http://skip.incog.com/spec/EUDH.html.
[10] A. Aziz、T。Markson、H。Prafullchandra。符号なしDiffie-Hellmanパブリックバリューのエンコーディング。 http://skip.incog.com/spec/EUDH.htmlとしてオンラインで入手できます。
Authors' Addresses
著者のアドレス
Gabriel E. Montenegro Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View, California 94303
ガブリエルE.モンテネグロSun Microsystems、Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View、California 94303
Phone: (415)786-6288 Fax: (415)786-6445 EMail: gabriel.montenegro@Eng.Sun.COM
電話：(415)786-6288ファックス：(415)786-6445メール：gabriel.montenegro@Eng.Sun.COM
Vipul Gupta Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View, California 94303
Vipul Gupta Sun Microsystems、Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View、California 94303
Phone: (415)786-3614 Fax: (415)786-6445 EMail: vipul.gupta@Eng.Sun.COM
電話：(415)786-3614ファックス：(415)786-6445メール：vipul.gupta@Eng.Sun.COM
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。