Network Working Group N. Freed
Request for Comments: 2979 Sun
Category: Informational October 2000
Behavior of and Requirements for
Internet Firewalls
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls. While most of these things may seem obvious, current firewall behavior is often either unspecified or underspecified and this lack of specificity often causes problems in practice. This requirement is intended to be a necessary first step in making the behavior of firewalls more consistent across implementations and in line with accepted IP protocol practices.
このメモは、インターネットファイアウォールの要件の相互運用性と行動特性を定義します。これらの事のほとんどは明白なように思えるかもしれませんが、現在のファイアウォールの動作は、多くの場合、未指定または不足のどちらかで、特異性の欠如は、多くの場合、実際に問題が発生します。この要件は、複数の実装間で一貫性と受け入れIPプロトコル慣行に沿ったファイアウォールの動作を行う際に必要な最初のステップであることを意図しています。
The Internet is being used for an increasing number of mission critical applications. Because of this many sites find isolated secure intranets insufficient for their needs, even when those intranets are based on and use Internet protocols. Instead they find it necessary to provide direct communications paths between the sometimes hostile Internet and systems or networks which either deal with valuable data, provide vital services, or both.
インターネットは、ミッションクリティカルなアプリケーションの数が増加するために使用されています。このため、多くのサイトで、これらのイントラネットは、に基づいており、インターネットプロトコルを使用している場合でも、自分のニーズには不十分孤立セキュアなイントラネットを見つけます。代わりに、彼らはそれが必要な、貴重なデータを扱う重要なサービスを提供し、またはその両方のいずれか、時には敵対的なインターネットおよびシステムやネットワークの間の直接通信パスを提供するために見つけます。
The security concerns that inevitably arise from such setups are often dealt with by inserting one or more "firewalls" on the path between the Internet and the internal network. A "firewall" is an agent which screens network traffic in some way, blocking traffic it believes to be inappropriate, dangerous, or both.
必然的に、このようなセットアップから発生するセキュリティ上の懸念は、多くの場合、インターネットと内部ネットワークの間のパス上の1つ以上の「ファイアウォール」を挿入することによって対処されています。 「ファイアウォール」は、それが、不適切な危険、またはその両方であると信じるトラフィックをブロックし、何らかの方法でネットワークトラフィックをスクリーニング薬剤です。
Note that firewall functions are disjoint from network address translation (NAT) functions -- neither implies the other, although sometimes both are provided by the same device. This document only discusses firewall functions.
ファイアウォール機能は、ネットワークアドレス変換（NAT）機能から互いに素であることに注意してください - 時々両方を同一の装置によって提供されるが、他の意味でもありません。この文書では、ファイアウォールの機能について説明します。
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in RFC 2119 [2].
このドキュメントは時折大文字で現れる用語を使用しています。ときの用語は、「MUST」、「SHOULD」、「NOT MUST」、「SHOULD NOT」、および大文字表示される「MAY」、彼らは、この仕様の特定の要件を示すために使用されています。これらの用語の意味の議論は[2] RFC 2119に表示されます。
Firewalls either act as a protocol end point and relay (e.g., a SMTP client/server or a Web proxy agent), as a packet filter, or some combination of both.
パケットフィルタ、または両方の組み合わせとしてファイアウォールプロトコルエンドポイントとして機能し、リレーのいずれか（例えば、SMTPクライアント/サーバまたはWebプロキシエージェント）。
When a firewall acts a protocol end point it may
ファイアウォールはプロトコル終点を作用した場合には、かもしれません
(1) implement a "safe" subset of the protocol,
（1）、プロトコルの「安全な」サブセットを実装
(2) perform extensive protocol validity checks,
（2）は、広範なプロトコルの妥当性チェックを実行します
(3) use an implementation methodology designed to minimize the likelihood of bugs,
（3）バグの可能性を最小限に抑えるように設計された実装方法を使用して、
(4) run in an insulated, "safe" environment, or
（4）絶縁、「安全な」環境で実行しますか、
(5) use some combination of these techniques in tandem.
（5）タンデムでのこれらの技術のいくつかの組み合わせを使用しています。
Firewalls acting as packet filters aren't visible as protocol end points. The firewall examines each packet and then
パケットフィルタとして動作するファイアウォールは、プロトコルのエンドポイントとして表示されません。ファイアウォールは、各パケットを検査し、
(1) passes the packet through to the other side unchanged,
（1）は、不変の反対側に介してパケットを渡します
(2) drops the packet entirely, or
（2）完全にパケットをドロップ、または
(3) handles the packet itself in some way.
（3）何らかの方法でパケット自体を処理します。
Firewalls typically base some of their decisions on IP source and destination addresses and port numbers. For example, firewalls may
ファイアウォールは、通常のIP送信元アドレス、宛先アドレス、およびポート番号にその決定のいくつかをベースにします。例えば、ファイアウォール月
(1) block packets from the Internet side that claim a source address of a system on the internal network,
（1）内部ネットワーク上のシステムの送信元アドレスを請求インターネット側からブロックパケットを、
(2) block TELNET or RLOGIN connections from the Internet to the internal network,
（2）ブロックTELNETまたは内部ネットワークへのインターネットからRLOGIN接続、
(3) block SMTP and FTP connections to the Internet from internal systems not authorized to send email or move files,
（3）、電子メールを送信したり、ファイルを移動するために許可されていない内部システムからインターネットにSMTPやFTP接続をブロック
(4) act as an intermediate server in handling SMTP and HTTP connections in either direction, or
（4）のいずれかの方向にSMTPおよびHTTP接続を処理中に中間サーバとして機能し、又は
(5) require the use of an access negotiation and encapsulation protocol such as SOCKS [1] to gain access to the Internet, to the internal network, or both.
（5）[1]は、内部ネットワークにインターネットへのアクセス、またはその両方を得るために、このようなSOCKSなどのアクセス交渉およびカプセル化プロトコルの使用を必要とします。
(This list of decision criteria is only intended to illustrate the sorts of factors firewalls often consider; it is by no means exhaustive, nor are all firewall products able to perform all the operations on this list.)
（判断基準のこのリストは、多くの場合、唯一の考慮要因ファイアウォールの種類を説明することを意図しています。それは、網羅されるものではない、またすべてこのリストのすべての操作を実行することができ、ファイアウォール製品です）
Applications have to continue to work properly in the presence of firewalls. This translates into the following transparency rule:
アプリケーションは、ファイアウォールの存在下で適切に動作し続けなければなりません。これは、以下の透明性規則に変換します。
The introduction of a firewall and any associated tunneling or access negotiation facilities MUST NOT cause unintended failures of legitimate and standards-compliant usage that would work were the firewall not present.
ファイアウォールと関連するトンネリングやアクセス交渉の設備の導入がうまくいく正当かつ標準準拠の用法の意図しない障害を引き起こしてはならないファイアウォールのない存在でした。
A necessary corollary to this requirement is that when such failures do occur it is incumbent on the firewall and associated software to address the problem: Changes to either implementations of existing standard protocols or the protocols themselves MUST NOT be necessary.
既存の標準プロトコルのいずれかの実装やプロトコルそのものへの変更が必要になることはいけません。この要件に必要な帰結は、このような障害が発生したとき、それは、ファイアウォールや問題に対処するために関連するソフトウェアの義務であるということです。
Note that this requirement only applies to legitimate protocol usage and gratuitous failures -- a firewall is entitled to block any sort of access that a site deems illegitimate, regardless of whether or not the attempted access is standards-compliant. This is, after all, the primary reason to have a firewall in the first place.
ファイアウォールは、アクセス試行が規格に準拠しているか否かのサイトは関係なく、非合法とみなすアクセスの任意の並べ替えを阻止する権利がある - この要件は唯一の合法的なプロトコルの使用や無償の障害に適用されることに注意してください。これは、結局、最初の場所でファイアウォールを持っている主な理由です。
Also note that it is perfectly permissible for a firewall to provide additional facilities applications can use to authenticate or authorize various sorts of connections, and for the firewall to be configurable to require the use of such facilities. The SOCKS protocol [1] is one example of such a facility. However, the firewall MUST also allow configurations where such facilities are not required for traversal.
また、それは、アプリケーションが認証または接続の様々な種類を許可するために使用できる追加機能を提供するために、ファイアウォールのために完全に許容され、およびファイアウォールのためにこのような施設の使用を必要とするように構成することに注意してください。 SOCKSプロトコル[1]は、そのような施設の一例です。しかし、ファイアウォールはまた、このような施設はトラバーサルのために必要とされていない構成を許容しなければなりません。
The following sections provide some examples of how the transparency rule actually applies to some specific protocols.
次のセクションでは、透明性のルールは、実際にいくつかの特定のプロトコルに適用する方法のいくつかの例を提供しています。
ICMP messages are commonly blocked at firewalls because of a perception that they are a source of security vulnerabilities. This often creates "black holes" for Path MTU Discovery [3], causing legitimate application traffic to be delayed or completely blocked when talking to systems connected via links with small MTUs.
ICMPメッセージは、一般的に、彼らはセキュリティ上の脆弱性の源であるため、知覚のファイアウォールでブロックされています。これは多くの場合、小さなMTUでリンクを介して接続されたシステムに話したときに遅延または完全に遮断することが正規のアプリケーショントラフィックを引き起こし、パスMTU探索のための「ブラックホール」[3]を生成します。
By the transparency rule, a packet-filtering router acting as a firewall which permits outgoing IP packets with the Don't Fragment (DF) bit set MUST NOT block incoming ICMP Destination Unreachable / Fragmentation Needed errors sent in response to the outbound packets from reaching hosts inside the firewall, as this would break the standards-compliant usage of Path MTU discovery by hosts generating legitimate traffic.
透明性規則により、パケットフィルタリングルータが到達から発信パケットに応答して送信、着信ICMP宛先到達不能/フラグメンテーション必要なエラーをブロックしてはならないDo not Fragment（DF）ビットが設定された発信IPパケットを許可するファイアウォールとして機能しますこれは、正当なトラフィックを生成するホストがパスMTUディスカバリの標準規格に準拠した使用法を破るように、ファイアウォールの内側に開催しています。
On the other hand, it's proper (albeit unfriendly) to block ICMP Echo and Echo Reply messages, since these form a different use of the network, or to block ICMP Redirect messages entirely, or to block ICMP DU/FN messages which were not sent in response to legitimate outbound traffic.
一方、ICMPエコーとエコーは、これらは、ネットワークの異なる使用を形成するため、応答メッセージ、または完全にICMPリダイレクトメッセージをブロックする、または送信されなかったICMP DU / FNメッセージをブロックするブロックする（非友好的ではあるが）適切です正当な送信トラフィックに応じてインチ
The original SMTP protocol [4] didn't provide a mechanism for negotiating protocol extensions. When this was added [5], some firewall implementations reacted by simply adding the EHLO command to the list of accepted commands. Unfortunately, this is not sufficient: What is necessary is for the firewall to scan the list of EHLO responses and only allow the ones the firewalls understands through. If this isn't done the client and server can end up agreeing to use an extension the firewalls doesn't understand, which can then lead to unnecessary protocol failures.
元のSMTPプロトコルは、[4]プロトコル拡張を交渉するためのメカニズムを提供しませんでした。これを添加した場合、[5]、いくつかのファイアウォールの実装は単に受け入れられたコマンドのリストにEHLOコマンドを添加することにより反応させました。残念ながら、これは十分ではありません：どのような必要があることは、ファイアウォールがEHLO応答のリストをスキャンし、唯一のファイアウォールが通じ理解ものをできるようにするためです。これを行わない場合、クライアントとサーバは、その後、不要なプロトコルの障害につながることができ、ファイアウォールは理解していない拡張機能を使用することに同意してしまうことができます。
Firewalls are a fact of life that application protocols must face. As such, application protocols SHOULD be designed to facilitate operation across firewalls, as long as such design choices don't adversely impact the application in other ways. In addition, application protocol specifications MAY include material defining requirements firewalls must meet to properly handle a given application protocol.
ファイアウォールは、アプリケーションプロトコルが直面しなければならないことを人生の事実です。そのため、アプリケーションプロトコルは限りこのような設計の選択肢が悪影響を他の方法でアプリケーションに影響を与えないように、ファイアウォールを越えて操作を容易にするために設計されなければなりません。また、アプリケーションプロトコルの仕様は、ファイアウォールが適切に与えられたアプリケーションプロトコルを処理するために満たさなければならない要件を定義する物質を含むことができます。
Examples of proper and improper application protocol design include:
適切および不適切なアプリケーションプロトコルの設計の例としては、
(1) Wrapping a new protocol around HTTP and using port 80 because it is likely to be open isn't a good idea, since it will eventually result in added complexity in firewall handling of port 80.
（1）それは最終的に、ポート80のファイアウォールの取り扱いに追加複雑になりますので、オープンである可能性が高いため、HTTPの周りに新しいプロトコルをラップし、ポート80を使用すると、良いアイデアではありません。
(2) Defining a secure subset of a protocol is a good idea since it simplifies the firewall design process.
それはファイアウォールの設計プロセスを簡素化するため、（2）プロトコルの安全なサブセットを定義することは良い考えです。
(3) Specificating an appropriate firewall traversal mechanism if one exists is a good idea.
（3）が存在する場合、適切なファイアウォールトラバース機構をSpecificatingことは良い考えです。
(4) Registering a separate port for new protocols is a good idea.
（4）新しいプロトコル用に別のポートを登録することをお勧めします。
Good security may occasionally result in interoperability failures between components. This is understood. However, this doesn't mean that gratuitous interoperability failures caused by security components are acceptable.
グッドセキュリティは時折コンポーネント間の相互運用性の障害をもたらすことができます。これが理解されています。ただし、これはセキュリティコンポーネントによって引き起こされる無償の相互運用性の障害が許容されていることを意味するものではありません。
The transparency rule impacts security to the extent that it precludes certain simpleminded firewall implementation techniques. Firewall implementors must therefore work a little harder to achieve a given level of security. However, the transparency rule in no way prevents an implementor from achieving whatever level of security is necessary. Moreover, a little more work up front results in better security in the long run. Techniques that do not interfere with existing services will almost certainly be more widely deployed than ones that do interfere and prevent people from performing useful work.
それは、特定のsimplemindedファイアウォール実装テクニックを排除する程度の透明性規則の影響を与えるセキュリティ。ファイアウォールの実装者は、したがって、セキュリティの特定のレベルを達成するために少し難しく働かなければなりません。しかし、決して透明性のルールが必要であるセキュリティのどんなレベルの達成から実装を防ぐことができます。また、もう少し長期的に優れたセキュリティで前の結果をアップ作業。既存のサービスに干渉しない技術は、ほぼ確実に、より広く干渉し、有用な作業を行ってから人々を防ぐないものより展開されます。
Some firewall implementors may claim that the burden of total transparency is overly onerous and that adequate security cannot be achieved in the face of such a requirement. And there is no question that meeting the transparency requirement is more difficult than not doing so.
いくつかのファイアウォールの実装は、完全な透明の負担が過度に面倒であると、十分なセキュリティは、このような要件の顔には達成できないということを請求することができます。そして、透明性の要件を満たすことがそうではないよりも困難であることに疑いはありません。
Nevertheless, it is important to remember that the only perfectly secure network is one that doesn't allow any data through at all and that the only problem with such a network is that it is unusable. Anything less is necessarily a tradeoff between usability and security. At present firewalls are being circumvented in ad hoc ways because they don't meet this transparency requirement and this necessarily weakens security dramatically. In other words, the only reason that some firewalls remain in use is because they have essentially been disabled. As such, one reason to have a transparency requirement is to IMPROVE security.
しかし、それだけで完全に安全なネットワークがまったく通って、そのようなネットワークの唯一の問題は、それが使用不可能であることであることを任意のデータを許可しないものであることを覚えておくことが重要です。小さいものは、必ずしも利便性とセキュリティの間のトレードオフです。彼らは、この透明性の要件を満たしていないと、これは必ずしも劇的にセキュリティを弱めるので、本ファイアウォールではアドホックな方法で回避されています。彼らは、本質的に無効にされているので、他の言葉では、一部のファイアウォールは使用中に残る唯一の理由です。そのため、透明性の要件を持っている一つの理由は、セキュリティを向上させることです。
Bill Sommerfeld provided the text for the Path MTU Discovery example. This document has benefited from discussions with a number of people, including but not limited to: Brian Carpenter, Leslie Daigle, John Klensin, Elliot Lear, and Keith Moore.
ビル・ゾンマーフェルトはパスMTUディスカバリー例えばテキストを提供しました。ブライアン・カーペンター、レスリーDaigle氏、ジョン・クレンシン、エリオットリア、およびキースムーア：この文書では、を含むがこれらに限定されない人々の数、との議論の恩恵を受けています。
[1] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", RFC 1928, April, 1996.
[1]リーチ、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.およびL.ジョーンズ、 "SOCKSプロトコルバージョン5"、RFC 1928、1996年4月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[3]モーグル、J.およびS.デアリング、 "経路MTUディスカバリ"、RFC 1191、1990年11月。
[4] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[4]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[5] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[5] Klensin、J.、フリード、N.、ローズ、M.、Stefferud、E.およびD.クロッカー、 "SMTPサービス拡張"、STD 10、RFC 1869、1995年11月。
Ned Freed Sun Microsystems 1050 Lakes Drive West Covina, CA 91790 USA
ネッドフリードSun Microsystemsの1050湖ドライブウェストコヴィナ、CA 91790 USA
Phone: +1 626 919 3600 Fax: +1 626 919 3614 EMail: ned.freed@innosoft.com
電話：+1 626 919 3600ファックス：+1 626 919 3614 Eメール：ned.freed@innosoft.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。