NSIS Working Group Gabor Bajko Internet Draft Franck Le Document: Nokia Michael Paddon Qualcomm Trevor Plestid RIM February, 2005 Requirements for Firewall Configuration Protocol Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet- Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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. This Internet-Draft will expire on August 5, 2005. Copyright Notice Copyright (C) The Internet Society (2005). 1. Abstract This document defines requirements for a Firewall Configuration Protocol, has been produced by a number of 3GPP2 member companies and presents their view for the requirements to a next generation firewall configuration protocol. 1 Requirements for Firewall Configuration Protocol February 2005 With the number of threats that keep increasing on the Internet, many networks have decided to deploy firewalls to reduce the possible risks and protect their users as well as their network resources. Firewalls can however present many issues with new protocols, applications and scenarios to be supported. Data packets may be discarded at the firewalls. In addition, the clients may often be the only parties that know the requirements and details of the data communications. This document therefore explains why a protocol allowing clients to configure firewalls would be useful, and attempts to identify the requirements and features to be supported by such a protocol. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 3. Table of Content Status of this memo 1. Abstract 1 2. Conventions used in this document 2 3. Table of contents 2 4. Introduction 2 5. Requirements 4 5.1 Functional Requirements 4 5.1.1 Pinholes creation 4 5.1.2 Creation of Pinholes without knowing the CN 5 5.1.3 Pinholes deletion 6 5.1.4 Packet filters 6 5.1.5 States update 7 5.1.6 Transport protocol preferences and firewall configuration 7 5.1.7 Efficient use of the air interface 7 5.1.8 IP version 8 5.1.9 Firewall Features 8 5.2 Security Requirements 8 6. References 8 7. Appendix 8 8. AuthorÆs Addresses 9 4. Introduction While the numbers of attacks keeps increasing with Denial of Service, Distributed Denial of Service, virus, worms and other forms of attacks, many networks are deploying firewalls to reduce the threats. Firewalls can however introduce several issues with new protocols, applications, and scenarios to be supported. To mention few examples, firewalls and Mobile IPv6 do not work well together [1]. Firewalls may present issues to many features, considered important NSIS Working Group Expiration 8/14/05 2 Requirements for Firewall Configuration Protocol February 2005 parts of the Mobile IPv6 protocol, such as Route Optimization which may not be used in the presence of firewalls. Most firewalls are also configured to block unsolicited incoming traffic. Connections are typically authorized only when initiated by nodes in the network protected by the firewalls. While this allows to reduce unwanted IP traffic, such configuration may compromise the use of arbitrary peer to peer protocols/applications, and may prevent end points in networks protected by such firewalls to host servers. Different approaches have been proposed to solve theabove listed problems: Application-Level-Gateways (ALGs) that by analyzing the signaling messages, create and remove the necessary pinholes in the firewalls, have been developed; protocols allowing Application Severs (AS) to create and delete pinholes in firewalls have also been specified. However, it has to be noted that often, the end point is the only party that knows the details and requirements of the data communications: a) Relying on some existing network entities (e.g. ALG, AS) to interpret the signaling and open the pinholes in the firewalls may result in misconfiguration: the created pinholes may not correspond to the incoming and outgoing traffic, and the data packets may be dropped at the firewalls (e.g. an end point may establish a communication using SIP&SDP and may decide to use IPsec to protect the media stream. If pinholes are created based on SIP&SDP signaling, the final data packets may not match the pinholes. Similar problems exist if Mobile IP is used: the packets may differ from the states created in the firewalls). b) Existing network entities may not have the ability to verify the validity/authenticity of the signaling. E.g. Mobile IPv6 has been designed to be an end-to-end protocol. A firewall on the path may not know if a Binding Update is valid or a forged one. Only the end point, thanks to the Return Routability Test, and thanks to the IPsec Security Association with its Home Agent can know it. A firewall cannot therefore know whether the states for the Mobile Node should be updated or not, upon detecting a Binding Update message. c) For P2P protocols and applications, and for scenarios where the end point wants to host a server, the end point is typically the only entity that knows the requirements of the pinholes to be created in the firewalls. d) A key criteria is that the protocol supports extensibility for higher level msessages. For example the protocol may want to define different firewalls modes of operation. An example: for a given node behind a firewall, existing stateful packet filtering technology deals with it acting as an initiating endpoint. The node should however also be able to act as a soliciting endpoint, where a soliciting end point response to an initiating endpoint outside the firewall creates pinholes. NSIS Working Group Expiration 8/14/05 3 Requirements for Firewall Configuration Protocol February 2005 A protocol allowing an end point to configure the firewall(s) or at least indicating its requirements to the network would solve these problems. Actually such protocol could also increase the security since in some attacks as illustrated in the Overbilling one [2], end points were forced to receive unwanted traffic and had to pay for the undesired received data. A protocol allowing the end point to install packet filters that block the unwanted traffic would prevent such attack. NOTE: Packets in the FW are (de)selected by matching them against a set of "pinholes". A pinhole, as used in this document, is a specification of acceptable ranges for various fields that may occur in a packet. 5. Requirements The following sections describe the requirements for such a protocol. Based on different use cases, useful features are identified and described. The security requirements are also analyzed. 5.1 Functional Requirements 5.1.1 Pinholes creation A client SHOULD be able to create pinholes and specify the characteristics of the pinholes to be installed in the firewalls. A client SHOULD be able to specify pinhole characteristics such that any desired subset of the packets directed to the node will be passed by the firewall. Characteristics should include (but not be limited to) all IP headers and upper layer protocol headers. A client SHOULD be able to specify pinholes that admit classes of packets, i.e. a single pinhole should permit ranges of values in header fields. (The mechanism must be efficient; 1000 ports shouldn't equate to 1000 rules). A client SHOULD be able to specify pinholes that refer to encapsulated headers (Mobile IP or tunneling) or routing options (Mobile IPv6). A client SHOULD be permitted to open pinholes specifying any internal address associated with it. A client MUST NOT be permitted to open pinholes which specify internal addresses not associated with it (e.g. multihoming case). The following describes use cases where such capability is needed: a) SIP-established-communications NSIS Working Group Expiration 8/14/05 4 Requirements for Firewall Configuration Protocol February 2005 After agreeing on the IP addresses and the ports on where to receive the media stream, the node needs to open the appropriate pinholes in the firewalls for the media traffic. The end point should have a mean to indicate the characteristics (e.g. IP addresses/port numbers) of the pinholes that need to be installed in the firewalls. This mechanism must not be incompatible with the standard statefull firewall pinholes creation mechanism. NOTE: A stateful firewall is a firewall that keeps track of the state of network connections (such as TCP streams) traveling across it. b) Mobile IP Home Agent When a MN changes its location, it typically acquires a local IP address (Care of Address). When that happens, several IP addresses can be used by the MN for sending/receiving packets (e.g., HoA, CoA, Home AgentÆs address), and those may take different format (encapsulated, not encapsulated, etc.). If corresponding pinholes are not opened, the firewall may block the packets. Similar issues exist with MIPv6 signalling messages (e.g. HoTI, CoTI). Detailed description can be found in [1]. The node should have a means to specify the required pinholes (e.g. for the MIPv6 signalling, and for the incoming packets from the HA) to one or more firewalls. c) In some environments (e.g. 3GPP GPRS access) nodes possess a network prefix for one of their interface, instead of one specific address and may want to accept packets to a range of destination addresses; or, a node behind a FW may want to accept connections for a range of ports (e.g. default ones) or from a range of source addresses; 5.1.2 Creation of Pinholes without knowing the CN The end point SHOULD be able to create pinholes with wildcard for any field (e.g. port number, IP address, etc.) Such capabilities are useful in the following scenarios: a) The end point should be able to open pinholes even without knowing the characteristics (e.g. IP address) of its correspondent nodes. This feature is needed for applications where the end point does not yet know the CN: the end point may e.g. want to host a server (FTP, HTTP) or run applications such as P2P. b) This feature is also needed for the Mobile IPv6 protocol since a Mobile Node may e.g. send a Binding Update from an IP address that NSIS Working Group Expiration 8/14/05 5 Requirements for Firewall Configuration Protocol February 2005 is not known before. The MIPv6 Correspondent Node needs to open the pinholes to accept such Binding Update to allow Route Optimization. 5.1.3 Pinholes deletion A client SHOULD be able to close any or all the pinholes it created with a single protocol instance. A client SHOULD be able to suggest a pinhole timeout. A firewall SHOULD be able to override such suggestions. A client SHOULD be able to refresh all associated pinhole timeouts with a single protocol instance. The protocol MUST have a means to allow a trusted 3rd party to take an action instead of the client. Such capabilities are useful in the following scenarios: a) The client should be able to close a pinhole it created. The end point may host a server but later, for different reasons, the end point may decide not to host server anymore. Therefore, the end point should be able to close the pinholes to stop incoming packets at the network. This is particularly important for access networks with limited bandwidth. The end point should also be able to close all pinholes it created without listing them (e.g. a rebooting node). b) When opening the pinholes, each of the pinholes should be associated with a lifetime to ensure that no pinholes are left in the firewalls. 5.1.4 Packet filters The protocol MUST support specifying the action to be taken for packets matching the packet filters. For each packet filter, the protocol MUST be able to indicate whether packets matching the filter should 'PASS' or if the firewall should 'DROP' them. The actions MUST be extendable. Such capabilities are useful in the following scenarios: a) Restricting the packets: the end point may have opened a pinhole to accept packets from a specific node. However the end point may not want to receive a specific type of packets from this end point (e.g. packets with specific flags on). The end point could also have opened a pinhole to accept incoming requests in the case it is hosting a server. The end point may however have a list of nodes it does not want to receive requests from. b) Restricting the services: some service may be authorized by default by the local network policy. The end point may however not NSIS Working Group Expiration 8/14/05 6 Requirements for Firewall Configuration Protocol February 2005 need such services and may prefer to drop the corresponding packets at the firewall not to waste the access network resources. c) Blocking Overbilling attack: Allowing the end point to install filters in the firewall prevents the overbilling attacks 5.1.5 States update The client SHOULD be able to update the pinholes and/or packet filters installed in the firewall. The client SHOULD be able to update the firewall states by providing: a) the fields to be updated b) the values for the fields to be updated This capability is useful in the following scenarios: a) The end point may e.g. be a Mobile IPv6 Node and may change its Care of Address. As described in [1], there is the need to update the states in the firewall (section 4.3), otherwise data packets will be dropped at the firewalls. b) The end point may be changing its IP address for privacy reasons (RFC 3041). The end point may have installed different filters rules in the firewalls and in that case, the end point also has to update the states in the firewalls for the filters to become applicable to the new IP address. c) Closing the previous rules and recreating new ones for the new value may unnecessarily consume network resources (e.g. access link) especially if there are many rules, and introduce latency to the procedure. 5.1.6 Transport protocol preferences and firewall configuration The granularity of the rules SHOULD allow an end point to specify the TCP flags, and other transport protocol related information (e.g. the end point should have the ability to specify that it does not want to receive TCP SYN packets. The protocol MUST be extendable to allow further more complex actions. The rationale is that there is an expected need to have to define additional firewall mechanism in addition to setting pinholes. An example is setting particular countermeasures, or specific filtering mechanisms, or specific firewall modes of operation. 5.1.7 Efficient use of the air interface NSIS Working Group Expiration 8/14/05 7 Requirements for Firewall Configuration Protocol February 2005 The protocol SHOULD allow an end point to create, modify or delete several firewall states with one protocol instance. This capability is useful in some wireless networks, where the access link resources are limited. This would reduce the overhead and the delay of the procedures. 5.1.8 IP version The protocol SHOULD be applicable both for IPv4 and IPv6. 5.1.9 Firewall features The protocol SHOULD allow the client to learn the features implemented in the FW and whether those are enabled or disabled. The protocol SHOULD allow the client to configure the Firewall (e.g. enable/disable a feature in the FW). This capability is useful in the following scenarios: Certain Firewalls implement different features aimed to protect nodes within the network, like TCP Sequence Verifier or SYN Relay. These features however, may prevent nodes in establishing end-to-end communications using certain protocols (e.g. IPSec can not be used with FWs implementing SYN Relay). Knowing in advance the features enabled in the Firewall may help nodes choosing adequate protocols and succeed with end-to-end communication. 5.2 Security requirements The firewall MUST prevent an end point to update/close firewall pinholes opened by other nodes, and to modify/delete a packet filter installed by other nodes (to avoid fraud). The firewall configuration protocol SHOULD not open the opportunity for nodes to flood a target. The client SHOULD be able to integrity protect and/or encrypt the messages it sends to the firewall. 6. References [1] Franck Le, Stefano Faccin, Basavaraj Patil, Hannes Tschofenig, ôMobile IPv6 and Firewalls, Problem statementö IETF Internet draft, August 2004. [2] S.P0103-0, Network Firewall Configuration and Control, 3GPP2 TSG-S, Dec 2004. 7 Appendix NSIS Working Group Expiration 8/14/05 8 Requirements for Firewall Configuration Protocol February 2005 The following requirements represent requirements for Firewalls, and are provided herein for information. A firewall MUST be able to verify which internal addresses an initiating endpoint is granted for use. A firewall MUST limit the resources (especially memory and CPU time) that a soliciting endpoint can consume. The firewall SHOULD block outgoing packets with spoofed source addresses (this might require the firewall to be able to associate allocated addresses with link layer identifiers, i.e. PPP tunnels, MAC addresses, etc.). The firewall SHOULD reject requested pinholes that do not comply with a predetermined policy. Extensible actions Examples of these extendable actions and firewall modes of operation are; -to specify firewall behavior for specific protocols, such as pass all SIP packets -to specify the configuration is being performed by a proxy, and that the end node is not capable of self configuration, such that default configuration may be applied to the firewall for that end node -to specify unique firewall behaviors for that end node only, such as allow the firewall to operate in æsymetrical stateful firewallÆ mode, allowing only the first ænÆ packets of an originating endpoint outside the firewall to reach the solicting endpoint inside the firewall. A soliciting end point response to an initiating endpoint outside the firewall creates pinholes. This may be defined as a æsymetrical stateful firewallÆ -rate limiting of originating source IP to a particular end point - allow a max number of "partially opened" sessions, 'fully opened' defined after the CN source IP responds to packets from the MN firewall sends packets to MN on behalf of the originating source to properly complete an 'open' session, where for example the MN is a server to prevent DOS attacks such as SYN ACK. - For a particular protocol, the firewall provides the response to the soliciting node outside the firewall, instead of the end node inside the firewall. When a packet response comes back from the soliciting node, then we have a authorized pinhole also known not to be spoofed. Also, subsequent originating packets from the end node also causes a pinhole. Otherwise subsequent incoming packets from the soliciting node are permanently blocked (for that particular end node only) Example is TCP SYN packets 8. Author's Addresses NSIS Working Group Expiration 8/14/05 9 Requirements for Firewall Configuration Protocol February 2005 Gabor Bajko Nokia e-mail: gabor.bajko@nokia.com Franck Le Nokia e-mail: franck.le@nokia.com Michael Paddon Qualcomm e-mail: mwp@qualcomm.com Trevor Plestid RIM e-mail: tplestid@rim.com NSIS Working Group Expiration 8/14/05 10 Requirements for Firewall Configuration Protocol February 2005 Full Copyright Statement Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." 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 implmentation 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." NSIS Working Group Expiration 8/14/05 11