ternet Engineering Task Force Jiri Kuthan Internet Draft GMD Fokus draft-kuthan-fcp-00.txt March, 2000 Expires: September 2000 Firewall Control Protocol Framework and Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract We propose requirements for a protocol which allows for remote control of packet filters. This protocol may be used by application clients or application-level gateways to pass their protocols through firewalls deploying 'default-deny' filtering policy. It also may used by network management entities to manage filtering policies. We anticipate that generic design of the control protocol will allow for management of finer flow handling policies than simple accept/deny. 1 Introduction Firewalls are used to protect networks from external attacks be restricting information flows. They consist of Application Level Gateways (ALGs) and packet filters. ALGs are trusted, administrator- maintained, application-aware entities acting on behalf of untrusted hosts at application layer. They examine application protocol flows and allow only messages that conform to security policies to pass through. Packet filters are used to impose security restrictions at lower layers. They usually check IP and TCP/UDP headers of examined packets against tables of filtering rules. Only conforming IP packets are allowed to pass through the filter. The filtering policy may be either 'default-permit' or 'default-deny'. 'Default-permit' policy allows all but explicitly stated IP flows whereas 'default- deny' policy allows only explicitly stated IP flows to pass through. Internet Draft Firewall Control Protocol March 2000 Typically, the policy is set up to allow traffic from and to trusted ALGs to pass through. The 'default-deny' policy is more restrictive and provides higher security. It is frequently deployed in corporate networks. Unfortunately, it makes firewall traversal difficult for applications that use session bundles. This means that they negotiate IP address and port numbers with a control protocol dynamically and then use these addresses to establish streams for transport of raw data. Examples of applications relying on session bundling are SIP [1], H.323 [2], and FTP [3]. Without a kind of firewall control these applications cannot open firewall pinholes dynamically. Additionally, they will need to query address associations of original and translated packet flows if the packet filters deploy network address translation [15].Only then, they will be able to include the translated addresses in their control protocols. To allow applications using bundled protocols to pass through packet filters during application sessions without compromising security a mechanism for control of filtering rules is needed. The remainder of this document considers "default-deny,permit-control-protocols- through-ALGs,dynamic-open" packet filtering policy and ALGs using their application awareness to control the filters. We also assume that the ALGs are not collocated with the packet filters. This setting is referred to in [11] as "internal service, separated proxy" and shown in Figure 1. We formulate requirements for the communication protocol between packet filters and hosts that control them in this documents. We call this protocol "Firewall Control Protocol" (FCP). We use the term FCP to refer to the general concept in this document. An existing protocol such as SNMP could be possibly used to implement FCP functionality. SIP SIP +---------+_____________ | ________|SIP Proxy| \ | / +---------+.. +----+---------------+ | : | | | : FCP +-----+------------+ | | :...........| FCP | Filtering | | | FTP +---------+.............| unit| Rules Table| | | _____|FTP Proxy|_____________+-----+------------+ | | / +---------+ | Packet | | | -----| Filter | +-----------+ / +----+---------------+ +-----------+| data streams / | +-----------+||----------------/ | |end-devices|| (RTP, ftp-data, etc.) | +-----------+ | | Inside | Outside Legend: ---- raw data streams Internet Draft Firewall Control Protocol March 2000 ____ application control protocols .... Firewall Control Protocol Figure 1: FCP Architecture The FCP framework is described as follows. Section 2 defines terms used throughout this document. In Section 3, we formulate requirements for functionality of Firewall Control Protocol (FCP). Performance issues are introduced in section 4. 2 Definitions TBD. Include or refer to definitions of NAT, ALGs, packet filters, packet relayers, protocol bundling, session, control protocol, flow, stream, etc. 3 Requirements for FCP 3.1 Management of Filtering Rules FCP should allow for adding, deleting and possibly changing processing rules. Definition of packet processing rules should be generic, i.e. should provide the possibility to specify arbitrary packet matching expressions and actions for matched packets. The actions include but are not limited to passing packet, dropping packets with and without ICMP notification, rewriting packet content, querying number of packets matched by a rule, querying or setting up address association if NAT is used, and setting up rule precedence. Experience from packet filters like tcpdump [16] and rule management utilities like ipchains [17] could be used when refining these requirements. Though the primary goal of FCP framework is to simplify firewall traversal for applications using protocol bundling, its functionality could allow for more general flow management if designed generically. This is illustrated by the following example: A corporate SIP proxy may want to instruct the packet filter to assign a special DiffServ class to all media streams belonging to a preferred SIP session. Then it would instruct edge router to set DiffServ bits in these packets accordingly. The benefits of this scenario are that applications residing at end systems do not have to be aware of DiffServ, edge routers do not need to identify to which DiffServ class which packet flows belong to and this is done by administrator-maintained, application-aware ALGs. 3.2 Softstate Rule Design. Opening dynamic pinholes in firewalls makes only sense if they are closed on session termination. To avoid unreleased rules due to system failures introducing timeouts to the filtering rules is desirable. Since applications know best how long their sessions can Internet Draft Firewall Control Protocol March 2000 be it is appropriate to allow them to specify rule expiration period when setting up a rule. To keep the rules alive if session duration exceeds timeout period the issuer of a rule will have to send keep- alive-messages periodically. 3.3 MACs Usage Alternatively to keeping set of authorization rules at packet filters packets could carry authorization information. Although this approach has not been deployed, a discussion of its use and required FCP support would be beneficial since it features some interesting properties such as resistance against spoofing. Most likely, the packet authorization information would be generated using some Message Authentication Checks (MACs). The MACs would be generated to be verifiable by firewalls. The MACs can cover either packet headers or entire packets. The former scenario is sensitive to replay attacks but allows firewalls to keep a single verification secret and communicate MACs to senders on authorization. The latter scenario is not sensitive to reply attacks but requires firewalls to keep individual secrets for each authorized flows. Feasibility discussion of this scheme is out of scope of this document. It would have to address issues such as passing of packets with MACs through multiple firewalls, security assessment, MAC throughput, secret distribution, time validity of MACs, etc. 3.4 Security FCP channel must be secure to prevent eaves-droppers from learning the rules, MAC secrets, and whatever else is communicated over FCP. Authentication mechanism is needed to prevent unauthorized entities from changing the rules. In the most simple case (packet filter driven by trusted ALGs) IP-addressed based authentication may be satisfactory. If end-devices are allowed to modify the rules (like they can with SOCKS), then secure user-based authentication would have to be deployed along with some administration policy. For example, the policy may permit authenticated user A to open pinholes from his host at "high" port numbers and deny anything else. 3.5 Open Issues - Multicasting. Does multicasting introduce any challenges to FCP? Probably not. - Multiple firewalls. Scenarios for traversal of multiple firewalls need to be examined. - Interaction with IPv6 needs to be examined. 4 Performance Issues The 'default-deny-and-dynamic-open' filtering policy compels stateful packet filters to maintain potentially huge tables of filtering rules. The rule lookup processing overhead grows with number of rules and may lead to increased packet latency. Algorithms Internet Draft Firewall Control Protocol March 2000 for fast rule lookup in large, frequently changing filter databases are needed. Results of some recent research in this area was published in [7], [8], [9]. If stateless MAC-based approach is taken, per-packet processing overhead resulting from MAC verification does not grow with number of authorized data flows but depends on efficiency of the MAC algorithm. For example, Touch [10] claimed the throughput of MD5 to be up to 256 Mbps with 1995 hardware. 5 Example TBD. Include protocol flows for traversal of a SIP session through a NAT-enabled firewall. Appendix A Bibliography [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg: SIP: Session Initiation Protocol, RFC 2543, IETF, March 1999. [2] ITU-T Recommendation H.323. "Packet-based Multimedia Communications Systems," 1998. [3] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", RFC 959, IETF. October 1985. [4] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "The Simple Network Management Protocol", RFC 1157, IETF, May 1990[5] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones: SOCKS Protocol Version 5, RFC 1928, IETF, April 1996. [6] Postel, J. and Reynolds, J.: Telnet Protocol Specification, RFC 854, IETF, May 1983. [7] A. Feldmann, S. Muthukrishnann: Tradeoffs for Packet Classification. In Proc. IEEE INFOCOM 2000, 2000. [8] V. Srinivasan, S. Suri, G. Varghese: PAcket Classification Using Tuple Space Search. In Proc. ACM SIGCOMM '99, 1999. [9] P. Gupta, N. McKeown: Packet Classification on Multiple Fields. In Proc. ACM SIGCOMM '99, 1999. [10] J. Touch: Report on MD5 Performace, RFC 1810, IETF, June 1995. [11] J. Rosenberg, D. Drew, H. Schulzrinne: "Getting SIP through Firewalls and NATs", Internet Draft, Internet Engineering Task Force, Feb. 2000. Work in progress. [12] M. Shore: "H.323 and Firewalls: Problem Statement and Solution Framework", Internet Engineering Task Force, Feb. 2000. Work in progress. [13] S. Mercer, A. Molitor, M. Hurry, T. Ngo: "H.323 Firewall Control Interface (HFCI)", Nov. 1998. Expired Internet Draft. [14] F. Baker: IP Forwarding Table MIB, RFC 1354, IETF. July 1992. [15] P. Srisuresh and M. Holdrege: IP network address translator (NAT) terminology and considerations, RFC 2663, IETF, August 1999. [16] tcpdump [17] Rusty Russel: Linux IP Firewalling Chains, http://www.rustcorp.com/linux/ipchains/ B Glossary of Abbreviations Internet Draft Firewall Control Protocol March 2000 ALG Application Level Gateway FCP Firewall Control Protocol FTP File Transfer Protocol IP Internet Protocol HTTP Hypertext Transfer Protocol MAC Message Authentication Check NAT Network Address Translation SIP Session Initiation Protocol TCP Transmission Control Protocol UDP User Datagram Protocol C Author's Address Jiri Kuthan GMD Fokus Kaiserin-Augusta-Allee 31 D-10589 Berlin Germany