Network Working Group Ned Freed, Innosoft Internet Draft Behavior of and Requirements for Internet Firewalls February 2000 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 1. 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 Internet Draft Firewal Requirements February 2000 making the behavior of firewalls more consistent and correct. 2. 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 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. 2.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]. 3. 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 Expires August 2000 [Page 2] Internet Draft Firewal Requirements February 2000 (1) implement a "safe" subset of the protocol, (2) perform extensive protocol validity checks, (3) use an implementation methodology designed to minimize the liklihood of bugs, (4) run in an insolated, "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 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.) Expires August 2000 [Page 3] Internet Draft Firewal Requirements February 2000 4. Firewall Requirements Applications have to continue to work properly in the presence of firewalls. This translates into the following transparency requirement: The introduction of a firewall and any associated tunneling or access negotiation facilities MUST NOT cause gratuitous 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 attemped 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 configureable 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. 5. Application Requirements Firewalls are a fact of life that application protocols must face. As such, application protocols SHOULD be designed to facilititate 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. Expires August 2000 [Page 4] Internet Draft Firewal Requirements February 2000 6. Security Considerations 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 useability 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 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. Good security may occasionallly result in interoperability failures between components. This is understood. However, this doesn't mean that gratiutous interoperability failures caused by security components are acceptable. 7. References [1] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones, "SOCKS Protocol Version 5", RFC 1928, April, 1996. [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Expires August 2000 [Page 5] Internet Draft Firewal Requirements February 2000 8. Authors Address Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA tel: +1 626 919 3600 fax: +1 626 919 3614 email: ned.freed@innosoft.com 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. Expires August 2000 [Page 6]