RFC 7288

Reflections on Host Firewalls

📅 published June 2014, from ietf

RFC 7288: Reflections on Host Firewalls 🎀

Okay bestie, first things first 🧚 This is RFC 7288, called Reflections on Host Firewalls. D. Thaler from Microsoft wrote it for the Internet Architecture Board (IAB) 💅 It was published in June 2014 as an Informational doc, which means it's shared for the permanent record and isn't a standards-track spec 📚 Its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's a standalone moment ✨

Abstract

Okay so firewalls are literally everywhere now, and everyone in the industry accepts that 🔥 Most of them are network firewalls guarding network links. Host firewalls are different because they run on the end-user's own system 💻 The tea is that software can be running and eating up resources, and then a host firewall just blocks its communication 💀 Everyone kinda assumes that's either the best outcome or the only possible one 🙈 But what about an end state where the software isn't running at all, or where it's running in a way that doesn't lead to unwanted communication? In this doc, we dig into the reasons behind these assumptions and suggest ways to make the architecture better going forward 🦋

Status of This Memo

Real talk: this document is not an Internet Standards Track spec. It's published for informational purposes only 📖

This doc is a product of the Internet Architecture Board (IAB). It holds info the IAB thought was valuable enough to keep on permanent record 🌸 It represents the consensus of the IAB. Documents the IAB approves for publication are not a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for the details 🧐

For the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7288 🎀

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, which you can find at http://trustee.ietf.org/license-info, as they're in effect on the date of publication. Please read these carefully, because they explain your rights and restrictions for 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

1. Introduction ✨

Okay, so [BLOCK-FILTER] talks about blocking or filtering abusive or objectionable content and communications, plus how that affects the overall Internet architecture 🧠 This doc is the sequel to that convo, focusing on how host firewalls affect hosts and applications 💖

"Behavior of and Requirements for Internet Firewalls" [RFC2979] gives a nice intro to firewalls, and it's all about transparency. It says:

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.

Lowkey, lots of firewalls today don't follow that rule. For example, they block traffic with IP options or IPv6 extension headers (see [RFC7045] for more on that) 😭

In Section 2.1 of "Reflections on Internet Transparency" [RFC4924], the IAB shared more thoughts on firewalls and how they affect the Internet architecture. That includes disclosure obligations, plus the complexity that comes up as applications evolve to get around firewalls 🌈 This doc picks up that thread and adds more considerations 🫶

Traditionally, firewalls were all about arming customers to protect them from bugs in applications and services 🛡️ This doc asks a bunch of big questions, like who a firewall is supposed to protect from what. It mostly looks at this from an end system perspective, with a special focus on host firewalls, though not exclusively 🦋

The Internet Security Glossary [RFC4949] has a detailed definition of a firewall. But informally, most people think of a firewall as "something that blocks unwanted traffic" (see [RFC4948] for a discussion of the many types of unwanted traffic) 🔥 The big question is: "unwanted by whom?" 🤔

Possible answers include end users, application developers, network administrators, host administrators, firewall vendors, and content providers. We exclude the sender of the traffic by definition, since the sender usually wants that traffic delivered 📬 Still, these other entities have different, and often conflicting, desires. That means one type of traffic might be wanted by one entity and unwanted by another 😅 So it's no surprise there are different kinds of firewalls, and different kinds of "arms race," which we'll get into in Section 4.1.2 ⚔️

1.1. Terminology

Here we make a distinction between a "host firewall," which just aims to protect the single computer it runs on, and a "network firewall," which sits in the network and aims 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] clears up that misconception 🙅‍♀️ Still, some of the same observations in this doc may also apply to NATs 💅

Sandboxed environments, like the ones browsers provide, 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 seen as a mechanism that blocks unwanted outbound traffic under a "same origin policy." That policy means a script can only talk to the "site" it came from. The definition of site could be something like the scheme and authority in a URI 🌸

In this doc, "application" is used generically to mean any component that can receive traffic 🎀 It could mean a process running on a computer (including a system service), or even a portion of a TCP/IP stack itself, like a component that responds to pings 🏓

2. Firewall Rules 🍓

Okay so wants and unwants for traffic can be expressed as "allow" vs. "block" rules, with some way to resolve rules that conflict 💜 Lots of firewalls are actually built on rules like these. Figure 1 shows some typical sources of those 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 network firewalls are run by network admins (if there are any), and host firewalls are run by host admins (if there are any). A firewall can also have rules that come from the firewall vendor itself 🏭

End users typically can't directly give rules to firewalls that affect other users, unless the end user is a host or network admin 🙋‍♀️ App developers can, though, give rules to some firewalls, like at installation time 🎁 They can do this by calling an API that a host firewall included with the operating system provides, or by giving metadata to the operating system so firewalls can use it. They can also use a protocol like Universal Plug and Play (UPnP) [UPNPWANIP] or the Port Control Protocol (PCP) [RFC6887] to talk to a network firewall (see Section 4.1.3 for a longer chat) 💬

Firewall rules generally fall into two categories:

  1. Attack surface reduction: Rules meant to stop an application from doing things the developer doesn't want it to do 🛑
  2. Security policy: Rules meant to stop an application from doing things the developer might want it to do, but an administrator doesn't 🙅

A firewall is unnecessary if both categories are empty 🤷‍♀️ Next, we'll go through each category one at a time, focusing on host firewalls (though some points might be just as relevant to network firewalls) 💖

3. Category 1: Attack Surface Reduction ✨

okay so bestie, this category is all about stopping apps from doing stuff the developer never meant for them to do 🙈

Some people ask if this category is usually empty. It's not, not right now 💅 One reason is that you can stick a security barrier in a separate process, away from the process that might be compromised. That way a vulnerability can't just run wild. There's also some desire for a "stealth mode" (see Section 5 below) 🫶

So a firewall will typically block everything by default. Then a one-time, privileged, application-install step adds one or more Allow rules, and after that the normal (unprivileged) app runs inside whatever rules are left. Main character energy for the rules 👑

A second reason this category isn't empty is when the rules are used as workarounds for stuff the app developer found too much work to build. Here's what that looks like:

  1. Simple policies that the developer would totally want but that are hard to implement. One example is an app that should only talk within the local network (like a home or enterprise network), but isn't reachable from the global Internet or while the device is moved to some public network, like a hotspot. A second example is the reverse: talk over the Internet but not with local entities. This category would shrink with better platform support for these policies, making them easier for developers to build and use 🌸
  2. Complex policies where the developer literally can't know the specifics. One example is communicating only during normal business hours, or only outside them, where the exact hours might change by location and time of year ⏰ Another example is avoiding links that cost too much, where "too much" depends on the customer. The end host and app might not even know the costs! This category would shrink with better platform support too, letting the app use a simple API to talk to some other library or service that handles the specifics 🧚

3.1. Discussion of Approaches

When running an app would cause unwanted behavior, customers have three choices. Let's go through them one by one 🦋

  • 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 stop it from working in unwanted ways.

3.1.1. Fix the Software

Firewall vendors love to point out that you can update firewall rules way faster and more reliably than app software 💅 Some apps might have no way to update at all, and support for other apps might disappear (like if the developers aren't around anymore 😭). Most modern operating systems (and the apps that come with them) have automatic updates, and some independent apps do too. But until every app has automatic updates, and those updates are actually used, firewall rules will still update faster than software patches. Also, in some contexts (like some enterprises), a possibly lengthy retesting and recertification process has to happen before an app can be updated. Ugh, so slow 💀

So yeah, mechanisms that encourage and ease the use of secure automatic software updates are important, and they'd seriously cut down on overall complexity ✨ Those mechanisms should also let updates get scheduled at good times, taking into account operational stuff like dependencies, compatibility, testing, and maintenance windows 🗓️

3.1.2. Don't Use the Software

The key question to ask is: could the app still do something useful when it's firewalled? If yes, then not using the software is probably unrealistic 🙅‍♀️ For example, a game with both single-player and multi-player modes could still be fun in single-player when it's firewalled 🎮 If the answer is no, then it's better to not let the app run in the first place. Some host firewalls can actually block apps from running at all, which is iconic 🔥

3.1.3. Run the Software behind a Host Firewall

Like we said earlier, one downside of this approach is that resources still get used up. The app can still eat memory, CPU, and bandwidth (up to the point of blockage), plus ports in the transport layer protocol, and maybe other resources depending on the app, all for operations that give zero benefit while it's firewalled 😩

The second big downside is the bad user experience 💔 Usually the app and the end-user have no clue why the app isn't working. A poorly designed app might not cope well and could burn even more resources, like retrying an operation that keeps failing over and over 🙃

The third downside is that a firewall rule often ends up blocking more than it should for attack surface reduction. That can mess with protocol operation and even cause adverse effects on other endpoints 😬 For example, some firewalls can't do full deep packet inspection at line speed, so they've adopted a block-by-default approach to anything they don't understand from the first few bytes. This is seriously harmful to innovation, because it gets in the way of deploying new protocols and features 🚫

Another example: blocking ICMP messes with path MTU discovery, which can cause problems for other entities (see [RFC4890] and Section 3.1.1 of [RFC2979] for more). This can happen because of not understanding all the details of app behavior, or because of an accidental misconfiguration. Section 2.1 of [RFC5505] says, "Anything that can be configured can be misconfigured," and digs into this more 🤭

So, in short, it's important to make apps more aware of the constraints of their environment, so they can behave well when they're constrained 🫶

4. Category 2: Security Policy 🛡️

As noted in Section 2, this category of firewall rule usually tries to stop an app from doing things an administrator doesn't want it to do, even if the app developer did want it 👀

Is this category typically empty? It depends! For enterprise-scenario firewalls, it's almost never empty, so the problems from Section 3.1.3 can be super common here too 😵 For consumer-scenario firewalls, it's generally not empty either, but there are some notable exceptions. For example, the host firewall in some operation systems always starts out empty, and most users never change that 🌈

4.1. Discussion of Approaches

Security policy can be implemented in any of three places: in the application, in a firewall, or in a library/service that the application explicitly uses. Let's dive in 💖

4.1.1. Security Policies in Applications

Here, every application has to implement support for potentially complex security policies, plus ways for administrators to configure them 🥴 Explicit interaction with apps does avoid the problems from Section 3.1.3, but this approach is impractical for a bunch of reasons. First, the complexity makes it hard to build and really error-prone, especially for app developers whose main skill isn't networking 🍓 Second, there are potentially tons of apps (and app developers), which leads to an inconsistent experience. That makes it hard for an administrator to manage common policies across apps, and it drives up training and operational costs 💸

4.1.2. Security Policies in Host Firewalls

Putting security policies in firewalls without explicit interaction with the apps gives you the problems from Section 3.1.3 💀 On top of that, it leads to "arms races," where apps are incented to evolve to get around the security policies, since what the end user or developer wants can clash with what an administrator wants ⚔️ 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 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.

Arms races like these come from inherent tussles between different entities' desires 🥊 For example, the tussle between end-user desires and administrator desires leads to an arms race between firewalls and deep packet inspection on one side, vs. the use of obfuscation or tunnels on the other 🕵️‍♀️

Even though these arms races are usually talked about with network firewalls, they happen with host firewalls too. It's generally easier for a host firewall to overcome them, though, since it may be more practical for a host firewall to set up some form of trust between the policy-desiring entities, with a trusted arbiter in the middle 🧚‍♀️✨

4.1.3. Security Policies in a Service

In this approach, apps use a library or other external service, so the apps have explicit knowledge of how the security policies will affect them. That way they can avoid the problems in Section 3.1.3. In a sandboxed environment, this might even be the app's only way to interact with the network 📦

So in this opt-in approach, apps give a description of the network access they're requesting. The library/service can make sure that apps and/or users are informed in a way they can understand, and that administrators can craft policy that affects the apps 🎀

This is really hard to do with a firewall-vendor-specific library/service when there can be multiple firewall implementations (including ones in the middle of the network). It's usually impractical for an app developer to know about and build for a bunch of different firewall APIs 😩 It is possible, though, to use a firewall-vendor-agnostic library/service that can talk to both apps and firewalls. Then app developers and firewall developers can all use a common platform 🤝

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's also the approach used by PCP in the IETF. So, 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 🦋

okay so bestie, there's this whole vibe where you want to be invisible to address and port scans on a public network 🫣 but ngl, a bunch of RFCs basically say you have to respond to stuff. Like, TCP [RFC0793] compliance means sending a RST when a SYN shows up and nobody's listening, and ICMPv6 [RFC4443] compliance means sending an Echo Reply to an Echo Request. So being a stealth girlie while still being a compliant one is kind of a plot twist 💀

Firewall rules can give you that stealth without changing your statement of compliance with the basic protocols, which is lowkey iconic ✨ But stealth mode could also be a configurable option that the applications themselves use 🧚 Like, instead of a firewall rule dropping an outbound message after the app already made it, it's way more efficient if the app just knows not to generate it in the first place. Fewer resources wasted, no cap 💅

6. Security Considerations 🔐

okay this one is SO important, so listen up 👂 There's a super common misconception that firewalls protect you from malware on your computer. Actually, firewalls protect you from buggy software 🐛 Some people are also worried that firewalls give users a false sense of security, and honestly, same. Firewalls are not invulnerable 😭 and they won't stop malware from running if the user lets it run. Protect your heart and your device, bestie 💜

This document mainly focuses on host firewalls. If you want more on network firewalls, check out [RFC2979] and [BLOCK-FILTER] 🌈

7. Acknowledgements 🫶

Stuart Cheshire gets the credit for starting this whole thing 👑 He asked the thought-provoking question of why you'd firewall an application instead of just stopping it from running, and that sparked the discussion. That discussion, plus the IAB tech chat in November 2011, led to this document. Dan Simon, Stephen Bensley, Gerardo Diaz Cuellar, Brian Carpenter, and Paul Hoffman also gave helpful suggestions, so thank you all, you're the real ones 🎀

8. IAB Members at the Time of Approval 🌸

These are the IAB members at the time this document was approved, bestie 💖

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 📚

Here's the full reading list, iykyk 🤓

[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.

[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. Here are the contact details, bestie 💌

Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA  98052
USA

Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
📦 where this page comes from