Network Working Group N. Freed
Request for Comments: 2979 Sun
Category: Informational October 2000
Network Working Group N. Freed
Request for Comments: 2979 Sun
Category: Informational October 2000
Behavior of and Requirements for Internet Firewalls
Internet防火墙的行为和要求
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.
本备忘录定义了Internet防火墙的行为特征和互操作性要求。虽然这些事情中的大多数看起来很明显，但当前的防火墙行为通常是未指定或未指定的，这种缺乏特定性的情况通常会在实践中导致问题。这一要求旨在成为使防火墙的行为在各种实现中更加一致并符合公认的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.
互联网正被越来越多的关键任务应用程序所使用。因此，许多站点发现孤立的安全内部网不足以满足其需求，即使这些内部网基于并使用Internet协议。相反，他们发现有必要在有时充满敌意的互联网和处理有价值数据、提供重要服务或两者兼而有之的系统或网络之间提供直接通信路径。
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.
这种设置不可避免地引起的安全问题通常通过在Internet和内部网络之间的路径上插入一个或多个“防火墙”来解决。“防火墙”是一个代理，它以某种方式屏蔽网络流量，阻止它认为不适当、危险或两者兼而有之的流量。
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].
本文档偶尔使用大写字母表示的术语。当术语“必须”、“应该”、“不得”、“不应该”和“可能”出现大写时，它们被用来表示本规范的特殊要求。RFC 2119[2]中对这些术语的含义进行了讨论。
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) 阻止来自Internet端的数据包，这些数据包声明内部网络上系统的源地址，
(2) block TELNET or RLOGIN connections from the Internet to the internal network,
(2) 阻止从Internet到内部网络的TELNET或RLOGIN连接，
(3) block SMTP and FTP connections to the Internet from internal systems not authorized to send email or move files,
(3) 阻止未经授权发送电子邮件或移动文件的内部系统与Internet的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) 需要使用访问协商和封装协议（如SOCKS[1]）来访问Internet、内部网络或两者。
(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消息是安全漏洞的来源，因此通常在防火墙上阻止ICMP消息。这通常会为路径MTU发现造成“黑洞”[3]，导致合法应用程序流量在与通过小型MTU链接连接的系统通信时延迟或完全阻塞。
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.
根据透明规则，作为防火墙的数据包过滤路由器，允许设置了不分段（DF）位的传出IP数据包不得阻止响应出站数据包而发送的传入ICMP目的地不可到达/需要分段的错误到达防火墙内的主机，因为这将破坏生成合法流量的主机对路径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) 围绕HTTP包装一个新协议并使用端口80，因为它可能是开放的，这不是一个好主意，因为它最终会增加端口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) 如果存在防火墙穿越机制，则指定适当的防火墙穿越机制是一个好主意。
(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.
透明度规则影响安全性，因为它排除了某些简单的防火墙实现技术。因此，防火墙实现者必须更加努力地工作，以实现给定的安全级别。然而，透明度规则决不会阻止实现者实现任何必要的安全级别。此外，从长远来看，更多的前期工作会带来更好的安全性。不干扰现有服务的技术几乎肯定会比干扰和阻止人们执行有用工作的技术得到更广泛的应用。
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.
Bill Sommerfeld提供了路径MTU发现示例的文本。本文件得益于与许多人的讨论，包括但不限于：布赖恩·卡彭特、莱斯利·戴格尔、约翰·克林森、艾略特·李尔和基思·摩尔。
[1] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", RFC 1928, April, 1996.
[1] Leech，M.，Ganis，M.，Lee，Y.，Kuris，R.，Koblas，D.和L.Jones，“SOCKS协议版本5”，RFC 19281996年4月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[3] Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[4] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[4] Postel，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.，Freed，N.，Rose，M.，Stefferud，E.和D.Crocker，“SMTP服务扩展”，STD 10，RFC 18691995年11月。
Ned Freed Sun Microsystems 1050 Lakes Drive West Covina, CA 91790 USA
Ned Freed Sun Microsystems 1050 Lakes Drive West Covina，加利福尼亚州，美国91790
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: ned.freed@innosoft.com
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: 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编辑功能的资金目前由互联网协会提供。