NSIS Working Group Gabor Bajko Internet Draft Nokia Document: October, 2006 Requirements for Firewall Configuration Protocol Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 18, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 1. Abstract 3GPP2 is working in specifying a way to allow the mobile network subscribers to configure the Firewalls in their network according to their needs[3]. This document defines requirements for a Firewall Configuration Protocol. It has been produced by a number of 3GPP2 member companies and endorsed by 3GPP2. It contains 3GPP2 requirements to a next generation firewall configuration protocol. 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 1 Requirements for Firewall Configuration Protocol October 2006 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 Pinhole creation to enable communication when MIPv6 is used 5 5.1.4 Pinholes deletion 6 5.1.5 Packet filters 7 5.1.6 States update 7 5.1.7 Transport protocol preferences and firewall configuration 8 5.1.8 Efficient use of the air interface 8 5.1.9 IP version 8 5.1.10 Grouping 8 5.1.11 Firewall Features 9 5.2 Security Requirements 9 6. Contributors 9 7. References 9 8. Author’s Addresses 10 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 parts of the Mobile IPv6 protocol, such as Route Optimization which NSIS Working Group Expiration April 2007 2 Requirements for Firewall Configuration Protocol October 2006 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 unsolicited 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, an end point is the only party that is aware of the details and requirements associated with 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. A protocol allowing an end point to configure the firewall(s) or at least indicating its requirements to the network would solve these problems. Such protocol would also mitigate the risk of inaccurate billing as indicated in [2], where an end point is forced to receive unsolicited traffic and incur extra charges. 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 filter with values or acceptable ranges for various fields that may occur in a packet. NSIS Working Group Expiration April 2007 3 Requirements for Firewall Configuration Protocol October 2006 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 MUST be able to create pinholes and specify the characteristics of the pinholes to be installed in the firewalls. It MUST be possible for a client to specify pinholes containing ranges of IP addresses, port numbers and SPI values. A client SHOULD be able to specify pinholes that refer to encapsulated headers (tunnelled packets filtering). A client MUST be able to specify pinholes that contain at least the routing options (Mobile IPv6). The protocol must be flexible enough to accomodate other IPv6 options and possibly for the ones which are not yet defined. A client SHOULD be permitted to open pinholes specifying any internal address associated with it. (e.g. multihoming case). The protocol SHOULD be able to validate the source IP address. Reasoning The following describes use cases where such capabilities are needed: a) SIP-established-communications 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. 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 NSIS Working Group Expiration April 2007 4 Requirements for Firewall Configuration Protocol October 2006 exist with MIPv6 signalling messages (e.g. HoTI, CoTI). Detailed description can be found in [1]. The node therefore needs to 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 MUST be able to create pinholes with wildcard for source address, port, protocol and spi values field. Reasoning. 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 (the source address is wildcarded). 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 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 Pinhole creation to enable communication when MIPv6 is used The protocol MUST support the IPv6 Next Header value. In particular, the protocol MUST support at least the value 135 (Mobility Header). Such capability is useful in the following scenario: By supporting Next Header value 135 (Mobility Header), an MN would be able to open pinholes with wildcard for source address, port, protocol and spi values, and specify that only Mobility Header messages are to be allowed to pass through. 5.1.4 Pinholes deletion NSIS Working Group Expiration April 2007 5 Requirements for Firewall Configuration Protocol October 2006 A client MUST be able to close any or all the pinholes it created with a single protocol instance. NOTE: a Firewall Configuration Protocol should provide a solution for the above requirement in a single Firewall architecture. In a multihomed scenario, with multiple Firewalls on alternative paths, there should be a means for the Firewalls to keep themselves synchronized. A client MUST be able to suggest a pinhole timeout. A firewall SHOULD be able to override such suggestions. A client MUST be able to refresh all associated pinhole timeouts with a single protocol instance. NOTE: a Firewall Configuration Protocol should provide a solution for the above requirement in a single Firewall architecture. In a multihomed scenario, with multiple Firewalls on alternative paths, there should be a means for the Firewalls to keep themselves synchronized. 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 scenario: a) The end point may host a server but later, for different reasons, it may decide not to host server anymore. Therefore, the end point should be able to close the pinholes it opened to stop incoming packets at the network, maybe even before the lifetime of the pinhole expires. This is particularly important for access networks with limited bandwidth. In addition, when opening the pinholes, each of the pinholes should be associated with a lifetime to ensure that no pinholes are left in the firewalls in case the MNs e.g. loose coverage and get disconnected from the network. 5.1.5 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 packet from a specific node (e.g. packets with specific flags on). The end point could also have NSIS Working Group Expiration April 2007 6 Requirements for Firewall Configuration Protocol October 2006 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 applications: some applications may be authorized by default by the local network policy. The end point may however not want to receive packets related to such applications and may prefer to drop the corresponding packets at the firewall to avoid a wastage of access network resources. c) Blocking Overbilling attack: Allowing the end point to install filters in the firewall prevents the Overbilling attacks 5.1.6 States update The client MUST be able to update the pinholes and/or packet filters installed in the firewall. The client MUST 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.7 Transport protocol preferences and firewall configuration The granularity of the rules MUST 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 NSIS Working Group Expiration April 2007 7 Requirements for Firewall Configuration Protocol October 2006 example is setting particular countermeasures, or specific filtering mechanisms, or specific firewall modes of operation. 5.1.8 Efficient use of the air interface The protocol MUST allow an end point to create, modify or delete several firewall states with one protocol instance. NOTE: a Firewall Configuration Protocol should provide a solution for the above requirement in a single Firewall architecture. In a multihomed scenario, with multiple Firewalls on alternative paths, there should be a means for the Firewalls to keep themselves synchronized. 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. It MUST be possible to open a pinhole with a single protocol request/response pair of messages. This is required because: a) a wireless link is a scarce and expensive resource b) real-time applications are delay sensitive 5.1.9 IP version The protocol MUST be applicable both for IPv4 and IPv6. 5.1.10 Grouping The protocol SHOULD support grouping of pinhole requests so that either all the pinholes will be created or none will be created. This capability might be useful: - to applications which require multiple pinholes to be created in order to operate successfully. - when a pinhole range can only be created by multiple pinhole requests (e.g. open a range, but block one in the middle). 5.1.11 Firewall features The protocol MAY allow the client to learn the features implemented in the FW and whether those are enabled or disabled. The protocol MAY provide a means to the client to configure the Firewall (e.g. enable/disable a feature in the FW). A Firewall MUST be able to authorise such request based on the NAI of the client and the IP address used to send the request. This capability is useful in the following scenarios: NSIS Working Group Expiration April 2007 8 Requirements for Firewall Configuration Protocol October 2006 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 MUST not open the opportunity for nodes to flood a target. The client MUST be able to integrity protect and/or encrypt the messages it sends to the firewall. A firewall MUST perform authentication and integrity check on each message from a client. 6. Contributors The following people contributed to this draft: Franck Le, Michael Paddon, Trevor Plestid, Sebastian Thalanany. Special thanks to Hannes Tschofenig for the valuable comments and inputs he made to the document. 7. 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. ftp://3gpp2.org [3] X.P0036, Network Firewall Configuration and Control, 3GPP2 TSG- X, April 2005 ftp://3gpp2.org 8. Author's Address Gabor Bajko Nokia e-mail: gabor.bajko@nokia.com NSIS Working Group Expiration April 2007 9 Requirements for Firewall Configuration Protocol October 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. NSIS Working Group Expiration April 2007 10