Network Working Group R. Penno Internet Draft Expires: July 2003 Distributed End-Point Firewall Control (DEFCon) Applicability Scenarios draft-penno-defcon-appl-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC 2026]. 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 Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document discusses the use of a distributed end-point firewall control (DEFCon) in various network deployment scenarios. 1.Introduction The applicability scenarios for Defcon can be divided into four categories. a) Scenarios where a perimeter firewall cannot provide adequate security when compared to a distributed firewall or there are severe scaling and security issues, e.g., applying firewall to encrypted traffic. b) Scenarios where a distributed firewall complements the perimeter firewall functionality Penno draft-penno-defcon-appl-00.txt [Page 1] Internet-Draft Defcon Applicability Scenarios December 2002 c) Scenarios where the same functionality can be achieved by a distributed or a perimeter firewall d) Scenarios where a distributed firewall wouldn't work with a perimeter firewall The applicability scenarios could also be divided based whether the differences, when compared to perimeter firewalls, are mostly tied to traffic inspection or network topology. *Network Topology Mobility (Wireless) Telecommuting Broadband Internet Access Separation Between access and service provider Protection from Insiders *Traffic Inspection Encrypted Traffic Personal Firewall High touch services Firewall In this document we will examine each scenario on the list above and will conclude with a brief discussion pointing out if the scenario belongs to category a, b, c or d. 2. Applicability Scenarios for Defcon 2.1 Mobility In the case the user access the Internet through his mobile phone, although his ISP could provide a network based firewall solution, when he is roaming this service might not be available. In this case his ISP could push a firewall policy that could take effect when the user roams to an area services by a different wireless provider. Of course the mobile phone could contact the management station of his native ISP and pull the appropriate policies for a roaming user. An interesting situation could occur if the roaming network has its own set of policies, that it wishes to enforce on roaming nodes in its network - since a compromised or rogue node could issue a DoS attack from this other network. In this case there should be a mechanism in place to decide which polices to use, knowing that might exist conflicting or overlapping policies. Penno draft-penno-defcon-appl-00.txt [Page 2] Internet-Draft Defcon Applicability Scenarios December 2002 2.2 Telecommuting Certain corporations have a strict policy in what types of traffic or applications their employees can use inside their premises or when using a device that belongs to the company outside its premises. Corporations are also usually concerned about security relating to confidential or sensitive material that can be stored on employees laptop or desktops. The solution to this problem is to employ a distributed end point firewall where the corporation can guarantee that their employees are only using approved applications and their computers are protected by a firewall if they are accessing the Internet outside the company's premises. Another solution for telecommuters could be to use a encryption protocol such as IPsec to connect to his company and then send and receive all traffic through this connection, which would be protected by the company's firewall. A disadvantage with the second approach is the delay introduced due to the routing of all internet traffic through the corporate network, which will also add unnecessary load to it. 2.3 Broadband Internet Access In Broadband deployments is very common for subscribers to make use of firewall software installed on their hosts or built-in in their access devices (cable/xdsl modem, switch, etc). The problem is that very often subscribers do not have the technical expertise to configure their firewalls appropriately. Two solutions exist to this problem. The first one, which is used today, is to use a Broadband RAS that has the ability to offer network or virtual firewalls. The access provider configures a customized firewall for each subscriber based on its userid, class (e.g., *@ispA.com) or some other means of identification (e.g, virtual circuit). The subscriber of course also has the ability to change the rules of its virtual firewall. The second one would be to employ a distributed firewall solution where the access provider also configure the firewall on behalf of the subscriber and push the firewall rules to each of the subscribers' hosts. It is assumed that the subscriber should be able to change its firewall rules and when a new machine connects to the network it could pull the appropriate firewall policy based on the userid using the host or some other means of identification (e.g., IP address). In this scenario, with the exception of encrypted traffic, the same functionality can be achieved by a distributed or network based Penno draft-penno-defcon-appl-00.txt [Page 3] Internet-Draft Defcon Applicability Scenarios December 2002 firewall. The choice between the two methods would be based on ease of configuration, software cost, management overhead, etc, etc Of course methods, network and end point based firewalls, could be used complementing each other. 2.3.1 Separation between Access and Service Provider [TBD] 2.4 Encrypted Traffic In the case where users inside the perimeter firewall use encrypted communication with outside parties, is not possible or extremely troublesome for the firewall to inspect the packets. Potential solutions not only require the firewall to become a trusted entity but also incur in a high processing demand. An end point firewall would be the most adequate choice in this case. 2.5 Personal Firewall Independent of the network deployment scenario, there are cases where the firewall policy to be applied to a device or access connection is based on the identity of the user connected or using the device. For example, in a household different content filtering policies are applied depending on identification of the user. Or in corporation certain employees might have a different access restriction than others. Most perimeter firewalls apply its rules based solely on layer 3 or 4 information contained in the packet. When the IP addresses allocated to hosts are dynamic, there is no mapping between users and source IP address. In this case only a distributed end point firewall that could reside on the host and apply different policies based on the user identification would be an adequate solution. An exception would be broadband Internet deployment where an access protocol that carries user identification (e.g., PPPx) is used and a customized network firewall policy can be applied. 2.6 High Touch Services Firewall Firewalls nowadays are being required to implement demanding or specialized services such as content filtering, virus scanning, active code parsing, etc. These services impose a burden that depending on the number of users the firewall cannot handle. There are some solutions to this problem. The first one would be to employ specialized devices where the firewall (in this case an OPES processor) would send the traffic to be scanned, filtered, etc [OPES- Arch][OPES-Cases]. There could be as many specialized devices as needed. Authors draft-penno-defcon-appl-00.txt [Page 4] Internet-Draft Defcon Applicability Scenarios December 2002 The second one would be to employ a distributed firewall solution and relinquish these demanding or specialized tasks to the end nodes. In this scenario the same functionality can be achieved by a distributed or network based firewall. The decision between the two models would be based on software availability, license costs, scalability, management overhead and others. [OPES-Arch] A. Barbir et. al, "An Architecture for Open Pluggable Edge Services (OPES)", Internet-Draft: http://www.ietf.org/internet- drafts/draft-ietf-opes-architecture-03.txt, Aug 2002. [OPES-Cases] A. Barbir et. al, "OPES Use Cases and Deployment Scenarios", Internet-Draft: http://www.ietf.org/internet- drafts/draft-ietf-opes-architecture-02.txt, July 2002. [Bel99] S.M. Bellovin, "Distributed Firewalls", USENIX ;login magazine, special issue on security, November 1999. [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. [Defcon-Req] R. Sahita, " Distributed/End-Point Firewall Control (DEFCon) Requirements", draft-many-defcon-reqs-00.txt, 3. Authors' Addresses R. Penno EMail: rapenno@yahoo.com 4. Acknowledgements Thanks to Ravi Sahita for his comments. Full Copyright Statement Copyright (C) The Internet Society (2002). 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 Penno draft-penno-defcon-appl-00.txt [Page 5] Internet-Draft Defcon Applicability Scenarios December 2002 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 RFC Editor function is currently provided by the Internet Society.