Behavior of and Requirements for Internet Firewalls
RFC 2979
Document | Type |
RFC - Informational
(October 2000; No errata)
Was draft-iab-firewall-req (iab)
|
|
---|---|---|---|
Author | Ned Freed | ||
Last updated | 2015-11-11 | ||
Stream | IAB | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | IAB state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) |
Network Working Group N. Freed Request for Comments: 2979 Sun Category: Informational October 2000 Behavior of and Requirements for Internet Firewalls Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls. While most of these things may seem obvious, current firewall behavior is often either unspecified or underspecified and this lack of specificity often causes problems in practice. This requirement is intended to be a necessary first step in making the behavior of firewalls more consistent across implementations and in line with accepted IP protocol practices. 1. Introduction The Internet is being used for an increasing number of mission critical applications. Because of this many sites find isolated secure intranets insufficient for their needs, even when those intranets are based on and use Internet protocols. Instead they find it necessary to provide direct communications paths between the sometimes hostile Internet and systems or networks which either deal with valuable data, provide vital services, or both. The security concerns that inevitably arise from such setups are often dealt with by inserting one or more "firewalls" on the path between the Internet and the internal network. A "firewall" is an agent which screens network traffic in some way, blocking traffic it believes to be inappropriate, dangerous, or both. Note that firewall functions are disjoint from network address translation (NAT) functions -- neither implies the other, although sometimes both are provided by the same device. This document only discusses firewall functions. Freed Informational [Page 1] RFC 2979 Firewall Requirements October 2000 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]. 2. Characteristics Firewalls either act as a protocol end point and relay (e.g., a SMTP client/server or a Web proxy agent), as a packet filter, or some combination of both. When a firewall acts 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, Freed Informational [Page 2] RFC 2979 Firewall Requirements October 2000 (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 intended to illustrate the sorts of factors firewalls often consider; it is by no means exhaustive, nor are all firewall products able to perform all the operations on this list.) 3. Firewall Requirements Applications have to continue to work properly in the presence of firewalls. This translates into the following transparency rule: The introduction of a firewall and any associated tunneling or access negotiation facilities MUST NOT cause unintended failures of legitimate and standards-compliant usage that would work wereShow full document text