Network Working Group Ned Freed Innosoft Kevin Carosso Innosoft Internet Draft An Internet Firewall Transparency Requirement November 1997 Status of this Memo This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 1. Abstract This memo defines a basic transparency requirement for Internet firewalls. While such a requirement may seem obvious, the fact of the matter is that firewall behavior is currently either unspecified or underspecified, and problems often arise in practice. This document is intended to be a necessary first step in making the behavior of firewalls more consistent and correct. Internet Draft Firewall Transparency November 1997 2. Introduction The Internet is now being used for an increasing number of mission critical applications. Because of this many sites find isolated secure intranets insuficient 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 unsecured and 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, disallowing or fixing traffic it believes to inappropriate, dangerous, or both. More specifically, firewalls either act as a protocol end point (e.g. a SMTP client/server or a Web proxy agent), as a packet filter, or some combination of both. In the case of a packet filter the firewall isn't visible as a protocol end point; each packet is examined and the firewall may then (1) pass the packet through to the other side unchanged, (2) drop the packet entirely, or (3) handle the packet itself in some way. Firewalls typically base 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, Expires May 1998 [Page 2] Internet Draft Firewall Transparency November 1997 (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 like SOCKS [1] to gain access to the Internet, to the internal network, or both. (This list is only intended to illustrate the sorts of things firewalls often do; it is by no means exhaustive, nor are all firewall products able to perform all the operations on this list.) Unfortunately, the development and deployment of firewalls has largely been ignored by the Internet standards community. As a result of this inattention the use of firewalls has solved some old problems, but not without generating lots of new ones in the process. This memo is intended to address the new problems firewalls can cause by establishing a basic transparency requirement for firewalls. The exact nature of this requirement is described in the following section. 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 [3]. 3. The Transparency Requirement The basic transparency requirement for firewalls is quite simple: The introduction of a firewall and any associated tunneling or access negotiation facilities MUST NOT cause the failure of legitimate and standards-compliant usage that would work were the firewall not present. Expires May 1998 [Page 3] Internet Draft Firewall Transparency November 1997 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 -- a firewall is entitled to block any sort of access that is seen as illegitimate, regardless of whether or not it is standards-compliant. This is, after all, the primary reason to have a firewall in the first place. 4. 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 because 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. Now, at some point implementors will inevitably claim that the burden of total transparency is overly onerous, that adequate security cannot be achieved and still obey it, and so on. And there's 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 this solution is that nobody can use such a network. Anything less is necessarily a tradeoff between useability and deployment. And the simple fact of the matter is that at present firewalls are being circumvented in ad hoc ways, necessarily weakening security dramatically, simply because they don't meet the transparency requirement. In other words, the only reason that some firewalls remain in use is because they have essentially been disabled. As such, IMPROVED security can be viewed as the main reason for having a transparency requirement. Expires May 1998 [Page 4] Internet Draft Firewall Transparency November 1997 5. Example Violations of the Transparency Rule This document will conclude with a (long) list of existing firewall behavior that violates the transparency requirement. (1) In an effort to enhance security by hiding internal system names that might otherwise be revealed in email headers, some firewalls either strip information from or completely delete certain header fields. There are even known cases of certain text strings (e.g. names of internal hosts systems) being deleted from message bodies. Blindly deleting information from message body text is simply not acceptable. Consider what happens when a string is deleted from a binary part encoded in base64 simply because it matches some string pattern somewhere, or what happens when someone has given their own name to their personal system. Deleting "Received:" fields from message headers is also problematic, as it interferes with message loop detection. In addition, some firewalls delete "Received:" fields in messages passing from the Internet to the local network in addition to messages going the other way, and this actually compromises security as it eliminates trace information vital in determining a hostile message's possible origin. The solution is simple for messages passing from the external Internet to internal hosts: Don't delete Received: headers because this compromises, rather than enhances, security. As for Received: headers going in the other direction, one approach is to obscure host name information using name replacement, hash functions, or encryption, rather than removing the field entirely. Simple encryption schemes lead to host names are meaningless to outsiders but if need be can be analyzed by a security manager to determine the actual underlying name. (2) Firewalls implementing Web proxies often trash URLs which are the least bit complicated. The result is that Web applications which employ complex URLs, such as directory applications, tend not to work properly Expires May 1998 [Page 5] Internet Draft Firewall Transparency November 1997 through many firewall products, even though the URLs being used are completely legal and correct. (3) Many firewalls which act as SMTP proxy agents implement only the most rudimentary form of SMTP service. The result is that the ability to use many useful SMTP facilities (DSNs, size negotiation, authentication, pipelining, etc.) is eliminated. In the case of authentication once again this action lessens security rather than strengthening it. (4) DNS service behind many firewalls works very poorly. Firewalls often implement the concept of a split between the part of a domain the outside world can see and the part the inside world can see. And firewalls are often called upon to create DNS setups of this sort. This is often done poorly -- perhaps it is just too difficult to configure such things properly. The net result often is that such restrictions end up getting summarily dumped, which again may compromise security more than it strengthens it. Note that this also makes it hard to deploy a good mailer on the inside even if the firewall lets the SMTP traffic through to/from the mail hub. A mail hub inside such a setup cannot get a true picture of the outside world, and this once again may end up compromising security rather than strengthening it. (5) Many firewalls handle TCP connections in a way which lies somewhere between acting as a full-fledged application protocol proxy and a transpart connection path. Specifically, they intercept all attempts to open TCP connections across the firewall and respond to them immediately, making the connection initiator think the open has succeeded. They then make a connection of their own to the actual destination host. If that connection succeeds packets are then forwarded from one side to the other, possibly with some additional examination and/or modification of content, or possibly not. The first problem with this technique arises when the connection from the firewall to the actual destination cannot be opened. There is no way to properly convey Expires May 1998 [Page 6] Internet Draft Firewall Transparency November 1997 the semantics of such a failure to the connection originator since the firewall has already completed the connection to the originator. The firewall must then either content itself with simply closing the connection or else send some protocol-specific response, which applications may interpret quite differently than a transport level connection failure. In the case of an SMTP transfer to a destination with multiple MX and A records, for example, existing clients may interpret a successful connection open as constituting a delivery attempt requiring no subsequent connection attempts to other MX or A records. This in turn can lead to delivery failures when one or more hosts in an MX or A record list aren't available for a prolonged period of time. The second problem with this technique arises when modifications are made to packets transferred from one side to the other without full knowledge of the underlying protocol. For example, situations have arisen where firewalls attempt to "censor" an SMTP data stream and end up removing data from that stream, operating under the assumption that since SMTP uses dot-stuffing rather than counted data such editing is acceptable. Unfortunately, the SMTP protocol has changed in recent years and now includes the BDAT command [2] for transferring counted data, among other things. Removing octets from a BDAT data stream inevitably leads to protocol desynchronization, timeouts, and transfer failures. A similar problem can occur with SMTP's VRFY command, which is a mandatory part of the SMTP protocol. Firewalls like to intercept VRFY because of the perception that VRFY exposes internal information unnecessarily. (This perception is false as comparable exposure occurs with SMTP's RCPT TO, and disabling or interfering with RCPT TO breaks the protocol completely.) Unfortunately, while it is possible to intercept and handle VRFY properly, some firewalls fail to do so, either returning a 5XX SMTP error unconditionally (which can lead to delivery failures when working with clients that do VRFYs prior to each RCPT TO) or else failing to return a properly formatted Expires May 1998 [Page 7] Internet Draft Firewall Transparency November 1997 2XX SMTP success code (the protcol requires that the response to a VRFY include an RFC 822 address enclosed in angle brackets). 6. References [1] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones, "SOCKS Protocol Version 5", RFC 1928, April, 1996. [2] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC1830, August, 1995. [3] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 7. Authors' Addresses 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 Kevin Carosso Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA tel: +1 626 919 3600 fax: +1 626 919 3614 email: kevin.carosso@innosoft.com Expires May 1998 [Page 8]