RFC2979 - Behavior of and Requirements for Internet Firewalls

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.

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.

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 RFC2119 [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,

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

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.

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

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", RFC1928, April, 1996.

[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement

Levels", BCP 14, RFC2119, March 1997.

[3] Mogul, J. and S. Deering, "Path MTU discovery", RFC1191,

November 1990.

[4] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821,

August 1982.

[5] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,

"SMTP Service Extensions", STD 10, RFC1869, 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

9. Full Copyright Statement

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 RFCEditor function is currently provided by the

Internet Society.