ネットワークワーキンググループ
Request for Comments: 3093
分類: 情報提供

M. Gaynor
S. Bradner
Harvard 大学
2001年 4月 1日

ファイアウォール強化プロトコル(FEP)
(Firewall Enhancement Protocol (FEP))

English

このメモの位置付け

このメモは、インターネットコミュニティに対して情報を提供します。何らインターネット標準を規定するものではありません。本書の配布に制限はありません。

著作権表記

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 は、両世界にとって最善を実現できるようにします。:すなわち、ファイアウォールのセキュリティと、ファイアウォール経由の透過なトンネリングです。

 

1.0 用語法 English

本書中のキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、"OPTIONAL"は、RFC 2119 [1] に記述されているように解釈されるべきものです。

2.0 はじめに English

インターネットは、「まだ 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 のようなツールは、陳腐化します。

3.0 FEP プロトコル English

図 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

3.1 HTTP Method English

FEP は、両側がクライアントとサーバーのどちらにでも見えることを許容します。各 TCP/IP パケットは、HTTP GET request としても、あるいは、GET request に対するレスポンスとしても、送信されます。この柔軟性は、ファイアウォールを横断する妥当な HTTP コマンドを検証して、望まない FEP パケットの intercepting を止めることを試みるファイアウォールと共に、うまく機能します。

3.2 TCP ヘッダーのカプセル化: English

この提案は、IPv4 ヘッダー情報を再現するために下記の新しい HTTP ヘッダーを規定します。:

これらのオプションとしてのヘッダーは、IPv4 [5] ヘッダーを、より良い可読性のための符号化用に使われます。これらのフィールドは、上記の TCP ヘッダーフィールドと同様の作法で符号化されます。

base IP パケットは、既に HTTP ヘッダー中にあるので、下記のヘッダーは、オプションとしてのものです。それらの None/some/all は、そのプログラマの気まぐれ(whim)に依存して使われる可能性があります。

(作業中)

IP_value_opt
この ASCII string は、
for the 下記のフィールドs where a mandatory encoding type is not specified
その符号化 type を表現する。正規の値は、TCP_value_opt についてと同一である。
 
IP_Ver
IP バージョン番号。UTF-8 string として符号化される。この string についての正規の値は、 "four", "five", "six"である。
IP ヘッダー中のフィールドの encapsulation は、
in this section if the value is "four",
and in section 3.3 if the value is "six。
IP_Ver の値として "five" をもつヘッダーについての Encapsulations は、
the right orders are received
場合、開発される。
for ヘッダーs with the IP_Ver value of "eight"
Encapsulations は、空である。実装は、これらの文字列について、任意の native languages をサポートできなければならない(MUST)
 
IP4_Hlen
IP インターネットヘッダー長フィールド。これは、TCP_DODO と同様のやり方で符号化される。
 
IP4_Type_of_Service (この名前は、case sensitiveである)
これは、
is an obsolete name for a フィールド in the IPv4 ヘッダー,
which has been replaced with IP_$$ and IP_CU。
 
IP_$$
6-bit Differentiated Services フィールド。
encapsulated as an UTF-8 string representing the name of the DS codepoint in the フィールド。
 
IP_CU
2-bit フィールド that was the 2 low-order bits of the TOS フィールド。
このフィールドは、現在、
for experiments it has to be coded in the most general way possible
使われているので、それゆえ、
it is encoded as 2 ASCII strings of the form "bit0=X" and "bit1=X," where "X" is "on" or "off"。
「bit 0 は、MSB であること」に注意。
 
IP4_Total
16-bit 合計長フィールド。このフィールドの値を表現する ASCII string として符号化される。
 
IP4_SSN
IP 識別フィールド。このフィールドの値を表現する ASCII string として符号化される。
 
IP4_Flags
IP フラグ。
the set of 3 comma separated ASCII strings
として符号化される。 :
[{"Must Be Zero"}, {"May Fragment"|"Don't Fragment"}, {"Last Fragment"|"More Fragments"}]
 
IP4_Frager
13-bit Fragment Offset フィールド。
このフィールドの値を表現する ASCII string として符号化される。
 
IP4_TTL
8-bit Time-to-Live フィールド。
encoded as an UTF-8 string of the form "X hops to destruction"。
ここで、"X" は、
is the decimal value -1 of the フィールド。
実装は、この string について任意(arbitrary)な言語をサポートできなければなりません(MUST)
 
IP4_Proto
8-bit プロトコルフィールド。
the common name for the プロトコル whose ヘッダー follows the IP ヘッダー
を表現する UTF-8 string として符号化される。
 
IP4_Checkit
16-bit チェックサムフィールド。
TCP_Checkit と同じ方法で符号化される。
 
IP4_Apparent_Source
32-bit 発信元アドレスフィールド。
For ユーザ friendliness
this is encoded as an UTF-8 string representing the ドメイン名 of the apparent sender of the パケット。
An alternate form,
to be used when the ドメイン名自体 might be blocked by a ファイアウォール programmed to protect the innocence of the corporate ユーザs,
is an ASCII string representing the dotted quad form of the IPv4 アドレス。
 
IP4_Dest_Addr
32-bit 宛先アドレスフィールド。
is IP4_Apparent_Source
と同じ方法で符号化される。
 
IP4_Opp_Lst
A comma-separated list of all IPv4 options that are present。
各オプションは、
as an ASCII string representing the name of the option followed by option-specific 情報 enclosed in square brackets
符号化される。
Representative options and their encoding follow,
他の IP options は、
follow the same form:

End of Options option:
["End of Options"]

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。

3.3 IPv6 ヘッダーのカプセル化: English

この提案は、IPv6 ヘッダー情報を再現するために下記の新しい HTTP ヘッダーを規定します。:

これらのオプションとしてのヘッダーは、IPv6 [5] ヘッダーを、より良い可読性(readability)のために符号化します。これらのフィールドは、上記 TCP ヘッダーフィールドと同様の作法で符号化されます。

base IP パケットは、既に HTTP ヘッダー中に在るので、下記のヘッダーは、オプションとしてのものです。それらの None/一部/すべては、そのプログラマの気まぐれ(whim)に依存して使われる可能性があります。現時点において、base IPv6 ヘッダーのみがサポートされています。十分な関心がある場合、サポートが IPv6 拡張ヘッダー用に配備されます。

(作業中)

IP_$$
6-bit Differentiated Services フィールド。(上記参照)
 
IP_CU
2-bit unused フィールド。(上記参照)
 
IP6_Go_with_the_Flow
20-bit Flow Label フィールド。
このフィールドは、現在、使われていないので、
the UTF-8 string "do not care"
として符号化される必要がある。
 
IP6_PayLd
16-bit Payload 長フィールド。
the フィールド
Eの値を表現する ASCII string として符号化される。
FEP with IPv6 jumbograms
の利用は、推奨されない。
 
IP6_NxtHdr
8-bit Next ヘッダーフィールド。
IP4_Proto と同じ方法で符号化される。
 
IP6_Hopping
8-bit Hop Limit フィールド。
IP4_TTL と同じ方法で符号化される。
 
IP6_Apparent_Source
128-bit Source アドレスフィールド。
For ユーザ friendliness,
これは、
of the apparent sender of the パケット
the ドメイン名を表現する UTF-8 string として符号化される。
An alternate form,
to be used when the ドメイン名自体 might be blocked by a ファイアウォール programmed to protect the innocence of the corporate ユーザs,
is an ASCII string representing any one of the legitimate forms of representing an IPv6 アドレス。
 
IP6_Dest_Addr
128-bit 宛先(Destination)アドレスフィールド。
IP6_Apparent_Source と同じ方法で符号化される。
3.4 TCP ヘッダー圧縮 English

パケットの大きさを莫大にするものともいえるようなプロトコルに直面する際に、TCP ヘッダーを圧縮することは愚かであり、それゆえ、我々は、それを無視します。

 

4.0 セキュリティについての考慮事項 English

このプロトコルはファイアウォールを扱うので、本当のセキュリティについての考慮事項はありません。

 

5.0 謝辞 English

我々は、インターネットの成功をもたらした革新を再現するための我々の作業を支援してくださった数多くのファイアウォールベンダーに感謝したいと思います。彼らは、ファイアウォールが提供するセロファンの僅かな葉っぱのようなセキュリティを諦めませんでした。

 

6.0 著者のアドレス

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.