|
ネットワークワーキンググループ Request for Comments： 3093 分類： 情報提供 |
M. Gaynor S. Bradner Harvard 大学 2001年4月1日 |
このメモは、インターネットコミュニティに対して情報を提供します。 何らインターネット標準を規定するものではありません。 本書の配布に制限はありません。
Copyright (C) The Internet Society (2001). All Rights Reserved.
インターネットの「エンド to エンド」アーキテクチャによるインターネットの透過性は、 新技術やサービスの目覚ましい革新をもたらしました [1]。 しかし、近年のファイアウォール技術における開発は、 このモデルを変更してしまい、 イノベーションを抑制することが示されてきた。 我々は、ファイアウォールのセキュリティモデルを破壊することなくイノベーションをできるようにするために、 FEP (Firewall Enhancement Protocol)を提案します。 ファイアウォール運用管理者からの協力をあおがずとも、FEPは、 あらゆるアプリケーションがファイアウォールを通り抜けることができるようにします。 我々の方法論は、あらゆるアプリケーション層TCP/IP (Transmission Control Protocol/User Datagram Protocol)パケットをHTTP (HyperText Transfer Protocol)プロトコル上に敷くことです。 なぜなら、HTTPパケットは、典型的には、 ファイアウォールを通過できるからです。 このスキームは、 ファイアウォールの実質的なセキュリティの有用性を破壊しません。 なぜならば、ファイアウォールは、外部からの攻撃を妨害し、 内部からの脅威を無視するように設計されているからです。 FEPの利用は、 現行のファイアウォールセキュリティモデルと互換性があります。 なぜならば、これは、 ファイアウォールの内側のホストからの協力を要求するからです。 FEPは、両世界にとって最善を実現できるようにします。 ：すなわち、ファイアウォールのセキュリティと、 ファイアウォール経由の透過なトンネリングです。
本書中のキーワード"MUST"、 "MUST NOT"、"REQUIRED"、 "SHALL"、"SHALL NOT"、 "SHOULD"、"SHOULD NOT"、 "RECOMMENDED"、"MAY"、 "OPTIONAL"は、 RFC2119 [1] に記述されているように解釈されるべきものです。
インターネットは、「まだ10年も経っていませんが、 協働環境としては決して機能することは無いと通信業界が主張していたこと」を考えると、 うまくやってきました。 これについて、多くの理由があります。； 特に強い理由は、Reed、 SeltzerおよびClarkによって検討された「エンド to エンド論」[2] です。 「エンド」におけるイノベーションは、 かつて想像されていたよりも大きな価値を創り出す、 とても強力な方法論であることが証明されてきました。 しかし、Clarkが [6] において注目しているように、世界は変化しています。 産業界のインターネット接続に伴って、 セキュリティについての関心事は、 「エンド to エンド」パラダイムを破壊することさえも代償とするほどに、 最重要事項(paramount)となってしまいました。 一例は、ファイアウォール(外部者が、 企業内へ不正アクセスすることを防ぐデバイス)です。 我々の新しいプロトコルであるFEP (Firewall Enhancement Protocol)は、 ファイアウォールによって作られたセキュリティのレベルを維持しつつ、 「エンド to エンド」モデルを再構築するために設計されています。
「『エンド to エンド』モデルがいかに強力であるか」をみるために、
下例を検討しましょう。
ScottとMarkが、ある良いアイディアと、
ある程度の実装能力をもっている場合、彼らは、作品を作って、
それを使って、他の友人にそれを送ることができる。
これが良いアイディアであると判明した場合、この友人らは、
それを採用し、おそらくそれを改良することができる。
そこにファイアウォールを導入します。：
Markが、
たまたまファイアウォールを導入している会社で働いている場合、
彼は、友人のScottと実験できません。
イノベーションは、より難しくなり、おそらく不可能です。
ScottとMarkが、
それらがユーザにより良いサービスを提供できるようにするための何らかの実験を行うことを望む場合、
ITマネージャーの仕事とは何でしょうか？
これは、Webが創り出された過程と同じです。：
才能と、
わずかな良いアイディアと、革新する能力をもった奴が居ました。
ファイアウォールは、重要であり、我々は、 (他者が迷惑を受けない限り)あらゆる者の自身を守る権限を、 彼らが望むいかなるやり方であれ尊重します。 ファイアウォールは、インターネットにおいて、動作し、 存在しています。 しかし、ファイアウォールは、内部の脅威からではなく、 外部の脅威から防護するために構築されています。 我々が提案したプロトコルは、 ファイアウォールのセキュリティモデルを壊しません。； ファイアウォールは、 なおも特定のファイアウォールが守ることができるすべての外部のリスクから守ります。 我々のプロトコルが動作するためには、 ファイアウォールの内側の者は、 TCP 80番ポートにアクセスできるアプリケーション層プロトコルを動作させなければなりません。 我々の概念設計は、 一貫したレベルのセキュリティを可能にする一方、 ファイアウォールに責任を負うITマネージャーを迂回する。 我々は、外部からのセキュリティと、 ことさらに妥協をはかること無しに、そして、最も良いのは、 承認のためにいかなるマネージャーをも巻き込む時間を費やす必要無しに、 革新するための自由を提供します。
我々は、増加しつつある、専らHTTPを使うアプリケーションから、 このアイディアを得ました。 なぜならば、HTTPは、 ファイアウォールのバリアを迂回できるからです。 この特定のアプリケーションの断片的な(piecemeal)配備は、 ファイアウォールによって作り出されたイノベーションの挑戦に適合させるためには効率的なやり方ではありません。 我々は、 TCP/IP自体がHTTP上を運ばれるようなプロセスを開発することを決意しました。
このイノベーションによって、あらゆる人々が、 特定のアプリケーション用にファイアウォールアクセスを扱うという面倒なプロセスを行う必要無しに、 あらゆる新しいTCP/IPアプリケーションを直ちに使えるようになります。 この提案の意図していなかった副産物は、 「既存のTCP/IPアプリケーションは、 ユーザにより良いサービスを提供するようにサポートされうること」です。 FEPがあれば、ユーザは、 「どのアプリケーションを動作させるか？」を判断できます。
我々のプロトコルは、シンプルであり、 IPパケットのMIME encodingについてのEastlakeの提案 [3] に基づいています。 我々は、 どこにでも存るHTTPプロトコルフォーマットを使います。 IPデータグラムは、 HTTPメッセージのメッセージbodyに入れて運ばれ、 TCPパケットヘッダー情報は、 そのメッセージのHTTPヘッダー中に符号化されます。 このヘッダーフィールドのASCII encodingは、 多くの優位性をもち、これには、可読性、 新しいアプリケーションのデバッグ可能性(debuggability)の向上、 および 、パケット情報のログ記録の容易性が含まれます。 これが広く採用されるようになる場合、 tcpdumpのようなツールは、陳腐化します。
図1は、我々のプロトコルの抽象的な概観を示します。 host A (outside the ファイアウォール)中のアプリケーション(1)は、 TCP/IPデータグラムをhost B (within the ファイアウォール)宛に送ります。 トンネルインターフェイスを使って、TCP/IPデータグラムは、 我々のFEPソフトウェア(2)宛に経路制御されます。 これは、HTTPメッセージ中のデータグラムを符号化します。 次に、このメッセージは、 HTTP/TCP/IPトンネル(3)経由で普通のHTTPポート(4)上のhost B宛に送られます。 これがhost Bに到達するとき、このパケットは、 そのトンネル経由でFEPソフトウェア(5)宛に経路制御されます。 (5)は、そのパケットをデコードし、 hostのBプロトコルスタック(6)に入れるTCP/IPデータグラムを作り出します。
このパケットは、 ファイアウォール(8)がまったく存在していなかったかのようにhost B(7)上のアプリケーション宛に経路制御されます。
host A host B
---------- ----------
| App | (1) | App | (7)
|----------| |----------|
| TCP | | TCP |
|----------| |----------|
| IP | | IP | (6)
|----------| |----------|
| FEP dvr | (2) | FEP dvr | (5)
|----------| |----------|
| TCP | | TCP |
|----------| |----------|
| IP | Firewall (8) | IP |
---------- --- -----------
| (3) | | ^ (4)
+---------------->| |-----------------------+
| |
| |
---
図1
FEPは、 両側がクライアントとサーバーのどちらにでも見えることを許容します。 各TCP/IPパケットは、HTTP GET requestとしても、あるいは、 GET requestに対するレスポンスとしても、送信されます。 この柔軟性は、 ファイアウォールを横断する妥当なHTTPコマンドを検証して、 望まないFEPパケットのinterceptingを止めることを試みるファイアウォールと共に、 うまく機能します。
この提案は、 IPv4ヘッダー情報を再現するために下記の新しいHTTPヘッダーを規定します。：
これらのオプションとしてのヘッダーは、 IPv4 [5] ヘッダーを、より良い可読性のための符号化用に使われます。 これらのフィールドは、 上記のTCPヘッダーフィールドと同様の作法で符号化されます。
base IPパケットは、既にHTTPヘッダー中にあるので、 下記のヘッダーは、オプションとしてのものです。 それらのNone／some／allは、 そのプログラマの気まぐれ(whim)に依存して使われる可能性があります。
(作業中)
Loose Source Routing option：
["Loose Source Routing", length, pointer, IP4_addr1, IP4_addr2, ...],
where length and pointer are ASCII strings representing the value of それらのフィールドs。
この提案は、 IPv6ヘッダー情報を再現するために下記の新しいHTTPヘッダーを規定します。：
これらのオプションとしてのヘッダーは、 IPv6 [5] ヘッダーを、より良い可読性(readability)のために符号化します。 これらのフィールドは、 上記TCPヘッダーフィールドと同様の作法で符号化されます。
base IPパケットは、既にHTTPヘッダー中に在るので、 下記のヘッダーは、オプションとしてのものです。 それらのNone／一部／すべては、 そのプログラマの気まぐれ(whim)に依存して使われる可能性があります。 現時点において、base IPv6ヘッダーのみがサポートされています。 十分な関心がある場合、 サポートがIPv6拡張ヘッダー用に配備されます。
(作業中)
パケットの大きさを莫大にするものともいえるようなプロトコルに直面する際に、 TCPヘッダーを圧縮することは愚かであり、それゆえ、 我々は、それを無視します。
このプロトコルはファイアウォールを扱うので、 本当のセキュリティについての考慮事項はありません。
我々は、 インターネットの成功をもたらした革新を再現するための我々の作業を支援してくださった数多くのファイアウォールベンダーに感謝したいと思います。 彼らは、 ファイアウォールが提供するセロファンの僅かな葉っぱのようなセキュリティを諦めませんでした。
Mark Gaynor
Harvard University
Cambridge MA 02138
EMail gaynor＠eecs.harvard.edu
Scott Bradner
Harvard University
Cambridge MA 02138
電話： +1 617 495 3864
EMail sob＠harvard.edu
独立行政法人 情報処理推進機構
技術本部
セキュリティセンター
(作業中)
| [1] |
Carpenter, B., "Internet Transparency", RFC 2775, 2000年2月. |
| [2] |
Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments in System Design".? 2nd International Conference on Distributed Systems, Paris, France, 1981年4月. |
| [3] |
Eastlake, D., "IP over MIME", 作業中。 |
| [4] |
Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 1981年9月. |
| [5] |
Postel, J., "Internet Protocol", STD 5, RFC 791, 1981年9月. |
| [6] |
Clark, D. and M. Blumenthal, "Rethinking the Design of the Internet: The end-to-end argument vs. the brave new world". 2000年. |
Copyright (C) The Internet Society (2001). 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.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.