Internet DRAFT - draft-iab-firewall-req

draft-iab-firewall-req










Network Working Group                           Ned Freed, Sun
Internet Draft                 <draft-iab-firewall-req-02.txt>

     Behavior of and Requirements for
            Internet Firewalls

                June 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       Firewall Requirements           June 2000


making the behavior of firewalls more consistent across
implementations and in line with accepted IP protocol
practices.


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


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.






           Expires December 2000            [Page 2]





Internet Draft       Firewall Requirements           June 2000


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 liklihood 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





           Expires December 2000            [Page 3]





Internet Draft       Firewall Requirements           June 2000


means exhaustive, nor are all firewall products able to
perform all the operations on this list.)


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


4.1.  Examples

The following sections provide some examples of how the
transparency rule actually applies to some specific protocols.








           Expires December 2000            [Page 4]





Internet Draft       Firewall Requirements           June 2000


4.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-compilant 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.


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


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





           Expires December 2000            [Page 5]





Internet Draft       Firewall Requirements           June 2000


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.


6.  Security Considerations

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.

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.





           Expires December 2000            [Page 6]





Internet Draft       Firewall Requirements           June 2000


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.


7.  Acknowlegements

Bill Sommerfeld provided the text for the Path MTU Discovery
example.  This document has benefitted from discussions with a
number of people, including but not limited to: Brian
Carpenter, Leslie Daigle, John Klensin, Elliot Lear, and Keith
Moore.


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

[3]  J. C. Mogul, S. E. Deering, "Path MTU discovery", RFC
     1191, November 1990.

[4]  J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC
     821, August 1982.

[5]  J. Klensin, N. Freed, M. Rose, E. Stefferud, and D.
     Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
     November 1995.











           Expires December 2000            [Page 7]





Internet Draft       Firewall Requirements           June 2000


9.  Authors Address

Ned Freed
Sun Microsystems
1050 Lakes Drive
West Covina, CA 91790
USA
 tel: +1 626 919 3600           fax: +1 626 919 3614
 email: ned.freed@innosoft.com


10.  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 December 2000            [Page 8]