From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2979.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc2979.txt (limited to 'doc/rfc/rfc2979.txt') diff --git a/doc/rfc/rfc2979.txt b/doc/rfc/rfc2979.txt new file mode 100644 index 0000000..b645188 --- /dev/null +++ b/doc/rfc/rfc2979.txt @@ -0,0 +1,395 @@ + + + + + + +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 were + the firewall not present. + + A necessary corollary to this requirement is that when such failures + do occur it is incumbent on the firewall and associated software to + address the problem: Changes to either implementations of existing + standard protocols or the protocols themselves MUST NOT be necessary. + + Note that this requirement only applies to legitimate protocol usage + and gratuitous failures -- a firewall is 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 primary reason to have a firewall in the first place. + + Also note that it is perfectly permissible for a firewall to provide + additional facilities applications can use to authenticate or + authorize various sorts of connections, and for the firewall to be + configurable to require the use of such 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. + + + + + + + + + + + +Freed Informational [Page 3] + +RFC 2979 Firewall Requirements October 2000 + + +3.1. Examples + + The following sections provide some examples of how the transparency + rule actually applies to some 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], causing + legitimate application traffic to be 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 which 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, as this 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, or to block ICMP Redirect messages entirely, or to block + ICMP DU/FN messages which 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, this is not + sufficient: What is necessary is for the firewall to scan the list of + EHLO responses and only allow the ones the firewalls understands + through. If this isn't done the client and server can end up + agreeing to use an extension the firewalls doesn't understand, which + can then lead to unnecessary protocol failures. + +4. Application Requirements + + Firewalls are a fact of life that application protocols must face. + As such, application protocols SHOULD be designed to facilitate + operation across firewalls, as long as such 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. + + + +Freed Informational [Page 4] + +RFC 2979 Firewall Requirements October 2000 + + + 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, since 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) Specificating an appropriate firewall traversal mechanism if + one exists is a good idea. + + (4) Registering a separate port for new protocols is a good idea. + +5. Security Considerations + + Good security may occasionally result in interoperability failures + between components. This is understood. However, this doesn't mean + that gratuitous interoperability failures caused by security + components are acceptable. + + The transparency rule impacts security to the extent that it + precludes certain simpleminded firewall implementation techniques. + Firewall implementors must therefore work a little harder to achieve + a given level of security. However, the transparency rule in no way + prevents an implementor from achieving whatever level of security is + necessary. Moreover, a little more work up front results in better + security in the long run. Techniques that do not interfere with + existing services will almost certainly be more widely deployed than + ones that do interfere and prevent people from performing useful + work. + + Some firewall implementors may claim that the burden of total + transparency is overly onerous and that adequate security cannot be + achieved in the face of such a requirement. And there is no question + that meeting the transparency requirement is more difficult than not + doing so. + + Nevertheless, it is important to remember that the only perfectly + secure network is one that doesn't allow any data through at all and + that the only problem with such a network is that it is unusable. + Anything less is necessarily a tradeoff between usability and + security. At present firewalls are being circumvented in ad hoc ways + because they don't meet this transparency requirement and this + necessarily weakens security dramatically. In other words, the only + + + + + +Freed Informational [Page 5] + +RFC 2979 Firewall Requirements October 2000 + + + reason that some firewalls remain in use is because they have + essentially been disabled. As such, one reason to have a + transparency requirement is to IMPROVE security. + +6. Acknowlegements + + Bill Sommerfeld provided the text for the Path MTU Discovery example. + This document has benefited from discussions with a number of people, + including but not limited to: Brian Carpenter, Leslie Daigle, John + Klensin, Elliot Lear, and Keith Moore. + +7. References + + [1] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. + Jones, "SOCKS Protocol Version 5", RFC 1928, April, 1996. + + [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, + November 1990. + + [4] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + August 1982. + + [5] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, + "SMTP Service Extensions", STD 10, RFC 1869, November 1995. + +8. Author's Address + + Ned Freed + Sun Microsystems + 1050 Lakes Drive + West Covina, CA 91790 + USA + + Phone: +1 626 919 3600 + Fax: +1 626 919 3614 + EMail: ned.freed@innosoft.com + + + + + + + + + + + + +Freed Informational [Page 6] + +RFC 2979 Firewall Requirements October 2000 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + 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. + + + + + + + + + + + + + + + + + + + +Freed Informational [Page 7] + -- cgit v1.2.3