RFC2356 日本語訳
2356 Sun's SKIP Firewall Traversal for Mobile IP. G. Montenegro, V.Gupta. June 1998. (Format: TXT=53198 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Montenegro
Request for Comments: 2356 V. Gupta
Category: Informational Sun Microsystems, Inc.
June 1998
コメントを求めるワーキンググループG.モンテネグロ要求をネットワークでつないでください: 2356年のV.グプタカテゴリ: 情報のサン・マイクロシステムズ・インク1998年6月
Sun's SKIP Firewall Traversal for Mobile IP
モバイルIPのためのSunのスキップファイアウォール縦断
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)インターネット協会(1998)。 All rights reserved。
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
1. 序論… 2 2. ファイアウォールのない移動性… 4 3. 制限はFirewallででしゃばりました… 4 4. 2つのファイアウォールオプション: アプリケーションリレーとIP Security… 5 4.1 SOCKSバージョン5[4]… 5 4.2は[3]をスキップします… 6 5. エージェントとモバイルノード構成… 8 6. サポートのモバイルIP: チャネル構成を保証してください… 9 6.1 私、: 兵士のNetworkの暗号化Outsideだけ… 9 6.2 II、: 終わりから終わりへの暗号化… 10 6.3 III、: 終端間暗号化、中間的認証… 10
Montenegro & Gupta Informational [Page 1] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[1ページ]のRFC2356Sunのスキップファイアウォール縦断
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
6.4、IV: 暗号化内外… 10 6.5 安全なチャネル構成を選びます… 11 7. スキップファイアウォールがあるモバイルIP登録手順… 11 7.1. ファイアウォールを通した登録要求… 12 7.1.1. 外(公共の)のネットワークに関して… 13 7.1.2. 内面(個人的な)のネットワークに関して… 14 7.2. ファイアウォールを通した登録回答… 14 7.2.1. 内面(個人的な)のネットワークに関して… 15 7.2.2. 外(公共の)のネットワークに関して… 15 7.3. 縦断拡大… 16 8. データ転送… 18 8.1. モバイルノードから通信員ノード. 18 8.2までのデータ・パケット。 通信員ノードからモバイルノードまでのデータ・パケット、.198.2、.1、内面(個人的な)のネットワークの中で… 20 8.2.2. 外(公共の)のネットワークに関して… 21 9. セキュリティ問題… 21の承認… 22の参照箇所… 22人の作者のアドレス… 23 完全な著作権宣言文… 24
1. Introduction
1. 序論
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:
以下の議論はファイアウォールによって一般的なインターネットか公衆通信回線と切り離された私設のネットワークから成るネットワーク・コンフィギュレーションを仮定します。 かかわったシステムは以下の通りです。
Montenegro & Gupta Informational [Page 2] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[2ページ]のRFC2356Sunのスキップファイアウォール縦断
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)
モバイルノード(ミネソタ)
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.
本籍は私設のネットワークの範囲の中に下がります。 ユーザは、ホームネットワークからシステムを取り外して、もう1ポイントのインターネットにそれを関連づけます。 この議論に概説されたメカニズムはこの移動性を透明にします: モバイルノードは、まるでちょうどまだそれの中にそれがあるかのようにホームネットワークとそのリソースにアクセスし続けています。 モバイルノードがホームネットワークを残すとき、それが私設のネットワークの境界の中、外で移行するかもしれないのに注意してください。 モバイル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)
外国人のエージェント(ファ)
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.
私設のネットワークと一般的なインターネットの間のアクセスコントロールを実施するシステム(または、システムの収集)。 それはアプリケーションgatewayingや、パケットフィルタリングや暗号のテクニックなどの機能の組み合わせでそうするかもしれません。
Montenegro & Gupta Informational [Page 3] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[3ページ]のRFC2356Sunのスキップファイアウォール縦断
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の話題です。
2. Mobility without a Firewall
2. ファイアウォールのない移動性
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に提供するでしょう。
3. Restrictions imposed by a Firewall
3. Firewallによって課された制限
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.
私設のネットワークを入るか、または出て、ファイアウォールは制限をパケットに課します。 フィルタリング仕様に従わないか、またはある種の認証にかかわる交渉がない場合、パケットは通じて許容されていません。
Montenegro & Gupta Informational [Page 4] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[4ページ]のRFC2356Sunのスキップファイアウォール縦断
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.
これのために、目的地ノードとして私設のネットワークに入ろうとする外のパケットで明らかにファイアウォールを狙わなければなりません。 一般的なインターネットにおけるルーティング骨組みはそれに従って、ファイアウォールとルートの場内放送を見るだけでしょう。 パケットがいったんファイアウォールに到着すると、プライベート・アドレスに運命づけられた本当のパケットは回復されます。
4. Two Firewall Options: Application relay and IP Security
4. 2つのファイアウォールオプション: アプリケーションリレーとIP Security
Before delving into any details, lets examine two technologies which may provide firewall support for mobile nodes:
以前、いずれも調べるのは、詳しく述べて、モバイルノードのファイアウォールサポートを提供するかもしれない2つの技術を調べさせます:
- application relaying or proxying, or
- またはアプリケーションリレーかproxying。
- IP Security.
- IPセキュリティ。
To understand the implications, let's examine two specific schemes to accomplish the above: SOCKS version 5 and SKIP.
含意を理解しているなら、上記を達成するために2つの特定の体系を調べましょう: SOCKSバージョン5とSKIP。
4.1 SOCKS version 5 [4]
4.1 SOCKSバージョン5[4]
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プロトコルに関する訂正明細書です。 また、UDPサービスを含むようにバージョン5を広げてあります。 SOCKSソリューションは、モバイルノード(そのに代わった別のノード)がUDPトラフィックをFWと交換するためにTCPセッションを確立するのを必要とします。 また、それは、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:
- メソッド依存する交渉。 例えば、Username/パスワードAuthentication[5]は1つの周遊旅行を必要とします:
Montenegro & Gupta Informational [Page 5] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[5ページ]のRFC2356Sunのスキップファイアウォール縦断
1. client sends a Username/Password request
2. FW (server) responds
1. クライアントはUsername/パスワード要求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 |
+----+------+------+----------+----------+----------+
+----+------+------+----------+----------+----------+ |RSV| 破片手榴弾で殺傷してください。| ATYP| DST.ADDR| DST.PORT| データ| +----+------+------+----------+----------+----------+ | 2 | 1 | 1 | 変数| 2 | 変数| +----+------+------+----------+----------+----------+
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.
モバイルが新しい状態でaを登録するたびに上をしなければならないのを覚えておいてください、注意、-、アドレス。 この非能率に加えて、この体系は、私たちがIPがデータグラムであるとカプセル化するのにUDPを使用するのを必要とします。これをする少なくとも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.
このヘッダーは直接届いていないそれらに達するようにかかわるすべてのパーティーによって必要とされたリレー情報を含んでいます。
4.2 SKIP [3]
4.2はスキップされます。[3]
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
SKIPに基づくソリューションはこのシナリオで非常に魅力的です、モバイルノードとファイアウォールが信頼関係を実現する前に周遊旅行時間が全く被られないとき: ファイアウォールは、最初のものを受け取るとすぐに、モバイルノードのためにパケットをリレーし始めることができます。 [7] これが、SKIPがAHと共に使用されているのをもちろん含意するので、認証情報は各パケットに含まれています。 また、超能力[6]を使用するのによる暗号化はこのシナリオで想定されます、全体のインターネットが敵対的環境であると考えられるので。 提供される超能力変換
Montenegro & Gupta Informational [Page 6] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[6ページ]のRFC2356Sunのスキップファイアウォール縦断
both authentication and encryption could be used, in which case the AH header need not be included.
認証と暗号化の両方を使用できました、その場合、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.
互いの認証されたディフィー-ヘルマン公共のコンポーネント(また、公共の値として、知られている)によってファイアウォールとモバイルノードは以前に、構成されるかもしれません。 あるいはまた、彼らは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の別の利点はその遊牧民的なアプリケーションのサポートです。 通常、安全なIP層のチャンネルで交信する2人のホストが、適切なセキュリティ協会に到着するのに入って来るパケットに関するIPソースと送付先アドレスを使用します。 受取人が正しい証明書を入手するのに使用しなければならない主要なIDを含んでいることによって、SKIPヘッダーは容易にこのデフォルトメカニズムに取って代わることができます。
The key id is specified by two fields in the SKIP header:
主要なイドは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) 唯一適切な証明書をとって来る際に使用するイドを示す(名スペースの中で)マスターキー識別子(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.
1にNSIDを設定するのによる例とホームアドレスへのMKIDが「私の公共のコンポーネントを見上げるのにIPソースを無視して、代わりに私のホームアドレスを使用する」ときモバイルノードが、受信機を言う。 同様に、8にNSIDを設定すると、使用しているUnsignedディフィー-ヘルマン(UDH)証明書は可能にされます。
In this case, the MKID is set to the MD5 hash of the DH public component [10].
この場合、MKIDはDHの公共の部品[10]のMD5ハッシュに用意ができています。
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
NSID/MKIDの特徴に加えて「遊牧民的な」アクセスコントロールリストエントリーの形でSKIPファイアウォールの適切な方針でモバイルIPをサポートするのは最も良いです。 これは主要なIDによってフィルターにかけられるエントリーです、IPソースアドレスの代わりに、普通のケースのように。 それ
Montenegro & Gupta Informational [Page 7] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[7ページ]のRFC2356Sunのスキップファイアウォール縦断
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ソースアドレスからもアクセスを許す」ために、翻訳します。 その上、入って来るパケットには、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パケット・フォーマットを理解させる別の利点について議論します。
In what follows we assume a SKIP-based solution.
続くことでは、私たちはSKIPベースのソリューションを仮定しますか?
5. Agents and Mobile Node Configurations
5. エージェントとモバイルノード構成
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"
ファイアウォールの観点から、これらの2つのケースの主な違いは、どのノードが一番はずれの暗号化カプセル化を準備するかに依ります。 ファイアウォールは入って来るパケットで一番はずれのSKIPヘッダーを創造するノードのディフィー・ヘルマン公共の成分を得ることができなければなりません。 これは場合「b」で単に保証するのにおいて可能です、モバイルノードとファイアウォールがともに同じ管理ドメインに属すので。 モバイルノードがRegistration Requestを試みるとき、問題はさらに明らかです。 外国人のエージェントがここの、単なる「再-層」でなく、それは、実際にモバイルノードによって送られたパケットを調べて、それに従って、エージェントサービスを変更します。 要するに、モバイルIPの現在の仕様とインターネットにおける、信頼の現在の不足が全体であると仮定して、ケース「b」だけが可能です。 ケース“a"が拡大を必要とするだろう、(例えば、「リレー」
Montenegro & Gupta Informational [Page 8] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[8ページ]のRFC2356Sunのスキップファイアウォール縦断
Registration Request), and modifying code at the home agent, the firewall and the foreign agent.
登録Request)、そして、ホームのエージェント、ファイアウォール、および外国人のエージェントにおけるコードを変更すること。
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.
したがって、Itはモバイルノードが共同見つけられたアドレスで作動すると仮定するのが最も簡単です。
6. Supporting Mobile IP: Secure Channel Configurations
6. サポートのモバイルIP: 安全なチャネル構成
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.
モバイルノードは2つの異なったタイプのトラフィックに参加します: モバイルIP登録プロトコルとデータ。 簡単にするために、以下の議論は、モバイルノードによってホームのエージェントに送られた初期のRegistration Requestを調べることによって、異なった安全なチャネル構成を評価します。
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とミネソタ(モバイルノード)の間の領域は、外部か公衆通信回線です。
6.1 I: Encryption only Outside of Private Network
6.1、私: 兵士のNetworkの暗号化Outsideだけ
HA FW MN
<=====================> SKIP (AH + ESP)
<-----------------------------------> Registration Request path
ハ、FWミネソタ<。=====================>スキップ、(+ 超能力) ああ、<。----------------------------------->登録Request経路
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.
トラフィックはモバイルノードの間で一般的なインターネット、およびファイアウォールの外部のインタフェースの外に暗号化されるだけです。 これは必要な状態で最小です。 より高価な暗号化されたチャンネルがそれが必要であるところで使用されるだけであるとき、それは最も望ましい構成です: 公衆通信回線に関して。
Montenegro & Gupta Informational [Page 9] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[9ページ]のRFC2356Sunのスキップファイアウォール縦断
6.2 II: End-to-End Encryption
6.2、II: 終端間暗号化
Another possible configuration extends the encrypted tunnel through the firewall:
別の可能な構成はファイアウォールを通して暗号化されたトンネルを広げています:
HA FW MN
<===================================> SKIP (AH + ESP)
<-----------------------------------> Registration Request path
ハ、FWミネソタ<。===================================>スキップ、(+ 超能力) ああ、<。----------------------------------->登録Request経路
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.
これは、簡単なパケットリレーかgatewaying機能を実行するためにファイアウォールを制限します。 パケットで適切な目的地NSIDを使用することによって、これを達成できるでしょうが、それはたぶん実際には、「非-実現可能」です。 理由はこの代替手段がたぶんそれほどコンピュータセキュリティ人員にポピュラーでないということです、ファイアウォールによって行われるのではなく、認証がホームのエージェントに行われて、後者のセキュリティが前者のよりはるかに潜在的に弱いので。
6.3 III: End-to-End Encryption, Intermediate Authentication
6.3、III: 終端間暗号化、中間的認証
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ヘッダー)について確かめた後に、ファイアウォールは暗号化されたパケット(超能力hdr)をホームのエージェントに送ります。
HA FW MN
<+++++++++++++++++++++> SKIP authentication
<===================================> SKIP encryption
<-----------------------------------> Registration Request path
HA FW MN<+++ + + + + + + + + + + + + + + + + + + >SKIP認証<。===================================>SKIP暗号化<。----------------------------------->登録Request経路
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は、終わりまでの終わりのセキュリティを中間的認証に提供するのに使用されます。 可能ですが、このオプションは、参加実体がそれらの対状長期のディフィーヘルマン共有秘密キーを中間的ノードに明らかにするのを含意します。
Whereas Option 2 above is probably not agreeable to security and system administration personnel, option 3 is unsavory to the end user.
セキュリティとシステム管理の人員には、上のOption2はたぶん快くはありませんが、エンドユーザにとって、オプション3はまずいです。
6.4 IV: Encryption Inside and Outside
6.4、IV: 暗号化内外
HA FW MN
<============><=====================> SKIP (AH + ESP)
<-----------------------------------> Registration Request path
ハ、FWミネソタ<。=>======<==========>スキップ、(+ 超能力) ああ、<。----------------------------------->登録Request経路
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
トラフィックは公衆の上と、そして、私設のネットワークの上で暗号化されます。 公衆通信回線では、暗号化はモバイルノードとファイアウォールとのセキュリティ協会によって書き取られます。 私設のネットワークでは、それはホームの間のセキュリティ協会によって書き取られます。
Montenegro & Gupta Informational [Page 10] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[10ページ]のRFC2356Sunのスキップファイアウォール縦断
agent and the firewall.
エージェントとファイアウォール。
6.5 Choosing a Secure Channel Configuration
6.5 安全なチャネル構成を選ぶこと。
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はcleartextカプセル化メカニズムを使用します。 これは例えば、IPカプセル化[2]にIPを使用することによって、入手可能です。
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.
ファイアウォールが両方の公共の、そして、私設のネットワークで暗号化を治めるセキュリティ協会に関係するので、それはいつもホームのエージェントとモバイルノードによって交換されるトラフィックを点検できます。 これが何か関心のものであるなら、ホームのエージェントとモバイルノードは、双方向のトンネルを設立して、それを暗号化するかもしれません。
7. Mobile IP Registration Procedure with a SKIP Firewall
7. スキップファイアウォールがあるモバイルIP登録手順
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
私設のネットワークの中を移動するとき、モバイルノードは直接ホームのエージェントにRegistration Requestsを送ります。 公共のインターネットでは、それはaでオリジナルのRegistration Requestをカプセル化しなければなりません。
Montenegro & Gupta Informational [Page 11] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[11ページ]のRFC2356Sunのスキップファイアウォール縦断
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パケットはファイアウォールに運命づけられました。 モバイルノードは“inside"と「外」のアドレスを見分けなければなりません。 アドレスの範囲を定義する1セットの規則でこれを達成できるでしょう。 それにもかかわらず、実際のインストールはまさに何がプライベート・アドレスであるか、そして、何がプライベート・アドレスでないかを定義することにおける重大な苦労を提示するかもしれません。
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.
ホームのエージェントは、また、“inside"と「外」のアドレスを見分けなければなりませんが、ダイレクトユーザ入力の潜在的恩恵を欠いています。 それに従って、モバイルノードがその知識をホームのエージェントに伝えるのは、可能であるべきです。 これを達成するために、私たちはRegistration RequestsとRepliesとTraversal Extensionを定義します。 また、複数のファイアウォールを横断するとき、この拡大も役に立ちます。
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はRegistration RequestsとRepliesとの使用のためにTraversal Extensionを定義します。
7.1. Registration Request through the Firewall
7.1. ファイアウォールを通した登録要求
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によって定義されたメカニズムを使用するモバイルノードは、ホームから移動して去ったと発見します。 それは、海外サイトでローカルアドレスを取得して、ホームのエージェントのために作られていたRegistration Requestを構成します。 モバイルノードは、このパケットが、SKIPによって処理される必要であるかどうか決めなければなりません。
Montenegro & Gupta Informational [Page 12] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[12ページ]のRFC2356Sunのスキップファイアウォール縦断
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) モバイルノードが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から適切なセキュリティー・サービスを要求するのは、最も良いです。
7.1.1. On the Outside (Public) Network
7.1.1. 外(公共の)のネットワークに関して
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モジュールは、パケットを扱って、暗号化するのにファイアウォール送付先アドレスとファイアウォールの証明書を使用しなければなりません。 それは、超能力[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.
Master Key-IDがモバイルノードのホームアドレスであることを示して、SKIPヘッダーのソースNSIDは1と等しいです。 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のディフィー-ヘルマンの公共の部品[10]を使用するのも可能です。 Certificate Authorityの必要は全くないので、そうするのはSKIPのインフラストラクチャ要件を大いに減らします。 もちろん、これが可能であるように、しっかりと主体の名前を伝えなければなりません。
REGISTRATION REQUEST: BETWEEN THE MOBILE NODE AND THE FIREWALL +---------------+----------+----+-----+--------------+--------------+ | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request | +---------------+----------+----+-----+--------------+--------------+
登録要求: モバイルノードとファイアウォール+の間で---------------+----------+----+-----+--------------+--------------+ | IP Hdr(スキップします)| Hdrをスキップしてください。| ああ| 超能力| 内側のIP Hdr| レッジ要求| +---------------+----------+----+-----+--------------+--------------+
IP Hdr (SKIP):
Source mobile node's care-of address
Destination firewall's public (outside) address
IP Hdr(スキップします): ソースノードのモバイルもの、注意、-、Destinationがファイアウォールの公共(外)のアドレスであると扱ってください。
Montenegro & Gupta Informational [Page 13] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[13ページ]のRFC2356Sunのスキップファイアウォール縦断
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
Hdrをスキップしてください: Inner IP Hdrが1Master Key-ID=IPv4が0Master KeyモバイルノードDestination NSID=ID=なにも扱わないソースNSID=: ソースノードのモバイルもの、注意、-、Destinationホームがエージェントのアドレスであると扱ってください。
7.1.2. On the Inside (Private) Network
7.1.2. 内面(個人的な)のネットワークに関して
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 Firewallのダイナミックなパケットフィルタリングがダイナミックな結合を確立するこの情報を使用する、注意、-、アドレス、そして、モバイルノードの永久的なホームアドレス。
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ヘッダーを処理して、内部のパケットを回復するようにうながして。 次に、それは別の外国行きのインタフェースにオリジナルのパケットを提供します、それがホームのエージェント(私設のネットワークの中のアドレス)に扱われるので。 安全なチャネル構成がNo.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(スキップします)| Hdrをスキップしてください。| ああ| 超能力| 内側のIP Hdr| レッジ要求| +---------------+----------+----+-----+--------------+--------------+
IP Hdr (SKIP):
Source firewall's private (inside) address
Destination home agent's address
IP Hdr(スキップします): ソースファイアウォールの個人的な(inside)アドレスのDestinationホームのエージェントのアドレス
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
Hdrをスキップしてください: Destination NSIDの0Master KeyソースNSID=ID=なにもがInnerの0Master Key-ID=いずれとも等しくない、IP Hdr: ソースノードのモバイルもの、注意、-、Destinationホームがエージェントのアドレスであると扱ってください。
7.2. Registration Reply through the Firewall
7.2. ファイアウォールを通した登録回答
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
ホームのエージェントは、Registration Requestを処理して、Registration Replyを構成します。 応じる前に調べる、注意、-、アドレスは、モバイルノードで報告して、それが外のアドレスに対応するかどうか決定します。 そうだとすれば、ホームのエージェントは、ファイアウォールを通してすべてのトラフィックを返送する必要があります。 ホームのエージェントはそうすることができます。
Montenegro & Gupta Informational [Page 14] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[14ページ]のRFC2356Sunのスキップファイアウォール縦断
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パケットでオリジナルのRegistration Replyをカプセル化することによって、これを達成してください(すなわち、私たちは、安全なチャネル構成がNo.4であると思います)。
7.2.1. On the Inside (Private) Network
7.2.1. 内面(個人的な)のネットワークに関して
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 Firewallを通したホームのエージェントからモバイルノードまでのパケットには、上で示されるのと同じ形式があります。 関連分野は以下の通りです。
REGISTRATION REPLY: BETWEEN THE HOME AGENT AND THE FIREWALL +---------------+----------+----+-----+--------------+------------+ | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply | +---------------+----------+----+-----+--------------+------------+
登録回答: ホームのエージェントとファイアウォール+の間で---------------+----------+----+-----+--------------+------------+ | IP Hdr(スキップします)| Hdrをスキップしてください。| ああ| 超能力| 内側のIP Hdr| レッジ返答してください。| +---------------+----------+----+-----+--------------+------------+
IP Hdr (SKIP):
Source home agent's address
Destination firewall's private (inside) address
IP Hdr(スキップします): ソースのホームのエージェントアドレスDestinationのファイアウォールの個人的な(inside)アドレス
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
Hdrをスキップしてください: Destination NSIDの0Master KeyソースNSID=ID=なにもがInnerの0Master Key-ID=いずれとも等しくない、IP Hdr: ソースのホームのエージェントアドレスDestinationのノードのモバイルもの、注意、-、アドレス
7.2.2. On the Outside (Public) Network
7.2.2. 外(公共の)のネットワークに関して
The SKIP Firewall recovers the original Registration Reply packet and looks at the destination address: the mobile node's care-of address.
SKIP Firewallはオリジナルの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 Firewallのダイナミックなパケットフィルタリングがダイナミックなマッピングを証明するのに、初期のRegistration Request(Secton7.1)を使用した、注意、-、アドレス、そして、モバイルノードのMaster Key-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.
超能力が必要性を取り除くトンネリングモードのこのダイナミックな拘束力がある能力と使用は「リレーRegistration Request」と共にモバイルIPプロトコルを広げています。 しかしながら、それは、Registration Replyが対応するRegistration Requestを進めたのと同じファイアウォールを通して私設のネットワークを出るのを必要とします。
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
また、ダイナミックな結合からモバイルノードの本籍を得ることの代わりに、モバイルIP意識しているファイアウォールはRegistration Reply自身からそれを得るかもしれません。 これは、Registration RequestsとRepliesが周辺を横断するのをファイアウォールを状態がなく表して、貸します。
Montenegro & Gupta Informational [Page 15] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[15ページ]のRFC2356Sunのスキップファイアウォール縦断
the private network through different firewalls.
異なったファイアウォールを通した私設のネットワーク。
REGISTRATION REPLY: BETWEEN THE FIREWALL AND THE MOBILE NODE +---------------+----------+----+-----+--------------+------------+ | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply | +---------------+----------+----+-----+--------------+------------+
登録回答: ファイアウォールとモバイルノード+の間で---------------+----------+----+-----+--------------+------------+ | IP Hdr(スキップします)| Hdrをスキップしてください。| ああ| 超能力| 内側のIP Hdr| レッジ返答してください。| +---------------+----------+----+-----+--------------+------------+
IP Hdr (SKIP):
Source firewall's public (outside) address
Destination mobile node's care-of address
IP Hdr(スキップします): ソースファイアウォールの公衆(外)が、Destinationがモバイルノードのものであると扱う、注意、-、アドレス
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
Hdrをスキップしてください: Destination NSIDの0Master KeyソースNSID=ID=いずれもモバイルノードInner IP Hdrの1Master Key-ID=IPv4 addrと等しくはありません: ソースのホームのエージェントアドレスDestinationのノードのモバイルもの、注意、-、アドレス
7.3. Traversal Extension
7.3. 縦断拡大
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.
Traversal ExtensionはRegistration Requestsのモバイルノード、およびRegistration Repliesのホームのエージェントによって入れられるかもしれません。 に従って、セクション3.6 .1 .3 [1]では、Traversal ExtensionはモバイルホームAuthentication Extensionの前に現れなければなりません。 Traversal Extensionはモバイルノードとそのホームのエージェントの間には、1縦断ポイント(ファイアウォール、fireridgesなど)以上があるという明白な通知です。 これらのシステムの先でアクセスを交渉すると、新しい認証ヘッダー、およびことによると受信者IPアドレスが縦断アドレスである新しい要約のヘッダー(恐らくモードにトンネルを堀っている超能力の一部としての)は含意されるかもしれません。
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アドレス空間の間の境界のシステムをtargettedしなければなりません(恐らく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.
SHOULDがRegistration Requestsに縦断ポイントあたり1Traversal Extensionに含むモバイルノード。 存在しているなら、彼らのオーダーはまさに、モバイルノードからホームのエージェントに向かって流れるのに従ってパケットがそれらに遭遇するオーダーに合わなければなりません。
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.
道に沿って追加ファイアウォールがあるかもしれませんが、明白な交渉がそうであるSHOULDがそれらのシステムを含むだけである縦断ポイントのリストが必要であるのに注意してください。
Montenegro & Gupta Informational [Page 16] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[16ページ]のRFC2356Sunのスキップファイアウォール縦断
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.
同様に、ホームのエージェントSHOULDはRegistration Repliesに縦断ポイントあたり1Traversal Extensionを含んでいます。 存在しているなら、彼らのオーダーはまさに、ホームのエージェントからモバイルノードまで流れるのに従ってパケットがそれらに遭遇するオーダーに合わなければなりません。
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.
アクセスがどう交渉されるかに関してTraversal Extensionは少しの指示も含んでいません。 おそらく、別々の手段でこの情報を得ます。 このドキュメントは、ファイアウォール発見問題を解決するのを試みません、すなわち、それが縦断ポイントのリストを発見する方法を指定しません。
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に下落するという事実は、Reply、ホームのエージェントかモバイルノードであるならRegistration RequestでTraversal Extensionに遭遇してください。さもないと、彼らが静かにそれを無視するかもしれないのを含意します。 これはTraversal Extensionが本質的にはヒントであるという事実と一致しています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mn、ハ、縦断アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mn縦断アドレスにハ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
129
129
Length
長さ
10
10
Reserved
予約されます。
0
0
MN to HA Traversal Address
Mn、ハ、縦断アドレス
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アドレス、モバイルノードによってホームのエージェントに向かって送られたデータグラムで遭遇する中間システムかファイアウォール。 これは通常、ファイアウォールかファイアウォール複合体の外部アドレスです。
Montenegro & Gupta Informational [Page 17] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[17ページ]のRFC2356Sunのスキップファイアウォール縦断
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 Requestsでこの分野を初期化しなければなりません。 通常、それがすべて、Registration Repliesでは、0であるさもなければ、モバイルノードSHOULDはヒントとしてそれを解釈します。
HA to MN Traversal Address
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.
Registration Repliesでこの分野を初期化しなければなりません。 通常、それがすべて、Registration Requestsでは、0であるさもなければ、ホームのエージェントSHOULDはヒントとしてそれを解釈します。
8. Data Transfer
8. データ転送
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.
データ転送は上に概説されたRegistration Requestと同様の系列に沿って続きます。 セクション8.1はモバイルノードによって通信員ノードに送られたデータ通信量を論じます。 セクション8.2はホームのエージェントによってモバイルノードにトンネルを堀られる逆のトラフィックのためにパケット・フォーマットを示しています。
8.1. Data Packet From the Mobile Node to a Correspondent Node
8.1. モバイルノードから通信員ノードまでのデータ・パケット
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機能は、Inner IPヘッダーを調べて、“a"と「セクション7.1からの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(スキップします)| Hdrをスキップしてください。| ああ| 超能力| 内側のIP Hdr| ULP| +---------------+----------+----+-----+--------------+------+
IP Hdr (SKIP):
Source mobile node's care-of address
Destination public (outside) address on the firewall
IP Hdr(スキップします): ソースノードのモバイルもの、注意、-、Destinationがファイアウォールに関する公共(外)のアドレスであると扱ってください。
Montenegro & Gupta Informational [Page 18] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[18ページ]のRFC2356Sunのスキップファイアウォール縦断
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
Hdrをスキップしてください: Inner IP Hdrが1Master Key-ID=IPv4が0Master KeyモバイルノードDestination NSID=ID=なにも扱わないソースNSID=: ソースモバイルノードのホームアドレスDestination通信員ノードのアドレス
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 Firewallはこのパケットを妨害して、Inner 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: ソース、注意、-、Destinationホームがエージェントアドレスであると扱ってください。
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ファイアウォールと、異なります。 オンである間、公衆通信回線(これらのホストとのモバイルノードのコミュニケーション)は双方向のトンネルを使用しなければなりません。
8.2. Data Packet From a Correspondent Node to the Mobile Node
8.2. 通信員ノードからモバイルノードまでのデータ・パケット
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パケットでデータグラムをカプセル化することによって、これを達成できます(すなわち、私たちは、安全なチャネル構成がNo.4であると思います)。
Montenegro & Gupta Informational [Page 19] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[19ページ]のRFC2356Sunのスキップファイアウォール縦断
8.2.1 Within the Inside (Private) Network
8.2.1 内面(個人的な)のネットワークの中で
From the home agent to the private (inside) address of the firewall the packet format is:
ホームのエージェントから個人的なファイアウォールの(inside)アドレスまで、パケット・フォーマットは以下の通りです。
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| スキップ| ああ| 超能力| mobip| 内側| ULP| | (スキップ) | Hdr| | | IP Hdr| IP Hdr| | +--------+------+----+-----+--------+--------+-----+
IP Hdr (SKIP):
Source home agent's address
Destination private (inside) address on the firewall
IP Hdr(スキップします): ファイアウォールに関するソースのホームのエージェントアドレスDestinationの個人的な(inside)アドレス
SKIP Hdr:
Source NSID = 0
Master Key-ID = none
Destination NSID = 0
Master Key-ID = none
Hdrをスキップしてください: Destination NSIDの0Master KeyソースNSID=ID=いずれも0Master Key-ID=なにもと等しくはありません。
Mobile-IP IP Hdr:
Source home agent's address
Destination care-of address
モバイルIP IP Hdr: ソースのホームのエージェントアドレスDestination、注意、-、アドレス
Inner IP Hdr:
Source correspondent node's address
Destination mobile node's address
内側のIP Hdr: ソース通信員ノードのアドレスDestinationモバイルのノードのアドレス
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.
それにもかかわらず、a遊牧民的な結合が事実上、現在のモバイルノードがある保証である、注意、-、アドレス
Montenegro & Gupta Informational [Page 20] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[20ページ]のRFC2356Sunのスキップファイアウォール縦断
8.2.2. On the Outside (Public) Network
8.2.2. 外(公共の)のネットワークに関して
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| スキップ| ああ| 超能力| mobip| 内側| ULP| | (スキップ) | Hdr| | | IP Hdr| IP Hdr| | +--------+------+----+-----+--------+--------+-----+
IP Hdr (SKIP):
Source firewall's public (outside) address
Destination mobile node's care-of address
IP Hdr(スキップします): ソースファイアウォールの公衆(外)が、Destinationがモバイルノードのものであると扱う、注意、-、アドレス
SKIP Hdr:
Source NSID = 0
Master Key-ID = none
Destination NSID = 1
Master Key-ID = IPv4 address of the mobile node
Hdrをスキップしてください: Destination NSIDの0Master KeyソースNSID=ID=いずれもモバイルノードのIPv4 1Master Key-ID=アドレスと等しくはありません。
Mobile-IP IP Hdr:
Source home agent's address
Destination care-of address
モバイルIP IP Hdr: ソースのホームのエージェントアドレスDestination、注意、-、アドレス
Inner IP Hdr:
Source correspondent node's address
Destination mobile node's address
内側のIP Hdr: ソース通信員ノードのアドレスDestinationモバイルのノードのアドレス
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)は、救済されて、伝えられます。
9. Security Considerations
9. セキュリティ問題
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リースを更新しなければならないかもしれません。
Montenegro & Gupta Informational [Page 21] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[21ページ]のRFC2356Sunのスキップファイアウォール縦断
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.
考えは本書では少なくとも以下の人々との議論の利益を得ました: ビル・ダニエリソン、マーチン・パターソン、トムMarkson、豊かなSkrenta、篤Shimbo、Behfar Razavi、Avinash Agrawal、Tsutomu Shimomura、およびドン・ホフマン。 また、ジム・ソロモンはこのドキュメントの上に多くの役に立つコメントを提供しました。
References
参照
[1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[1] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[2] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、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] SKIPのA.アジズ、M.パターソン、Design、およびImplementation、利用可能である、 http://skip.incog.com/inet-95.ps では、オンラインです。 紙の旧バージョンは、INET95年にインターネットプロトコル(SKIP)のためにタイトルSimple Key Managementの下に提示されて、そのタイトルの下における会議の議事録に載っています。
[4] Leech, M., Ganis, M., Lee, Y, Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[4] ヒル、M.、Ganis M.、リー、Y、Kuris、R.、Koblas、D.、およびL.ジョーンズ、「ソックスはバージョン5インチについて議定書の中で述べます、RFC1928、1996年3月。」
[5] Leech, M., "Username/Password Authentication for SOCKS V5",
RFC 1929, March 1996.
[5] ヒル、M.、「ソックスV5"、RFC1929、1996年3月のためのユーザ名/パスワード認証。」
[6] Atkinson, R., "IP Encapsulating Payload", RFC 1827, August
1995.
[6] アトキンソン、R.、「有効搭載量を要約するIP」、RFC1827、1995年8月。
[7] Atkinson, R., "IP Authentication Header", RFC 1826, August
1995.
[7] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、1995年8月。
[8] Stephen Kent, message to the IETF's IPSEC mailing list,
Message-Id: <v02130500ae569a3e904e@[128.89.30.29]>, September
6, 1996.
[8] スティーブン・ケント、IETFのIPSECメーリングリスト、Message-イドへのメッセージ: <v02130500ae569a3e904e@、[128.89 .30 .29] 1996年9月6日の>。
[9] Tom Markson, private communication, June 12, 1996.
[9] トムMarkson、私信、1996年6月12日。
Montenegro & Gupta Informational [Page 22] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[22ページ]のRFC2356Sunのスキップファイアウォール縦断
[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.アジズ、T.Markson、H.Prafullchandra。 無記名のディフィー-ヘルマン公共のValueはコード化されます。 利用可能である、 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.モンテネグロサン・マイクロシステムズ・インク901サンアントニオ道路Mailstop UMPK15-214カリフォルニア 94303
Phone: (415)786-6288 Fax: (415)786-6445 EMail: gabriel.montenegro@Eng.Sun.COM
以下に電話をしてください。 (415)786-6288 Fax: (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グプタサン・マイクロシステムズ・インク901サンアントニオ道路Mailstop UMPK15-214カリフォルニア 94303
Phone: (415)786-3614 Fax: (415)786-6445 EMail: vipul.gupta@Eng.Sun.COM
以下に電話をしてください。 (415)786-3614 Fax: (415)786-6445 メールしてください: vipul.gupta@Eng.Sun.COM
Montenegro & Gupta Informational [Page 23] RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
モバイルIP1998年6月のためのモンテネグロとグプタ情報[23ページ]のRFC2356Sunのスキップファイアウォール縦断
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Montenegro & Gupta Informational [Page 24]
モンテネグロとグプタInformationalです。[24ページ]
一覧
スポンサーリンク
