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