Internet Architecture Board (IAB) D. Thaler
Request for Comments: 7288 Microsoft
Category: Informational June 2014
ISSN: 2070-1721
Internet Architecture Board (IAB) D. Thaler
Request for Comments: 7288 Microsoft
Category: Informational June 2014
ISSN: 2070-1721
Reflections on Host Firewalls
关于主机防火墙的思考
Abstract
摘要
In today's Internet, the need for firewalls is generally accepted in the industry, and indeed firewalls are widely deployed in practice. Unlike traditional firewalls that protect network links, host firewalls run in end-user systems. Often the result is that software may be running and potentially consuming resources, but then communication is blocked by a host firewall. It's taken for granted that this end state is either desirable or the best that can be achieved in practice, rather than (for example) an end state where the relevant software is not running or is running in a way that would not result in unwanted communication. In this document, we explore the issues behind these assumptions and provide suggestions on improving the architecture going forward.
在今天的互联网上，业界普遍接受防火墙的需求，事实上，防火墙在实践中被广泛部署。与保护网络链接的传统防火墙不同，主机防火墙在最终用户系统中运行。通常结果是软件可能正在运行并可能消耗资源，但随后通信被主机防火墙阻止。人们想当然地认为，这种结束状态要么是理想的，要么是实践中可以实现的最佳状态，而不是（例如）相关软件未运行或以不会导致不必要通信的方式运行的结束状态。在本文档中，我们将探讨这些假设背后的问题，并提供改进架构的建议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7288.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7288.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Firewall Rules . . . . . . . . . . . . . . . . . . . . . . . 5
3. Category 1: Attack Surface Reduction . . . . . . . . . . . . 6
3.1. Discussion of Approaches . . . . . . . . . . . . . . . . 7
3.1.1. Fix the Software . . . . . . . . . . . . . . . . . . 7
3.1.2. Don't Use the Software . . . . . . . . . . . . . . . 8
3.1.3. Run the Software behind a Host Firewall . . . . . . . 8
4. Category 2: Security Policy . . . . . . . . . . . . . . . . . 9
4.1. Discussion of Approaches . . . . . . . . . . . . . . . . 9
4.1.1. Security Policies in Applications . . . . . . . . . . 9
4.1.2. Security Policies in Host Firewalls . . . . . . . . . 9
4.1.3. Security Policies in a Service . . . . . . . . . . . 10
5. Stealth Mode . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. IAB Members at the Time of Approval . . . . . . . . . . . . . 12
9. Informative References . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Firewall Rules . . . . . . . . . . . . . . . . . . . . . . . 5
3. Category 1: Attack Surface Reduction . . . . . . . . . . . . 6
3.1. Discussion of Approaches . . . . . . . . . . . . . . . . 7
3.1.1. Fix the Software . . . . . . . . . . . . . . . . . . 7
3.1.2. Don't Use the Software . . . . . . . . . . . . . . . 8
3.1.3. Run the Software behind a Host Firewall . . . . . . . 8
4. Category 2: Security Policy . . . . . . . . . . . . . . . . . 9
4.1. Discussion of Approaches . . . . . . . . . . . . . . . . 9
4.1.1. Security Policies in Applications . . . . . . . . . . 9
4.1.2. Security Policies in Host Firewalls . . . . . . . . . 9
4.1.3. Security Policies in a Service . . . . . . . . . . . 10
5. Stealth Mode . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. IAB Members at the Time of Approval . . . . . . . . . . . . . 12
9. Informative References . . . . . . . . . . . . . . . . . . . 12
[BLOCK-FILTER] discusses the issue of blocking or filtering abusive or objectionable content and communications, and the effects on the overall Internet architecture. This document complements that discussion by focusing on the architectural effects of host firewalls on hosts and applications.
[BLOCK-FILTER]讨论阻止或过滤滥用或不良内容和通信的问题，以及对整个互联网架构的影响。本文档通过关注主机防火墙对主机和应用程序的体系结构影响来补充这一讨论。
"Behavior of and Requirements for Internet Firewalls" [RFC2979] provides an introduction to firewalls and the requirement for transparency in particular, stating:
“互联网防火墙的行为和要求”[RFC2979]介绍了防火墙，特别是透明度要求，说明：
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.
防火墙和任何相关的隧道或访问协商设施的引入不得导致合法和符合标准的使用出现意外故障，如果防火墙不存在，这些故障将起作用。
Many firewalls today do not follow that guidance, such as by blocking traffic containing IP options or IPv6 extension headers (see [RFC7045] for more discussion).
今天的许多防火墙并不遵循这一指导，例如通过阻止包含IP选项或IPv6扩展头的流量（有关更多讨论，请参阅[RFC7045]）。
In Section 2.1 of "Reflections on Internet Transparency" [RFC4924], the IAB provided additional thoughts on firewalls and their impact on the Internet architecture, including issues around disclosure obligations and complexity as applications evolve to circumvent firewalls. This document extends that discussion with additional considerations.
在“关于互联网透明度的思考”[RFC4924]的第2.1节中，IAB提供了关于防火墙及其对互联网体系结构的影响的其他想法，包括围绕披露义务和复杂性的问题，随着应用程序不断发展以规避防火墙。本文件对这一讨论作了进一步的考虑。
Traditionally, firewalls have been about arming customers to protect against bugs in applications and services. This document discusses a number of fundamental questions, such as who a firewall is meant to protect from what. It does so primarily, though not exclusively, from an end system perspective with a focus on host firewalls in particular.
传统上，防火墙一直致力于武装客户，防止应用程序和服务中出现漏洞。本文档讨论了一些基本问题，例如防火墙应该保护谁不受什么影响。它主要是从终端系统的角度来实现这一点的，但不是唯一的，它特别关注主机防火墙。
While the Internet Security Glossary [RFC4949] contains an extended definition of a firewall, informally, most people would tend to think of a firewall as simply "something that blocks unwanted traffic" (see [RFC4948] for a discussion on many types of unwanted traffic). A fundamental question is, however: "unwanted by whom?"
虽然互联网安全术语表[RFC4949]包含了防火墙的扩展定义，但大多数人通常认为防火墙只是“阻止不需要的流量的东西”（有关许多类型的不需要的流量的讨论，请参见[RFC4948]）。然而，一个基本问题是：“谁不想要？”
Possible answers include end users, application developers, network administrators, host administrators, firewall vendors, and content providers. We will exclude by definition the sender of the traffic in question, since the sender would generally want such traffic to be delivered. Still, the other entities have different, and often conflicting, desires which means that a type of traffic might be
可能的答案包括最终用户、应用程序开发人员、网络管理员、主机管理员、防火墙供应商和内容提供商。我们将根据定义排除相关流量的发送方，因为发送方通常希望交付此类流量。尽管如此，其他实体有着不同的，并且经常是相互冲突的愿望，这意味着一种类型的通信可能是
wanted by one entity and unwanted by another entity. Thus, not surprisingly, there exist various types of firewalls, and various types of "arms race" as we will discuss in Section 4.1.2.
一个实体需要而另一个实体不需要。因此，正如我们将在第4.1.2节中讨论的，存在各种类型的防火墙和各种类型的“军备竞赛”，这一点并不奇怪。
In this document we distinguish between a "host firewall", which simply intends to protect the single computer on which it runs, and a "network firewall", which is located in the network and intends to protect the network and any hosts behind it.
在本文档中，我们区分了“主机防火墙”和“网络防火墙”，前者仅用于保护其运行的单台计算机，后者位于网络中，用于保护网络及其背后的任何主机。
A Network Address Translator (NAT) is also often viewed, or even marketed, as a type of network firewall; Section 2.2 of [RFC4864] addresses this misconception, but nevertheless some of the same observations in the present document may also apply to NATs.
网络地址转换器（NAT）也经常被视为网络防火墙的一种类型，甚至在市场上销售；[RFC4864]第2.2节阐述了这一误解，但本文件中的一些相同意见也可能适用于NAT。
Sandboxed environments, such as those provided by browsers, can also be thought of as a type of host firewall in the more general sense. For example, a cross-site check in a browser can be thought of as a mechanism to block unwanted outbound traffic per a "same origin policy" where a script can only communicate with the "site" from which the script was obtained, for some definition of site such as the scheme and authority in a URI.
沙盒环境，如浏览器提供的环境，也可以被认为是更一般意义上的主机防火墙类型。例如，可以将浏览器中的跨站点检查视为根据“同源策略”阻止不需要的出站流量的机制，其中脚本只能与从中获取脚本的“站点”进行通信，用于某些站点定义，例如URI中的方案和权限。
The term "application" is used in this document generically to apply to any component that can receive traffic. In this sense, it could refer to a process running on a computer (including a system service) or even to a portion of a TCP/IP stack itself, such as a component that responds to pings.
本文档中的术语“应用程序”一般适用于可接收流量的任何组件。从这个意义上讲，它可以指在计算机上运行的进程（包括系统服务），甚至指TCP/IP堆栈本身的一部分，例如响应ping的组件。
Desires for wanted or unwanted traffic can be expressed in terms of "allow" vs. "block" rules, with some way to resolve conflicting rules. Many firewalls are actually implemented in terms of such rules. Figure 1 shows some typical sources of such rules.
对想要的或不想要的流量的渴望可以用“允许”与“阻止”规则来表达，并通过某种方式来解决冲突规则。许多防火墙实际上是根据这些规则实现的。图1显示了此类规则的一些典型来源。
Source | Consumer | Consumer | Enterprise | Enterprise
| Scenario | Scenario | Scenario | Scenario
| Host | Network | Host | Network
| Firewall | Firewall | Firewall | Firewall
----------+------------+-------------+------------+------------
End user | Sometimes | Sometimes | |
| (as host | (as network | |
| admin) | admin) | |
----------+------------+-------------+------------+------------
App | Yes | Sometimes | |
developer | | (via | |
| | protocols) | |
----------+------------+-------------+------------+------------
Network | | Sometimes | | Yes
admin | | | |
----------+------------+-------------+------------+------------
Host | Sometimes | | Yes |
admin | | | |
----------+------------+-------------+------------+------------
Firewall | Yes | Yes | Yes | Yes
vendor | | | |
----------+------------+-------------+------------+------------
Source | Consumer | Consumer | Enterprise | Enterprise
| Scenario | Scenario | Scenario | Scenario
| Host | Network | Host | Network
| Firewall | Firewall | Firewall | Firewall
----------+------------+-------------+------------+------------
End user | Sometimes | Sometimes | |
| (as host | (as network | |
| admin) | admin) | |
----------+------------+-------------+------------+------------
App | Yes | Sometimes | |
developer | | (via | |
| | protocols) | |
----------+------------+-------------+------------+------------
Network | | Sometimes | | Yes
admin | | | |
----------+------------+-------------+------------+------------
Host | Sometimes | | Yes |
admin | | | |
----------+------------+-------------+------------+------------
Firewall | Yes | Yes | Yes | Yes
vendor | | | |
----------+------------+-------------+------------+------------
Figure 1: Common Sources of Firewall Rules
图1：防火墙规则的常见来源
Figure 1 assumes that network firewalls are administered by network administrators (if any), and host firewalls are administered by host administrators (if any). A firewall may also have rules provided by the firewall vendor itself.
图1假设网络防火墙由网络管理员（如果有）管理，主机防火墙由主机管理员（如果有）管理。防火墙也可能有防火墙供应商自己提供的规则。
End users typically cannot directly provide rules to firewalls that affect other users, unless the end user is a host or network administrator. Application developers can, however, provide such rules to some firewalls, such as providing rules at installation time. They can do this, for example, by invoking an API provided by a host firewall included with the operating system, or by providing metadata to the operating system for use by firewalls, or by using a protocol such as Universal Plug and Play (UPnP) [UPNPWANIP] or the Port Control Protocol (PCP) [RFC6887] to communicate with a network firewall (see Section 4.1.3 for a longer discussion).
最终用户通常不能直接向影响其他用户的防火墙提供规则，除非最终用户是主机或网络管理员。但是，应用程序开发人员可以向某些防火墙提供此类规则，例如在安装时提供规则。他们可以这样做，例如，通过调用操作系统中包含的主机防火墙提供的API，或者通过向操作系统提供元数据供防火墙使用，或者通过使用诸如通用即插即用（UPnP）[UPNPWANIP]或端口控制协议（PCP）[RFC6887]之类的协议与网络防火墙通信（有关详细讨论，请参见第4.1.3节）。
Firewall rules generally fall into two categories:
防火墙规则通常分为两类：
1. Attack surface reduction: Rules intended to prevent an application from doing things the developer does not want it to do.
1. 减少攻击面：旨在防止应用程序做开发人员不希望它做的事情的规则。
2. Security policy: Rules intended to prevent an application from doing things the developer might want it to do, but an administrator does not.
2. 安全策略：旨在阻止应用程序执行开发人员可能希望它执行但管理员不希望执行的操作的规则。
A firewall is unnecessary if both categories are empty. We will now treat each category in turn, focusing specifically on host firewalls (although some points might be equally applicable to network firewalls).
如果两个类别都为空，则不需要防火墙。现在，我们将依次处理每个类别，特别关注主机防火墙（尽管有些要点可能同样适用于网络防火墙）。
As noted above, this category of firewall rule typically attempts to prevent applications from doing things the developer did not intend.
如上所述，这类防火墙规则通常试图阻止应用程序做开发人员不想做的事情。
One might ask whether this category of rules is typically empty, and the answer is that it is not, at present. One reason stems from mitigating the threat of vulnerability exploitation by putting a security barrier in a separate process, isolated from the potentially compromised process. Furthermore, there is also some desire for a "stealth mode" (see Section 5 below).
有人可能会问，这类规则是否通常是空的，答案是，目前不是。其中一个原因是，通过在一个单独的流程中设置安全屏障来减轻漏洞攻击的威胁，该流程与可能受到危害的流程相隔离。此外，还有一些对“隐形模式”的渴望（见下文第5节）。
Hence, typically a firewall will have rules to block everything by default. A one-time, privileged, application-install step adds one or more Allow rules, and then normal (unprivileged) application execution is then constrained by the resulting rules.
因此，通常情况下，防火墙会有规则在默认情况下阻止一切。一次性、有特权的应用程序安装步骤添加一个或多个允许规则，然后正常（无特权）的应用程序执行会受到结果规则的约束。
A second reason this category of rules is non-empty is where they are used as workarounds for cases the application developer found too onerous to implement. These cases include:
这类规则非空的第二个原因是它们被用作解决应用程序开发人员发现过于繁重而无法实现的情况的变通方法。这些个案包括：
1. Simple policies that the developer would want but that are difficult to implement. One example might be a policy that an application should communicate only within the local network (e.g., a home or enterprise), but not be reachable from the global Internet or while the device is moved to some public network such as a hotspot. A second example might be the reverse, i.e., a policy to communicate over the Internet but not with local entities. The need for this category would be reduced by better platform support for such policies, making them easier for developers to implement and use.
1. 开发人员想要但难以实现的简单策略。一个示例可能是这样一种策略，即应用程序应仅在本地网络（例如，家庭或企业）内通信，但不能从全球互联网或当设备移动到某个公共网络（例如热点）时访问。第二个例子可能是相反的，即通过互联网进行通信但不与本地实体进行通信的策略。对此类策略的更好平台支持将减少对此类策略的需求，使开发人员更容易实施和使用这些策略。
2. Complex policies where the developer cannot possibly be aware of specifics. One example might be a policy to communicate only during, or only outside of, normal business hours, where the exact hours may vary by location and time of year. Another example might be a policy to avoid communication over links that cost too much, where the definition of "too much" may vary by customer, and indeed, the end host and application might not even be aware of the costs. The need for this category would be reduced by better platform support for such policies, allowing the application to communicate through some simple API with some other library or service that can deal with the specifics.
2. 复杂的策略，开发人员不可能知道具体情况。一个例子可能是仅在正常工作时间内或正常工作时间以外进行沟通的政策，其中确切的时间可能因地点和时间而异。另一个例子可能是一种避免通过成本过高的链路进行通信的策略，其中“过高”的定义可能因客户而异，实际上，终端主机和应用程序甚至可能不知道成本。通过更好的平台对此类策略的支持，允许应用程序通过一些简单的API与能够处理细节的其他库或服务进行通信，可以减少对此类策略的需求。
When running an application would result in unwanted behavior, customers have three choices, which we will discuss in turn:
当运行应用程序会导致不必要的行为时，客户有三种选择，我们将依次讨论：
a. fix (or get the developer to fix) the software,
a. 修复（或让开发人员修复）软件，
b. not use the software, or
b. 不使用该软件，或
c. let the software run, but then use a firewall to thwart it and prevent it from working in unwanted ways.
c. 让软件运行，然后使用防火墙阻止它，防止它以不必要的方式工作。
Firewall vendors point out that one can more quickly and reliably update firewall rules than application software. Indeed, some applications might have no way to update them, and support for other applications might no longer be available (e.g., if the developers are no longer around). Most modern operating systems (and any applications that come with them) have automatic updates, as do some independent applications. But until all applications have automatic updates, and automatic updates are actually used, it will still be the case that firewall rules can be updated more quickly than software patches. Furthermore, in some contexts (e.g., within some enterprises), a possibly lengthy retesting and recertification process must be employed before applications can be updated.
防火墙供应商指出，与应用软件相比，更新防火墙规则更快速、更可靠。事实上，一些应用程序可能无法更新它们，并且对其他应用程序的支持可能不再可用（例如，如果开发人员不再在场）。大多数现代操作系统（及其附带的任何应用程序）都有自动更新，一些独立的应用程序也是如此。但是，在所有应用程序都有自动更新并且实际使用自动更新之前，防火墙规则的更新速度仍然比软件补丁更快。此外，在某些情况下（例如，在某些企业内），在更新应用程序之前，必须采用可能很长的重新测试和重新认证过程。
In short, mechanisms to encourage and ease the use of secure automatic software updates are important and would greatly reduce overall complexity. Such mechanisms should allow scheduling updates at appropriate times, taking into account operational considerations such as dependencies, compatibility, testing and maintenance windows.
简言之，鼓励和简化使用安全自动软件更新的机制非常重要，将大大降低总体复杂性。此类机制应允许在适当的时间安排更新，同时考虑到操作方面的考虑，如依赖性、兼容性、测试和维护窗口。
A key question to ask is whether the application could still do something useful when firewalled. If the answer is yes, then not using the software is probably unrealistic. For example, a game with both single-player and multi-player capabilities could still be useful in single-player mode when firewalled. If instead the answer is no, it is better to not allow the application to run in the first place, and some host firewalls can indeed block applications from running.
要问的一个关键问题是，应用程序在防火墙上是否仍然可以做一些有用的事情。如果答案是肯定的，那么不使用该软件可能是不现实的。例如，一个同时具有单人和多人功能的游戏在单人模式下进行防火墙攻击时仍然很有用。如果答案是否定的，那么最好首先不要让应用程序运行，而且某些主机防火墙确实会阻止应用程序运行。
As noted earlier, one disadvantage of this approach is that resources still get consumed. For example, the application can still consume memory, CPU, bandwidth (up to the point of blockage), ports in the transport layer protocol, and possibly other resources depending on the application, for operations that provide no benefit while firewalled.
如前所述，这种方法的一个缺点是资源仍然会被消耗。例如，应用程序仍然可以使用内存、CPU、带宽（直到阻塞点）、传输层协议中的端口，以及可能的其他资源（取决于应用程序），这些操作在防火墙时不会带来任何好处。
A second important disadvantage of this approach is the bad user experience. Typically the application and the end-user won't know why the application doesn't work. A poorly designed application might not cope well and consume even more resources (e.g., retrying an operation that continually fails).
这种方法的第二个重要缺点是糟糕的用户体验。通常，应用程序和最终用户都不知道为什么应用程序不能工作。设计糟糕的应用程序可能无法很好地处理，并消耗更多的资源（例如，重试一个不断失败的操作）。
A third disadvantage is that it is common for a firewall rule to block more that is appropriate for attack surface reduction, impacting protocol operation and even having adverse effects on other endpoints. For example, some firewalls that cannot perform full deep packet inspection at line speed have adopted a block by default approach to anything they don't understand from the first few bytes; this is very harmful to innovation as it interferes with the ability to deploy new protocols and features.
第三个缺点是，防火墙规则通常会阻止更多适合于减少攻击面的内容，从而影响协议操作，甚至对其他端点产生不利影响。例如，一些不能以线路速度执行全深度数据包检查的防火墙在默认情况下采用了块方法来处理前几个字节中不理解的任何内容；这对创新非常有害，因为它干扰了部署新协议和功能的能力。
As another example, blocking ICMP adversely affects path MTU discovery which can cause problems for other entities (see [RFC4890] and Section 3.1.1 of [RFC2979] for further discussion). This can happen due to lack of understanding all the details of application behavior, or due to accidental misconfiguration. Section 2.1 of [RFC5505] states, "Anything that can be configured can be misconfigured," and discusses this in more detail.
另一个例子是，阻塞ICMP会对路径MTU发现产生不利影响，这可能会给其他实体带来问题（有关进一步讨论，请参见[RFC4890]和[RFC2979]第3.1.1节）。这可能是由于不了解应用程序行为的所有细节，或者由于意外的错误配置。[RFC5505]第2.1节指出，“任何可以配置的都可能配置错误”，并对此进行了更详细的讨论。
In short, it is important to make applications more aware of the constraints of their environment, and hence better able to behave well when constrained.
简言之，重要的是让应用程序更加了解其环境的约束，从而更好地在受到约束时表现良好。
As noted in Section 2, this category of firewall rule typically attempts to prevent an application from doing things an administrator does not want them to do, even if the application developer did.
如第2节所述，这类防火墙规则通常试图阻止应用程序做管理员不希望他们做的事情，即使应用程序开发人员做了。
One might ask whether this category of rules is typically empty, and the answer varies somewhat. For enterprise-scenario firewalls, it is almost never empty, and hence the problems discussed in Section 3.1.3 can be common here too. Similarly, for consumer-scenario firewalls, it is generally not empty but there are some notable exceptions. For example, for the host firewall in some operation systems, this category always starts empty and most users never change this.
有人可能会问，这类规则是否通常是空的，答案有所不同。对于企业场景防火墙，它几乎从不为空，因此第3.1.3节中讨论的问题在这里也很常见。类似地，对于消费场景防火墙，它通常不是空的，但也有一些明显的例外。例如，对于某些操作系统中的主机防火墙，此类别总是以空开头，并且大多数用户从不更改此类别。
Security policy can be implemented in any of three places, which we will discuss in turn: the application, a firewall, or a library/ service that the application explicitly uses.
安全策略可以在三个地方中的任何一个实现，我们将依次讨论：应用程序、防火墙或应用程序显式使用的库/服务。
In this option, each application must implement support for potentially complex security policies, along with ways for administrators to configure them. Although the explicit interaction with applications avoids the problems discussed in Section 3.1.3, this approach is impractical for a number of reasons. First, the complexity makes it difficult to implement and is error-prone, especially for application developers whose primary expertise is not networking. Second, the potentially large number of applications (and application developers) results in an inconsistent experience that makes it difficult for an administrator to manage common policies across applications, thus driving up training and operational costs.
在此选项中，每个应用程序必须实现对潜在复杂安全策略的支持，以及管理员配置这些策略的方法。尽管与应用程序的显式交互避免了第3.1.3节中讨论的问题，但由于许多原因，这种方法是不切实际的。首先，复杂性使其难以实现，并且容易出错，特别是对于主要专业知识不是网络的应用程序开发人员。其次，潜在的大量应用程序（和应用程序开发人员）会导致不一致的体验，这使得管理员很难跨应用程序管理通用策略，从而推高培训和运营成本。
Putting security policies in firewalls without explicit interaction with the applications results in the problems discussed in Section 3.1.3. In addition, this leads to "arms races" where the applications are incented to evolve to get around the security policies, since the desires of the end user or developer can conflict with the desires of an administrator. As stated in Section 2.1 of [RFC4924]:
在防火墙中放置安全策略而不与应用程序进行显式交互会导致第3.1.3节中讨论的问题。此外，这导致了“军备竞赛”，因为最终用户或开发人员的愿望可能与管理员的愿望相冲突，因此，应用程序被鼓励进化以绕过安全策略。如[RFC4924]第2.1节所述：
In practice, filtering intended to block or restrict application usage is difficult to successfully implement without customer consent, since over time developers will tend to re-engineer
实际上，未经客户同意，旨在阻止或限制应用程序使用的过滤很难成功实施，因为随着时间的推移，开发人员将倾向于重新设计
filtered protocols so as to avoid the filters. Thus, over time, filtering is likely to result in interoperability issues or unnecessary complexity. These costs come without the benefit of effective filtering since many application protocols began to use HTTP as a transport protocol after application developers observed that firewalls allow HTTP traffic while dropping packets for unknown protocols.
过滤协议，以避免过滤器。因此，随着时间的推移，过滤可能会导致互操作性问题或不必要的复杂性。由于应用程序开发人员发现防火墙允许HTTP通信，同时丢弃未知协议的数据包，因此许多应用程序协议开始使用HTTP作为传输协议，因此这些成本没有得到有效过滤的好处。
Such arms races stem from inherent tussles between the desires of different entities. For example, the tussle between end-user desires and administrator desires leads to an arms race between firewalls and deep packet inspection on the one hand, vs. the use of obfuscation or tunnels on the other.
这种军备竞赛源于不同实体的欲望之间固有的争斗。例如，最终用户需求和管理员需求之间的争斗一方面导致防火墙和深度数据包检查之间的军备竞赛，另一方面导致模糊处理或隧道的使用。
Although such arms races are often thought of in the context of network firewalls, they also occur with host firewalls. It is, however, generally easier for a host firewall to overcome, since it may be more practical for a host firewall to establish some form of trust between the policy-desiring entities, and have a trusted arbiter.
虽然这种军备竞赛通常被认为是在网络防火墙的背景下进行的，但它们也会发生在主机防火墙上。然而，主机防火墙通常更容易克服，因为主机防火墙可能更实际地在需要策略的实体之间建立某种形式的信任，并具有受信任的仲裁器。
In this approach, applications use a library or other external service whereby the applications have explicit knowledge of the impact of the security policies in order to avoid the problems in Section 3.1.3, and in a sandboxed environment, this might be the application's only way to interact with the network.
在这种方法中，应用程序使用库或其他外部服务，从而应用程序明确了解安全策略的影响，以避免第3.1.3节中的问题，在沙盒环境中，这可能是应用程序与网络交互的唯一方式。
Thus, in this opt-in approach, applications provide a description of the network access requested, and the library/service can ensure that applications and/or users are informed in a way they can understand and that administrators can craft policy that affects the applications.
因此，在这种选择加入方法中，应用程序提供所请求的网络访问的描述，并且库/服务可以确保以应用程序和/或用户能够理解的方式通知应用程序和/或用户，并且管理员可以制定影响应用程序的策略。
This approach is very difficult to do in a firewall-vendor-specific library/service when there can be multiple firewall implementations (including ones in the middle of the network), since it is usually impractical for an application developer to know about and develop for many different firewall APIs. It is, however, possible to employ this approach with a firewall-vendor-agnostic library/service that can communicate with both applications and firewalls. Thus, application developers and firewall developers can use a common platform.
这种方法在防火墙供应商特定的库/服务中是非常困难的，当存在多个防火墙实现时（包括在网络中间的），因为应用程序开发人员对于许多不同的防火墙API都知道和开发通常是不切实际的。但是，可以将此方法与防火墙供应商无关的库/服务结合使用，该库/服务可以与应用程序和防火墙进行通信。因此，应用程序开发人员和防火墙开发人员可以使用通用平台。
We observe that this approach is very different from the classic firewall approach. It is, however the approach used by some host operating system firewalls, and it is also the approach used by PCP in the IETF. As such, we encourage the deployment and use of this model.
我们观察到，这种方法与经典的防火墙方法非常不同。然而，这是一些主机操作系统防火墙使用的方法，也是IETF中PCP使用的方法。因此，我们鼓励部署和使用此模型。
Furthermore, while this approach lessens the incentive for arms races as discussed above, one important issue still remains. Namely, there is no standard mechanism today for a library/service to learn complex policies from the network. Further work in this area is needed.
此外，尽管这一办法减少了上文所讨论的军备竞赛的动机，但仍然存在一个重要问题。也就是说，现在没有标准的机制让图书馆/服务从网络学习复杂的策略。这方面还需要进一步的工作。
There is often a desire to hide from address and port scans on a public network. However, compliance to many RFCs requires responding to various messages. For example, TCP [RFC0793] compliance requires sending a RST in response to a SYN when there is no listener, and ICMPv6 [RFC4443] compliance requires sending an Echo Reply in response to an Echo Request.
人们通常希望在公共网络上隐藏地址和端口扫描。然而，遵守许多RFC要求响应各种消息。例如，TCP[RFC0793]合规性要求在没有侦听器时发送RST以响应SYN，ICMPv6[RFC4443]合规性要求发送回显回复以响应回显请求。
Firewall rules can allow such stealth without changing the statement of compliance of the basic protocols. However, stealth mode could instead be implemented as a configurable option used by the applications themselves. For example, rather than a firewall rule to drop a certain outbound message after an application generates it, fewer resources would be consumed if the application knew not to generate it in the first place.
防火墙规则可以在不改变基本协议合规性声明的情况下实现这种隐蔽性。但是，隐形模式可以作为应用程序本身使用的可配置选项来实现。例如，与在应用程序生成某个出站消息后删除该消息的防火墙规则不同，如果应用程序一开始就知道不生成该消息，将消耗更少的资源。
There is a common misconception that firewalls protect users from malware on their computer, when in fact firewalls protect users from buggy software. There is some concern that firewalls give users a false sense of security; firewalls are not invulnerable and will not prevent malware from running if the user allows it.
有一种常见的误解，即防火墙保护用户免受计算机上的恶意软件的侵害，而实际上防火墙保护用户免受有缺陷软件的侵害。有人担心防火墙会给用户一种错误的安全感；防火墙并非无懈可击，如果用户允许，也不会阻止恶意软件运行。
This document has focused primarily on host firewalls. For additional discussion (focused more on network firewalls) see [RFC2979] and [BLOCK-FILTER].
本文档主要关注主机防火墙。有关更多讨论（更多关注网络防火墙），请参阅[RFC2979]和[BLOCK-FILTER]。
Stuart Cheshire provided the motivation for this document by asking the thought-provoking question of why one would want to firewall an application rather than simply stop running it. The ensuing discussion, and subsequent IAB tech chat in November 2011, led to this document. Dan Simon, Stephen Bensley, Gerardo Diaz Cuellar, Brian Carpenter, and Paul Hoffman also provided helpful suggestions.
Stuart Cheshire提出了一个发人深省的问题，即为什么要对应用程序设置防火墙，而不是简单地停止运行应用程序，从而为本文提供了动机。随后的讨论，以及随后于2011年11月举行的IAB技术聊天，形成了本文件。Dan Simon、Stephen Bensley、Gerardo Diaz Cuellar、Brian Carpenter和Paul Hoffman也提供了有益的建议。
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Joel Halpern Russ Housley Eliot Lear Xing Li Erik Nordmark Andrew Sullivan Dave Thaler Hannes Tschofenig
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Joel Halpern Russ Housley Eliot Lear Xing Li Erik Nordmark Andrew Sullivan Dave Thaler Hannes Tschofenig
[BLOCK-FILTER] Barnes, R., Cooper, A., and O. Kolkman, "Technical Considerations for Internet Service Blocking and Filtering", Work in Progress, January 2014.
[BLOCK-FILTER]Barnes，R.，Cooper，A.，和O.Kolkman，“互联网服务阻塞和过滤的技术考虑”，正在进行的工作，2014年1月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979]弗里德，N.，“互联网防火墙的行为和要求”，RFC 2979，2000年10月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，RFC 4864，2007年5月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890]Davies，E.和J.Mohacsi，“防火墙中过滤ICMPv6消息的建议”，RFC 48902007年5月。
[RFC4924] Aboba, B. and E. Davies, "Reflections on Internet Transparency", RFC 4924, July 2007.
[RFC4924]Aboba，B.和E.Davies，“关于互联网透明度的思考”，RFC 49242007年7月。
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007.
[RFC4948]Andersson，L.，Davies，E.，和L.Zhang，“IAB 2006年3月9日至10日不必要交通研讨会报告”，RFC 4948，2007年8月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RFC5505] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, "Principles of Internet Host Configuration", RFC 5505, May 2009.
[RFC5505]Aboba，B.，Thaler，D.，Andersson，L.，和S.Cheshire，“互联网主机配置原则”，RFC 5505，2009年5月。
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC6887]南柴郡Wing，D.，布卡达尔，M.，佩诺，R.，和P.Selkirk，“港口控制协议（PCP）”，RFC 6887，2013年4月。
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, December 2013.
[RFC7045]Carpenter，B.和S.Jiang，“IPv6扩展头的传输和处理”，RFC 70452013年12月。
[UPNPWANIP] UPnP Forum, "WANIPConnection:2 Service", September 2010, <http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v2-Service.pdf>.
[UPNPWANIP]UPnP论坛，“WANIConnect:2服务”，2010年9月<http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v2-Service.pdf>。
Author's Address
作者地址
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Dave Thaler微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com