diff options
Diffstat (limited to 'doc/rfc/rfc7288.txt')
| -rw-r--r-- | doc/rfc/rfc7288.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc7288.txt b/doc/rfc/rfc7288.txt new file mode 100644 index 0000000..b4f9d11 --- /dev/null +++ b/doc/rfc/rfc7288.txt @@ -0,0 +1,731 @@ + + + + + + +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. + + 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. + + + + + + + + + + + + + +Thaler Informational [Page 1] + +RFC 7288 Host Firewalls June 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + +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 + + + + + + + + + + + + + + + + + + + +Thaler Informational [Page 2] + +RFC 7288 Host Firewalls June 2014 + + +1. Introduction + + [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. + + "Behavior of and Requirements for Internet Firewalls" [RFC2979] + provides an introduction to firewalls and the requirement for + transparency in particular, stating: + + 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). + + 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. + + 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?" + + 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 + + + + +Thaler Informational [Page 3] + +RFC 7288 Host Firewalls June 2014 + + + 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. + +1.1. Terminology + + 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. + + 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. + + 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. + + + + + + + + + + + + + + + + + + + + + + +Thaler Informational [Page 4] + +RFC 7288 Host Firewalls June 2014 + + +2. Firewall Rules + + 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. + + 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 + + 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. + + 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). + + + + +Thaler Informational [Page 5] + +RFC 7288 Host Firewalls June 2014 + + + 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. + + 2. Security policy: Rules intended to prevent an application from + doing things the developer might want it to do, but an + administrator does not. + + 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). + +3. Category 1: Attack Surface Reduction + + 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). + + 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. + + + + + +Thaler Informational [Page 6] + +RFC 7288 Host Firewalls June 2014 + + + 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. + +3.1. Discussion of Approaches + + 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, + + b. not use the software, or + + c. let the software run, but then use a firewall to thwart it and + prevent it from working in unwanted ways. + +3.1.1. Fix the Software + + 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. + + + + + + + +Thaler Informational [Page 7] + +RFC 7288 Host Firewalls June 2014 + + +3.1.2. Don't Use the Software + + 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. + +3.1.3. Run the Software behind a Host Firewall + + 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. + + 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. + + 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. + + + + + +Thaler Informational [Page 8] + +RFC 7288 Host Firewalls June 2014 + + +4. Category 2: Security Policy + + 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. + + 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. + +4.1. Discussion of Approaches + + 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. + +4.1.1. Security Policies in Applications + + 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. + +4.1.2. Security Policies in Host Firewalls + + 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]: + + 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 + + + +Thaler Informational [Page 9] + +RFC 7288 Host Firewalls June 2014 + + + 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. + + 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. + +4.1.3. Security Policies in a Service + + 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. + + 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. + + + + + + + +Thaler Informational [Page 10] + +RFC 7288 Host Firewalls June 2014 + + + 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. + + 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. + +5. Stealth Mode + + 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. + + 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. + +6. Security Considerations + + 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]. + +7. Acknowledgements + + 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. + + + +Thaler Informational [Page 11] + +RFC 7288 Host Firewalls June 2014 + + +8. IAB Members at the Time of Approval + + 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 + +9. Informative References + + [BLOCK-FILTER] + Barnes, R., Cooper, A., and O. Kolkman, "Technical + Considerations for Internet Service Blocking and + Filtering", Work in Progress, January 2014. + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC2979] Freed, N., "Behavior of and Requirements for Internet + Firewalls", RFC 2979, October 2000. + + [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. + + [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and + E. Klein, "Local Network Protection for IPv6", RFC 4864, + May 2007. + + [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering + ICMPv6 Messages in Firewalls", RFC 4890, May 2007. + + [RFC4924] Aboba, B. and E. Davies, "Reflections on Internet + Transparency", RFC 4924, July 2007. + + [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the + IAB workshop on Unwanted Traffic March 9-10, 2006", RFC + 4948, August 2007. + + + + + +Thaler Informational [Page 12] + +RFC 7288 Host Firewalls June 2014 + + + [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC + 4949, August 2007. + + [RFC5505] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, + "Principles of Internet Host Configuration", RFC 5505, May + 2009. + + [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. + Selkirk, "Port Control Protocol (PCP)", RFC 6887, April + 2013. + + [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing + of IPv6 Extension Headers", RFC 7045, December 2013. + + [UPNPWANIP] + UPnP Forum, "WANIPConnection:2 Service", September 2010, + <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 + + Phone: +1 425 703 8835 + EMail: dthaler@microsoft.com + + + + + + + + + + + + + + + + + + + + + + +Thaler Informational [Page 13] + |