RFC 2979

RFC 2979: Behavior of and Requirements for Internet Firewalls

Part 1 of 2 💖 (Sections 5 through 8 come next, bestie!)

Okay so, the title block first 🎀 This is RFC 2979, "Behavior of and Requirements for Internet Firewalls," written by Ned Freed (listed as N. Freed) over at Sun. It's from the Network Working Group, and it's dated October 2000. It's an Informational doc, which means it's just sharing info with the internet crowd and doesn't specify an Internet standard of any kind 📝. The header doesn't list any RFCs that it obsoletes or updates, so it's not replacing or patching anything else ✨.

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, so share away 💜.

Copyright Notice 🌈

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🧚

Okay, so this memo lays out how Internet firewalls should behave and what they need to do to play nicely with everything else 🔥. Most of it might seem obvious, but firewall behavior is often either unspecified or underspecified, and that lack of detail causes real problems in practice 💀. This is meant to be a first step toward making firewalls more consistent across implementations and in line with accepted IP protocol practices 🫶.

1. Introduction ✨

The Internet is being used for more and more mission critical applications, and honestly it's giving very serious energy 👑. Because of this, lots of sites find isolated secure intranets insufficient for their needs, even when those intranets are built on and use Internet protocols. So instead they end up providing direct communications paths between the sometimes hostile Internet and systems or networks that handle valuable data, provide vital services, or both 😭.

The security concerns that come with these setups are usually handled by putting one or more "firewalls" on the path between the Internet and the internal network. A "firewall" is an agent that screens network traffic in some way, blocking traffic it thinks is inappropriate, dangerous, or both 🚫.

Note that firewall functions are disjoint from network address translation (NAT) functions. Neither one implies the other, although sometimes both are provided by the same device 🍓. This document only discusses firewall functions 💅.

1.1. Requirements notation

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]. Bestie, those caps are doing real work here 🎀.

2. Characteristics 💖

Firewalls either act as a protocol end point and relay (for example, an SMTP client/server or a Web proxy agent), act as a packet filter, or do some combination of both 🌸.

When a firewall acts as a protocol end point, it may:

1. implement a "safe" subset of the protocol,
2. perform extensive protocol validity checks,
3. use an implementation methodology designed to minimize the likelihood of bugs,
4. run in an insulated, "safe" environment, or
5. use some combination of these techniques in tandem.

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,
2. drops the packet entirely, or
3. handles the packet itself in some way.

Firewalls typically base some of their decisions on IP source and destination addresses and port numbers. For example, firewalls may:

1. block packets from the Internet side that claim a source address of a system on the internal network,
2. block TELNET or RLOGIN connections from the Internet to the internal network,
3. block SMTP and FTP connections to the Internet from internal systems not authorized to send email or move files,
4. act as an intermediate server in handling SMTP and HTTP connections in either direction, or
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.

This list of decision criteria is only meant to illustrate the sorts of factors firewalls often consider. It is by no means exhaustive, and not all firewall products can perform every operation on this list 🙈.

3. Firewall Requirements 🔥

Applications have to keep working properly when firewalls are in the picture. 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 is that when such failures do happen, it is up to the firewall and its associated software to fix the problem. Changes to either implementations of existing standard protocols or the protocols themselves MUST NOT be necessary 🫶.

Note that this requirement only covers legitimate protocol usage and gratuitous failures. A firewall is totally 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 main reason to have a firewall in the first place 👑.

Also note that it's perfectly fine for a firewall to provide extra facilities that applications can use to authenticate or authorize various kinds of connections, and for the firewall to be configurable to require the use of those 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 🧚.

3.1. Examples

The following sections give some examples of how the transparency rule actually applies to specific protocols 🦋.

3.1.1. Path MTU Discovery and ICMP

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], which means legitimate application traffic can get delayed or completely blocked when talking to systems connected via links with small MTUs 😭.

By the transparency rule, a packet-filtering router acting as a firewall that 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. Blocking them would break the standards-compliant usage of Path MTU discovery by hosts generating legitimate traffic 💀.

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. It's also fine to block ICMP Redirect messages entirely, or to block ICMP DU/FN messages that were not sent in response to legitimate outbound traffic 🙈.

3.1.2. SMTP Extensions

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, that is not sufficient. What is necessary is for the firewall to scan the list of EHLO responses and only allow through the ones the firewall understands 🍓. If this isn't done, the client and server can end up agreeing to use an extension the firewall doesn't understand, which can then lead to unnecessary protocol failures 😩.

4. Application Requirements 🎀

Firewalls are a fact of life that application protocols have to face. So application protocols SHOULD be designed to facilitate operation across firewalls, as long as those 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. It will eventually result in added complexity in firewall handling of port 80 🙃.
2. Defining a secure subset of a protocol is a good idea, since it simplifies the firewall design process ✨.
3. Specifying an appropriate firewall traversal mechanism, if one exists, is a good idea 🌈.
4. Registering a separate port for new protocols is a good idea 🦋.

9. Full Copyright Statement 💅

Copyright (C) The Internet Society (2000). All Rights Reserved. 🎀

Okay so, the copyright vibes: anyone can copy this document and share it with others, and you can make derivative works that comment on or explain it, or help people implement it. Those works can be published, copied, and distributed, whole or in part, with no restrictions at all, as long as the copyright notice above and this paragraph are included on every copy and derivative work. ✨

The one catch is that this document itself can't be modified in any way. That means you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the copyright procedures defined in the Internet Standards process must be followed, or when it's translated into languages other than English. 🌍

The limited permissions above are perpetual, meaning they will never be revoked by the Internet Society or its successors or assigns. Forever and ever, bestie. 💜

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