Short Description

It is hard to impossible for Internet telephony to traverse firwalls and NATs. This inhibits a considerable number of Internet users from using Internet telephony services. Firewall Communication Protocol (FCP) is being designed to attack this problem. It connects signaling servers such as SIP Proxies or H.323 gatekeepers with firewalls, NATs and possibly other intermediate network devices ("middleboxes"). This construct enables to introduce application patchwork dealing with problems caused by firewalls and NATs in a scalable, easy-to-maintain and efficient manner.

Long description

Problem Statement

Novel applications, Internet telephony being a major example of them, are seriously broken by presence of intermediate network devices: NATs (and all flavors of it including IPv4v6 NAT-PT and NAPT), firewalls and possibly other "middleboxes". One of the root problem reasons is such devices deploy static packet processing policies whereas novel applications introduce dynamic conditions exceeding capabilities of such static policies. Vendors have been trying to address this issue by embedding sophisticated application modules into their network devices. However, such monolithic solutions have only limited maintainability, frequently duplicate intelligence located in application servers unnecessarily and are likely to result in lower performance. They are incompatible with hop-by-hop application security.

Solution

The main design concept of our solution is decomposition: We split application awareness from transport/network layer processing. A generic application-independent protocol is used to reconnect the split parts again. With this approach, new applications can be rapidly ntroduced to network devices easily by device vendors as well as third parties. Performance is also expected to be better as the network devices are relieved from processing and maintaining state above the transport layer. In addition, hop-by-hop security is enabled by this model. Postscript and PDF pictures of the architecture are available.

Current Status

We have been proposing this solution at IETF. A new working group midcom was formed in January 2000 to deal with FCP issues. Its goal is to gain in-depth understanding of the problem space. The group has not been chartered to develop a specific protocol. Most likely, once the requirements are formulated an attempt will be made to map them to an existing protocol. In the meantime, we (GMD Fokus) are developing a proprietary light-weighted FCP for experimental purposes. Many vendors indicated interest in FCP.

Applicability Scope

FCP is primarily thought to accomplish traversal of Internet telephony accross firewalls and NATs. It can be easily used by other complex applications as well, for example RTSP. There may be other uses as well such as firewall management. The protocol can be used to control other devices than firewalls/NATs. Almost any task requiring control of per-flow processing state may be accomplished using FCP. Active Network concepts may utilize FCP to introduce application-awareness into routers. FCP use is almost unlimited. Like with weapons, it is a dual-use technology. We are currently not concerned with any such extensions.

Midcom Working Group

History

FCP is being discussed at midcom WG.
Before forming midcom WG, FCP was discussed on the foglamps mailing list and midcom BOF ( You may want to check the draft minutes of 49th IETF MidCom BOF.)

Presentations

Presentation ( Powerpoint or HTML/JPEG ) at midcom BOF at 49th IETF
Presentation at foglamps BOF at 47th IETF

FAQ

I'd like to use FCP for maintenance of QoS state as well. How? It is not certain this is beneficial. In some scenarios, FCP controllers intervene in the middle of an end-to-end path and cannot solve the QoS end-2-end problem. To solve end-2-end QoS problem in Internet telephony, you will most likely want to use end-2-end QoS signaling and decouple it from session signaling as suggested in the manyfolks draft . Dave Oran wrote some comments on decoupling QoS signaling from session signaling: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force in Adelaide) and [IPTEL] CPL Question About Priority . FCP may be still used to communicate some data of local (as opposed to end-2-end) importance such as maximum packet rate.
Giving control to the applications reduces security, does not it? No. Application-awareness of the controllers has nothing to do with who they are and how much trusted they are. Though the controllers may be applications in end-devices, the most likely scenario is they are administrator-maintained, trusted proxies (external ALGs).
Allowing incoming calls to open pinholes in firewalls is a security thread, isn'it? It is surely less restrictive and secure than a 'default-deny' packet filtering policy. However, it still poses reasonable restrictions on data flows: it opens pinholes only for media belonging to calls considered trustworthy. Calls considered untrustworthy by a policy are denied. The policy may depend almost on anything, e.g., caller's domain, call subject, callee's approval, etc. and it allows for opening pinholes only to/from reasonable addresses (e.g. to higher port numbers of an IP-phone pools.) Parties uninvolved in the session will not be able to use the pinholes (unless they spoof).
Whom does the protocol allow to control the firewalls? What is the controller allowed to do? It depends on the administration policy. Most likely, the policy grants the control to application-aware, centrally maintained, trusted proxies (ALGs) and/or authenticated management tools. The only required protocol support is authentication.
What changes are needed to enable these scheme? Only an interface between proxies and packet filters has to be added. No changes to end-devices are needed at all.
Why do we not use SOCKSV5 for this purpose?SOCKS V5 was primarily designed for simple client-server applications. It does not allow for binding, precise pinhole definition (e.g., by SRC/DST address/port) and NAT control.

Documents

Internet Drafts submitted or related to Midcom
Other Internet Drafts related to firewall/NAT traversal
J. Kuthan: Internet Telephony Traversal across Decomposed Firewalls and NATs , in 2nd IP Telephony Workshop , April 2001, New York.
S. Bellovin: Distributed Firewalls
Fredrik Thernelius: SIP, NAT and Firewalls
U. Roedig, R. Ackermann, R. Steinmetz: Evaluating and Improving Firewalls for IP-Telephony Environments, March 2000, to appear in iptel2000 Proceedings
R. Gold: Active Virtual Private Networks

Implementations

Two independent server implementations of FCP, midcom-like protocol, have been developed at two technical universities. Both of them are in never-ending "under-construction" process. See more at the respective sites: Berlin development, Prague development. The CVS repository also includes protocol ABNF specification, examples, and description.
If you have any questions about these implementations, send them to fcpwg@fokus.gmd.de.

Last modification: 2003-03-20 01:00:00 CET by Jiri Kuthan