[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                    A. D. Keromytis
Internet Draft                                       Columbia University
draft-keromytis-disfi-compare-00.txt



                   Some Problems with Perimeter Firewalls



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


Abstract

   This document discusses some of the shortcomings of perimeter
   firewalls and the reasons for employing end-point (or distributed)
   firewall functionality in the network, either as an alternative or
   coexisting with traditional network access controls.


1.  Introduction

   Distributed firewalls [Bel99,IKBS] represent an alternative network
   access control mechanism to "traditional" perimeter firewalls
   [BC94].  Policy is enforced in a decentralized manner by the
   different components of the network, acting in a coordinated
   manner.  Distributed network access control (DNAC) can be employed
   either as an alternative or in conjunction with perimeter
   firewalls, and can employ different mechanisms and protocols, as
   well as heterogeneous elements.

   This document discusses some of the shortcomings of perimeter
   firewalls and the reasons for employing end-point (or distributed)
   firewall functionality in the network, either as an alternative or
   coexisting with traditional network access controls.

1.1.  Terminology

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [RFC2119].


2.  Shortcomings of Perimeter Firewalls

   In this section, we list several shortcomings of Perimeter
   Firewalls (PFs) and briefly discuss them.  It is important to bear
   in mind that PFs fundamentally depend on restrictions in the
   network topology, such that they can examine all traffic exchanged
   between a protected network and the public network, and enforce a
   security policy (typically access control).

2.1.  Performance

   Because PFs depend on restrictions in network topology to enforce a
   security policy, it has to examine all traffic exchanged between
   the protected network and the public network.  Thus it can become a
   performance bottleneck, especially if it also has to perform
   network encryption to accomodate Virtual Private Networks (VPNs),
   virus checking, or other CPU-intensive services.  Load-balancing
   techniques can help to some extend, but the complexity of
   state-sharing and synchronization in firewall clusters is a real
   limiting factor.

2.2.  Protection from Insiders

   Likewise, because of the dependence on the network topology, a PF
   can only enforce a policy on traffic that traverses it.  Thus,
   traffic exchanged among nodes in the protected network cannot be
   controlled.  This gives an attacker that is already an insider or
   can somehow bypass the firewall (see Section 2.6) complete freedom
   to act.  One obvious solution is to deploy multiple firewalls, in
   which case they must be coordinated and control in a consistent
   manner.

2.3.  End-to-end Protocol Properties

   There are several stateful protocols that use random ports for data
   transfers, which require the PF to actively monitor (and
   reconstruct) the control message sequences for these protocols.
   This increases the complexity and decreases the performance of the
   PF, and thus the whole (protected) network.  The fundamental
   problem is that IP was designed as a lean network substrate that
   would simply act as a packet carrier; all protocol state is
   maintained at the communication end-points.  A PF breaks this model
   by definition (since it needs to peek inside packets to make a
   policy decision); for some protocols, the ability to make that
   decision requires reconstruction of part of the state that is
   readily available at the end-points.

2.4.  Network Encryption

   Increasingly, end-to-end cryptographic protocols such as IPsec
   [RFC2401], TLS [RFC2246], and SSH are being used to protect
   (encrypt) communications between nodes.  PFs are hard-pressed to
   enforce a security or intrusion detection (e.g., virus scanning)
   policy in these situations, as they cannot strip the encryption.
   Potential solutions break this end-to-end model of security (key
   escrow, firewall as encryption end-point or trusted
   man-in-the-middle, etc.) with a corresponding loss of assurance and
   performance.

2.5.  Mobility / Telecommuting / Infrastructure Sharing

   In certain scenarios, nodes or users that are topologically outside
   the protected network must be treated as if they were inside it.
   Examples include users on the road, telecommuters, and Intranet
   configurations.  In all these cases, parts (or all) of the
   protected infrastructure need to be exposed in a controlled manner
   to remote entities.  PFs make this a complicated subject,
   especially in the presence of multihoming and fine-grain resource
   sharing (and corresponding access control) requirements.

2.6.  Closure

   Due to several trends in networking such as site multihoming,
   abundant dial-up access, and wide-scale (insecure) wireless
   deployment, administrators cannot be assured that all traffic
   exchanged between the protected and the public network will be
   examined by a PF: an attacker that manages to access the protected
   network through a user-installed wireless access point has complete
   freedom of action.

2.7.  Defense in Depth

   Following classic army doctrine, prudent security engineering
   argues for multiple defensive lines ("defense in depth") as a way
   to minimize the risk of a successful breach of the perimeter.  PFs
   alone cannot (by definition) provide this functionality; additional
   mechanisms are necessary inside the protected network.


3.  Security Considerations

   This draft describes some shortcomings of perimeter firewalls, and
   argues for the need for distributed firewall functionality.  There
   are several security issues in such an architecture, including
   policy robustness, secure distribution and control, coordination,
   management, and resilience to intrusions or insider attacks (this
   is not intended to be a detailed or exclusive list).  These issues
   will be addressed in separate documents of the working group
   (should there be one).


4.  IANA Considerations

   No requirements are placed on IANA at this stage.


Acknowledgements

   This document came out of discussions at the Distributed Firewalls
   mailing list, which can be foiund at disfi@lists.intel.com

   To subscribe on the list, send email to listserv@lists.intel.com
   with the command "subscribe disfi" in the message body.


References:

   [Bel99]  S.M. Bellovin, "Distributed Firewalls", USENIX ;login
            magazine, special issue on security, November 1999.

   [BC94]  Bellovin, S.M. and W.R. Cheswick, "Firewalls and Internet
           Security: Repelling the Wily Hacker", Addison-Wesley, 1994.

   [IKBS]  Ioannidis, S. and Keromytis, A.D., and Bellovin, S.M.  and
           J.M. Smith, "Implementing a Distributed Firewall",
           Proceedings of Computer and Communications Security
           (CCS), pp. 190-199, November 2000, Athens, Greece.

   [RFC 2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2246]  T. Dierks and C. Allen, "The TLS Protocol Version 1.0,"
              Internet Engineering Task Force, RFC 2246, January 1999.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.


Author's address:

   Angelos D. Keromytis
   Columbia University, CS Department
   515 CS Building
   1214 Amsterdam Avenue, Mailstop 0401
   New York, New York 10027-7003

   Phone: +1 212 939 7095
   Email: angelos@cs.columbia.edu


Expiration and File Name

   This draft expires in May 2003

   Its file name is draft-keromytis-disfi-compare-00.txt