Internet Draft
Internet Engineering Task Force Jiri Kuthan
Internet Draft GMD Fokus
draft-kuthan-fcp-01.txt Jonathan Rosenberg
June, 2000 dynamicsoft
Expires: December 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
The purpose of this document is to collect and put under discussion
requirements for a protocol allowing for decomposition of
application-awareness from packet processing in firewalls. The
protocol will be used by application-aware entities to control
packet flows of applications traversing firewalls dynamically. This
kind of control allows applications using session control protocols
to traverse firewalls while still retaining restrictive packet
filtering policy. Network management tools may also utilize the
protocol to manage packet-processing policies. We suggest an
extensible framework that may be used for management of arbitrary
per-flow control states in network nodes.
1 Introduction
Firewalls are trusted, administrator-maintained devices used to
protect networks from external attacks by enforcing restrictions on
information flows. The restriction policies are centrally defined
and maintained by network administrators. The firewalls consist of
Application Level Gateways (ALGs) and packet filters. ALGs are
application-aware entities acting on behalf of untrusted hosts at
application layer. They examine application protocol flows and allow
only messages conformant to security policies to pass through.
Optionally, they modify the messages to make them policy-conformant.
Packet filters are used to impose security restrictions at lower
layers. They usually inspect IP and TCP/UDP packet headers against
Internet Draft Firewall Control Protocol June 2000
tables of filtering rules. Only conforming IP packets are allowed to
pass through filters. The packet 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. Typically,
the latter policy is set up to allow traffic from and to trusted
ALGs to pass through.
The 'default-deny' policy provides higher security by being more
restrictive. It is frequently deployed in corporate networks.
Unfortunately, it makes firewall traversal difficult for
applications that use session bundles. This means that such
applications (e.g., SIP [1], H.323 [2], and FTP [3]) negotiate IP
addresses and port numbers with a session control protocol
dynamically and then use the negotiated addresses to establish
packet streams for transport of raw data. This technique is useful,
for example, if multiple applications want to receive RTP [21] flows
and cannot share the same TCP/UDP port number or an application uses
port numbers to demultiplex multiple incoming RTP flows. It is also
necessary if IP address information is dynamic.
Without a kind of firewall control these applications cannot open
firewall pinholes for their data streams dynamically. Additionally,
they need to query or set address translations for their packet
flows if the packet filters deploy network address translation
(NAT)[15]. Only then will they be able to include the translated
addresses in their session control protocols.
We propose to use application-awareness residing in trusted nodes
located out of the packet filters to manage packet-filtering
policies dynamically. Exploiting the application-awareness allows
for implementation of very fine security policies that meet
application needs but still remain restrictive. Decomposition of
application-awareness from packet processing is likely to increase
performance of packet filters and make maintenance of the
application-awareness easier. Application logic residing in
arbitrary external ALGs may be used for this purpose without having
to make packet filters understand the individual applications. End-
devices do remain unchanged. The only needed extension is a control
protocol between the ALGs and packet filters.
For example, a trusted, administrator-maintained SIP may open
temporary pinholes in a packet filter for media belonging only to
SIP sessions considered trustworthy. This scenario is illustrated in
Figure 1. A packet filter implements the 'default-deny' packet
filtering policy. It permits session control traffic from and to the
ALGs (SIP proxy, FTP proxy). The ALGs use their application-
awareness to control the packet filter dynamically through a control
protocol. If a new application protocol such as H.323 is introduced
no changes to packet filters are required. This setting is referred
to in [11] as "internal service, separated proxy".
This document summarizes requirements for the control protocol
between the packet filters and their controllers. We call this
Internet Draft Firewall Control Protocol June 2000
protocol "Firewall Control Protocol" (FCP). We use the term FCP to
refer to the general concept in this document. Discussion on how FCP
maps or does not map to an existing protocol is out of scope of this
document.
The FCP framework is described as follows. Section 2 defines terms
used throughout this document. In Section 3, we formulate
requirements for Firewall Control Protocol (FCP). Open issues that
need additional discussion before translating them to requirements
are presented in Section 3.7. Performance issues are introduced in
Section 4. Related issues that do not impose requirements on FCP
directly are listed in Section 5. Section 6 illustrates FCP usage by
examples. Security considerations are described in Section 7 and
status of this memo in Section 8.
SIP
SIP +---------+_____________ |
________|SIP Proxy| \ |
/ +---------+.. +----+---------------+
| : FCP +------+-----------+ |
| +----------+ :...........| | | |
| |management| | | Per-Flow | |
| | tools |..............| FCP | State | |
| +----------+ | unit | Table | |
| FTP +---------+.............| | | |
| _____|FTP Proxy|_____________+------+-----------+ |
| / +---------+ | Packet |
| | -----| Filter |
+-----------+ / +----+---------------+
+-----------+| data streams / |
+-----------+||----------------/ |
|end-devices|| (RTP, ftp-data, etc.) |
+-----------+ |
Inside | Outside
Legend: ---- raw data streams
____ application control protocols
.... Firewall Control Protocol
Figure 1: FCP Architecture
2 Terminology
o Endpoint address - general term describing source or destination of
a packet. This is, depending on context, IP address and/or TCP/UDP
port number.
o Packet flow _ a sequence of packets with identical source and
destination endpoint addresses.
o Session - a set of packet-flows belonging to an application.
o Session control protocol - a protocol used to negotiate endpoint
addresses of flows belonging to a session. Examples are SIP, H.323,
FTP control connection.
Internet Draft Firewall Control Protocol June 2000
o Flow descriptor - packet-matching expression describing a packet
flow or a group of them.
o Application Level Gateways (ALGs) - trusted, administrator-
maintained, application-aware entities acting on behalf of
untrusted hosts at the application layer. (ALGs are also called
proxies.)
o Packet filter - a network node that examines headers of forwarded
packets and allows only packets conforming to a security policy to
pass through. The security policy defines which endpoint addresses
are considered trustworthy and which are not. For example, it may
permit data traffic of an application only from/to ALGs.
o Network Address Translator (NAT) - a packet processing device that
is able to map source and/or destination endpoint addresses of
forwarded packet flows to a pool of other addresses. This technique
is used to conserve IP address space and/or hide IP address of
hosts behind the NATs from outside of the NATs. The NAT concept is
described in [15].
o Firewall - centrally maintained devices set-up to protect a network
from outside networks by putting restrictions on information flows.
The restrictions are applied with packet filters at the packet
level and/or ALGs at the application level. Optionally, NATs may be
used.
o Firewall Control Protocol - protocol used to control packet filters
using external controllers. The controllers MAY be ALGs such as SIP
proxies, management tools or any other hosts with authorized
access. There may be multiple controllers driving a packet filter
in parallel. A single controller may also control multiple filters
if needed. The protocol may be used between remote as well as co-
located nodes.
o Bind - association between end-point address and application.
Binding is usually implemented as API call if the receiving
application resides at the same host to which a sender sends
packets. If a packet relayer is in the middle of packet path, an
additional mechanism is needed to establish an association between
relayer's and receiver's endpoint.
3 Requirements for FCP
3.1 Management of Packet Flow Processing States
The primary goal of FCP is to allow for dynamic management of packet
filtering rules in a decomposed manner. From a general point of view
what the FCP does is it controls per-flow states. The following
requirements attempt to reach this abstraction and allow for easy
extension of the FCP to a generic 'flow-state control' protocol.
Such a protocol does not only allow to control filtering policy but
also any other control data associated with packet-flows.
In the remainder of the section 3.1 we assume a model in which
packet flows or classes of flows are identified by packet matching
expressions and associated with per-flow control states. The control
state determines how matched packets are handled. Both flow matching
expressions and associated states are manipulated by FCP.
Internet Draft Firewall Control Protocol June 2000
3.1.1 State Manipulation Operations
FCP MUST allow for setting, releasing and querying packet flow
processing rules. Operations like modification of existing rules and
keeping them alive are most likely to be implemented with the 'set'
operation. This increases protocol reliability in case of message
loss/duplication and/or failure of the controlled node.
The 'set' operation MAY either specify values of updated state
elements explicitly or omit them to allow controlled entities to
assign appropriate values. These MAY be default values (e.g. 0 for
packet counter), ephemeral values, or current values if the state
elements already exists (useful for keep-alive messages).
3.1.2 Packet Matching Expressions
This section specifies requirements for the language of packet
matching expressions. Note that FCP-controlled hosts have to
understand all expressions written in this language but FCP
controllers may use only a subset of them.
A) Matching expressions are used to identify packet flows or classes
of them. Experiences from packet filters like tcpdump [16] could
be adopted. As a minimum requirement, the language of packet
matching expression MUST allow for specification of the following
protocols and their respective header fields:
- IPv4: source and destination IP address or group of them,
protocol number, TOS field
- IPv6: source and destination IP address or group of them, next
header fields (Note that multiple fields may need to be
traversed until a match is found.), traffic class field
- UDP: port numbers
- TCP: port numbers, SYN, FIN, ACK and RST flags
- ICMP: type and code
- IGMP: type
Compatibility with ipsec selectors (see Section 4.4.2 in [22]) is
REQUIRED except the names that are subject to future extensions of
FCP.
B) Notion of packet filter interfaces is needed in the expressions
because different flow processing policies may apply at different
interfaces. For example, a packet filter may want to drop all
packets coming from the network inside of the firewall with source
address not belonging to the network [18]. Predefined interface
classes such as "in", "out", and "DMZ" (demilitarized zone) are
REQUIRED.
C) The ability to specify precedence is REQUIRED to enable
controlled nodes to resolve conflicts between multiple applicable
matching expressions. If no precedence is specified explicitly,
default precedence will be assigned by FCP-controlled node. Multiple
rules MAY share a single precedence.
Internet Draft Firewall Control Protocol June 2000
3.1.3 Control State Content
The control state associated with a packet matching expression MAY
include flow processing actions, timer information, encryption
policy, statistics, traffic limitations, etc. Members of the control
states are subject to future extensions. This section discusses core
control state members.
A) Actions define whether matched packets are processed. The
REQUIRED actions are 'passing packets' and 'dropping packets with or
without ICMP notification'.
B) Packet modifiers describe one or more rules for changing content
of matched packets if needed. For example, these rules may be
used to control network address/port translation or QoS
classification. The modifier rules will consist of identification
of the packet fields to be changed (syntax possibly a subset of
packet matching expression language), operators (at least the
assignment operator is required) and values. Modifier support is
OPTIONAL. If implemented, the modifier has to be able to change
the following protocol header fields:
- IPv4: IP addresses, TOS field
- IPv6: IP addresses, traffic class field
- UDP: port numbers
- TCP: port numbers
Note that packet filters implementing modifiers are REQUIRED to
recalculate packet checksums if a modifier is enabled.
C) State timer defines time remaining until state expiration. They
are REQUIRED. See also discussion of soft-state rule design in the
next section.
D) Unique flow state identifiers are REQUIRED unless matching
expressions are uniquely identifiable. Otherwise, state
modification/releasing would not work. The identifiers may be
generated either by clients or by servers. They may be random or
ephemeral. If clients generate them, they MUST be random to avoid
collisions. If controlled nodes generate identifiers, they MAY be
ephemeral. Ephemeral identifiers are typically shorter but lose
their uniqueness under a failure.
3.1.4 Soft-state 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 per-flow control states
is desirable. Since controllers are most likely to know best how
long the sessions can 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.
Internet Draft Firewall Control Protocol June 2000
3.1.5 Reflexive Rules
In order to allow replies to TCP/UDP data flows originated from the
internal side of firewall while still keeping the filtering policy
as restrictive as possible, so-called reflexive rules are used.
Reflexive rules are rules that allow packet flows reverse to
explicitly permitted active flows. They are defined implicitly by
permitting them within specification of the original explicit rules.
They specify the same protocol, IP addresses, port numbers as flows
matching the original rule do except the addresses and port numbers
are swapped. If permitted, packet filters generate a reflexive rule
if a new flow matches an explicit rule. No controller's intervention
is needed. The reflexive rules are valid only temporarily. They are
released when an inactivity timer expires, the flow is terminated
explicitly (e.g., by a FIN segment with TCP) or the original rule is
deleted. If endpoint address modifiers are enabled in the original
rules they MUST be reflected in the reflexive rules; namely packet-
matching expressions of the reflexive rules MUST match flows reverse
to modified flows and modifiers MUST be enabled to translate
endpoint addresses to addresses before modification.
FCP support for permitting generation of reflexive rules is
RECOMMENDED. If implemented, FCP MUST allow to specify their
inactivity timers, and to which interface they apply.
3.2 Responses
This section discusses content of FCP responses. FCP controllers
need to receive feedback on their control messages in order to learn
about results of requested operations. Positive responses indicate
successful operation and may possibly describe content of the
controlled states or part of them. Controlled state or part of it is
always returned if it was asked for by 'query' operation.
Negative responses indicate failures and describe reasons for them.
Minimum negative responses REQUIRED are "Authentication needed",
"Not permitted", "Syntax Error", "Unknown control state field", and
"Invalid control state field value".
3.3 Security
In order to prevent unauthorized entities from learning the firewall
state and controlling it the FCP channel MUST be private and
authenticated.
FCP privacy by encryption is REQUIRED since no general assumption
can be made about the privacy of transmission channel. The
encryption may take place either at lower layers (IPSec, TSL) or at
the FCP layer.
Though IP-address based authentication may be satisfactory in
particular cases cryptographic authentication is REQUIRED generally.
Note that the authentication takes place between FCP controllers and
Internet Draft Firewall Control Protocol June 2000
controlled node. Authentication mechanisms used between FCP-enabled
ALGs end ALG users are a separate issue out of scope of this memo.
3.4 Reliability
As with almost any other control protocol reliability is REQUIRED
regardless if it is implemented by FCP itself or an underlying
transport protocol.
3.5 Real-time Operation
The protocol transactions must be fast in terms of RTT to avoid
introducing delays to applications. Unless network loss results in
retransmission, total transaction time SHOULD be as close to one RTT
as possible.
Note: if TCP is used as underlying protocol to provide reliability,
pre-established TCP connections may be used to reduce transaction
time.
3.6 Extensibility
Protocol extensibility is REQUIRED in order to enable FCP to manage
arbitrary packet-flow processing state such as ipsec encryption
policies [22], accounting data, etc. In particular, adding new
control state fields, reply codes and elements of packet matching
expression language MUST be supported. The protocol MUST convey the
protocol version number in order to make the transition to potential
future versions easier.
3.7 Open Issues
3.7.1 Multicasting
Does control of multicasting flows introduce any challenges to FCP?
In particular, do multicasting flows require some specific state to
be maintained in the controlled packet processing devices?
3.7.2 Controller/Firewall Discovery
How to establish a relation between the controlled packet filters
and their controllers? Is this to be done administratively? Should a
discovery mechanism be deployed instead? If so, does it belong to
FCP's scope? Note that if deployed, the discovery mechanism MUST be
secure.
If there are multiple packet filters how does a controller know
which of them it should control in order to get an application
through a firewall? In fact, it is impossible unless the controller
knows routing tables along the path between end-devices and the
firewalls.
Internet Draft Firewall Control Protocol June 2000
3.7.3 Subscribe-Notify
The protocol MUST allow FCP controllers to request logging of
asynchronous events. Choice of the notification/logging mechanism
seems to be a configuration option. FCP is abstract and does not
mandate or specify the mechanism. Discussion is needed on:
o To what events could controllers subscribe? Probably to control-
state changes caused by explicit FCP operations, internal events
(e.g., timer expiration, exceeded number of permitted packets),
events triggered by matched packets, or all of them.
o Notification frequency. Generating a notification for every event
would certainly not be useful for events triggered by matched
packets. Instead, periodical notifications or notifications on
modulo n-th event would be useful.
3.7.4 NAT Support
Packet filters deploying NAT translate only endpoint addresses
conveyed in IP/UDP/TCP headers. ALGs are needed to translate
endpoint addresses conveyed in session control protocols. Thus,
external ALGs have to have the ability to query or/and set address
translations for use in session control. There are several questions
about how to support interaction of FCP controllers with NATs.
The first one is how does a controller know that the controlled node
deploys NAT. This knowledge is needed since FCP flows for scenarios
with NATs can differ from those without them. For example, a SIP
proxy must find out the address translation before forwarding an
INVITE if NAT is enabled. The same proxy does not have to do
anything at this call stage if no NAT is deployed. The knowledge of
NAT deployment may be statically configured in the FCP controllers
or preferably obtained with a protocol from controlled nodes. FCP
could be used for this purpose at the beginning of every
transaction. This alternative supports scenarios where NAT
selectively applies only to traffic from/to some hosts behind the
firewall without having to configure this policy in every single FCP
controller.
The next question is who manages the address translation.
Controller-driven NAT compels ALGs to maintain address pools.
Clearly more than one would expect from, for example, SIP proxy.
Additionally, synchronization of address pool management would need
to be solved for multiple controllers. Thus, management by
controlled nodes seems to be the more viable alternative.
In this case, FCP controllers MUST have the additional ability to
query and release a binding or group of them between private and
public endpoint addresses. Binding of address groups is needed, for
example, to accommodate RTP [21] which recommends allocation of even
port numbers for itself, subsequent port number for RTCP and
contiguous block of port numbers for layered encoding applications.
The bindings are subject to timer expiration in a similar way as
packet-filtering rules are.
Internet Draft Firewall Control Protocol June 2000
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. Mechanisms
for fast rule lookup in large, frequently changing filter databases
are needed. Results of some recent research in this area were
published in [7], [8], and [9].
Both complex packet matching expressions as well as complex actions
such as packet modification may affect filtering performance. The
trade-off between rule complexity and processing speed is left to be
resolved by administrator.
5 Related Issues
This Section explicitly names related features that are out of scope
of protocol requirements and are matter of implementation,
administrative policy or anything else.
5.1 Complex versus Fast Rules
As already noted in the Section on performance there is a trade-off
between complex and simple rules. Though FCP-controlled nodes must
understand all rules permitted by FCP language, execution of complex
rules may degrade their performance. The trade-off between complex
and simple rules is to be resolved by administrators of FCP
controllers.
5.2 Access Control
There may be different policies defining who may access and modify
what rules. For example, an access policy may specify that an FCP
controller may only control rules describing traffic to and from a
specific subnet. Additionally, it may define in which way the
controller is required to authenticate and which precedence it may
use for its rules. The access control policies are out of scope of
FCP. The only required FCP feature is authentication support.
5.3 State Ownership
Multiple controllers may control a single node with FCP. It is
desirable to avoid modification of per-flow control states by other
entities than those that created them (perhaps with exception of a
network manager). However, the state ownership is not a protocol but
packet filter requirement. The only required protocol functionality
is authentication.
Internet Draft Firewall Control Protocol June 2000
5.4 Default Flows
If a packet does not match any of matching expressions maintained in
a packet filter a default per-flow control state has to be applied.
Otherwise, packet handling would be undefined. Thus, all packet
filters controlled by FCP must always maintain the default rule. The
matching expression of the rule matches all packets at lowest
priority so that any other matching rules take precedence over it.
The content of the default control state may be modified with FCP,
the matching expression may not.
6 Examples
This section shows how to use FCP by examples. Many of the examples
are related to SIP because it is a prominent case of session control
protocols.
6.1 FCP Transaction Examples
This section illustrates how FCP requests could look like. The
requests in the following examples use abstract syntax in this form:
PME=
[ [=] ...]
The syntax of packet matching expression is borrowed from
tcpdump[16]. A keyword 'if' specifying at which filter's interface
the matching expression applies is added. A similar syntax is used
for definition of packet modifiers. Discussion on how these abstract
FCP examples map or do not map to existing protocols is out of scope
of this document.
In the examples bellow, a protected host behind the firewall has the
address 10.1.1.1, an outside host has the address 10.1.3.1 and the
packet filter has 10.1.2.42.
Example 1: Opening a Pinhole in a Packet Filter for an Outgoing Flow
In this example, a controller opens a pinhole for a packet flow
being sent from the inside to the outside host.
SET
PME='if in and udp src port 55 and src host 10.1.1.1 and udp dst
port 77 and dst host 10.1.3.1'
action=pass
=> REPLY: OK
Example 2: Opening a Pinhole in a Packet Filter w/NAPT for an
Outgoing Flow
In this example, a controller opens a pinhole for a packet flow
being sent from the outside to the inside host through a NAT. Before
Internet Draft Firewall Control Protocol June 2000
opening the pinhole, the controller queries network address
translations.
NAT_bind_incoming
PME='dst host 10.1.1.1 and udp dst port 55'
=> REPLY: NAT_OK, dst host 10.1.2.42 and udp dst port 66
SET
PME='dst host 10.1.2.42 and udp dst port 66 if out and src host
10.1.3.1 and udp src 77'
action=PASS
modifier='dst host = 10.1.1.1, udp dst port = 55'
=> REPLY: OK
Example 3: TOS Control
The controller instructs the controlled node to set TOS of matched
packets to hexadecimal value 0x10.
SET
PME='if in and udp src port 55 and src host 10.1.1.1 and udp dst
port 77 and dst host 10.1.3.1'
modifier='tos0x10'
=> REPLY: OK
Example 4: Querying Number of Matched Packets
QUERY
PME='if in and udp src port 55 and src host 10.1.1.1 and udp dst
port 77 and dst host 10.1.3.1'
packet_count
=> REPLY: OK, packet_count=333
Example 5: Refreshing Per-Flow State
SET
PME='if in and udp src port 55 and src host 10.1.1.1 and udp dst
port 77 and dst host 10.1.3.1'
=> REPLY: OK
Example 6: Prevention of Spoofed Packets Originating from Local
Network
See [18] for more details on this scenario.
SET
PME='if in and not src net 10.1.2'
action=drop(no_ICMP)
=> REPLY: OK
Internet Draft Firewall Control Protocol June 2000
Example 7: Reflexive HTTP Rules
The next rule allows controlled packet filters to create temporary
rules that permit inbound TCP packets for HTTP transactions
initiated from the internal side of firewall.
SET
PME='if in and tcp dst port 80'
REFLEXIVE='permit=yes, timer=180s, apply_to=out'
=> REPLY: OK
If an HTTP request from 10.1.1.1:37313 to 10.1.3.1:80 matches this
rule a reflexive rule of the following form is generated:
PME='if=out and tcp src port 80 and src host 10.1.3.1 and tcp dst
port 37313 and dst host 10.1.1.1'
Example 8: Packet Redirection
In this scenario, all HTTP traffic from inside network is redirected
to a Web proxy (10.1.4.4) transparently. This scenario is sometimes
also referred as 'transparent proxy'. The rule allows for automatic
creation of reflexive rules.
SET
PME='if in and tcp dst port 80'
modifier='ip dst host = 10.1.4.4'
reflexive_rules='permit=yes, inactivity_timer=240s, if=dmz'
=> REPLY: OK
If an HTTP request from 10.1.1.1:37313 to 10.1.3.1:80 matches this
rule a reflexive rule of the following form is generated:
PME='if=dmz and tcp src port 80 and src host 10.1.4.4 and tcp dst
port 37313 and dst host 10.1.1.1'
modifier='ip src host=10.1.3.1'
6.2 Using FCP to Get a SIP/SDP Session through a 'Default-Deny'
Firewall
This example illustrates how FCP can be used to get an outgoing SIP
call through a firewall deploying 'default-deny' packet filtering
policy. Network configuration as displayed in Figure 1 is assumed:
The packet filter allows SIP signaling only from/to a SIP proxy, the
proxy rejects calls considered untrustworthy, and instructs the
packet filter to open pinholes for RTP streams belonging to
trustworthy SIP/SDP sessions for the time of session duration.
Precise timing of opening and closing pinholes in SIP sessions and
issues such as 183 provisional media and re-invites are subject to
discussion which is out of scope of this document. Management of
Internet Draft Firewall Control Protocol June 2000
RTCP and ICMP pinholes is omitted for the sake of simplification.
Note that the pinholes in the packet filter are quiet 'wide'. This
means they allow packets with arbitrary source address and port
number to pass through because SDP does not communicate source
endpoint addresses.
Notation: In the diagram "INV 10.1.1.1:55" means an INVITE message
with the SDP body indicating IP address 10.1.1.1 with port 55 as the
receiving address and port for an incoming media-stream. Similarly
"200 OK 10.1.3.:77" indicates an OK response with IP address
10.1.3.1 and port 77 for receiving media. The value 0.0.0.0:0 stands
for any IP address and port number. Per-flow control states in this
example are identified by packet matching expressions.
+---------------------------------------------+--------------------+
| INSIDE | OUTSIDE |
+---------------------------------------------+--------------------+
10.1.1.1 10.1.2.42 10.1.3.1
UAC SIP Proxy AuthServer FW UAS
| | | | |
/* process SIP invitation; do not open firewall pinholes until
callee accepts the call */
| ----------------->| | | |
| INV 10.1.1.1:55 | | | |
| | ------> | | |
| | auth ? | | |
| | <------ | | |
| | OK auth | |
| | | |
| | -------------------------------------------> |
| | INV 10.1.1.1:55 |
/* process SIP OK, open pinholes for outgoing and incoming media
as soon as SIP ACK arrives */
| | <------------------------------------------- |
| | 200 OK 10.1.3.1:77 |
| <-----------------| | |
| 200 OK 10.1.3.1 77| | |
| ----------------->| | |
| ACK | ----------------------> | |
| |FCP SET | |
| |PME='dst udp 10.1.3.1:77 | |
| | src udp 0.0.0.0:0 | |
| | if=in', action=PASS | |
| | <---------------------- | |
| | FCP OK | |
| | ----------------------> | |
| |FCP SET | |
| |PME='dst udp 10.1.1.1:55 | |
| | src udp 0.0.0.0:0 | |
Internet Draft Firewall Control Protocol June 2000
| | if=out', action=PASS | |
| | <---------------------- | |
| | FCP OK | |
| | -------------------------------------------> |
| | ACK | |
| ...............................................................> |
| RTP DST 10.1.3.1:77 |
| <............................................................. |
| RTP DST 10.1.1.1:55 |
/* close pinholes when either party sends SIP BYE */
| | <------------------------------------------- |
| | BYE | |
| <---------------- | | |
| BYE | | |
| ----------------->| | |
| 200 OK | | |
| | ----------------------> | |
| |FCP RELEASE | |
| |PME='dst udp 10.1.3.1:77 | |
| | src udp 0.0.0.0:0 | |
| | if=in' | |
| | <---------------------- | |
| | FCP OK | |
| | ----------------------> | |
| |FCP RELEASE | |
| |PME='dst udp 10.1.1.1:55 | |
| | src udp 0.0.0.0:0 | |
| | if=out' | |
| | <---------------------- | |
| | FCP OK | |
| |--------------------------------------------> |
| | 200 OK | |
Figure 2: Protocol Flow for "SIP Session over Firewall"
6.3 Using FCP to Get a SIP/SDP Session through a NAT-enabled Firewall
This example is analogous to the previous one. Additionally, NAT is
deployed.
+---------------------------------------------+--------------------+
| INSIDE | OUTSIDE |
+---------------------------------------------+--------------------+
10.1.1.1 10.1.2.42 10.1.3.1
UAC SIP Proxy AuthServer NAT/FW UAS
| | | | |
| | | | |
/* process SIP invitation, bind to a public address for receiving
media, modify the invitation accordingly; do not open firewall
pinholes until both parties agree to establish a call; note
Internet Draft Firewall Control Protocol June 2000
that binding of source address for outgoing media is not done
because SDP does not care about source addresses */
| ----------------->| | | |
| INV 10.1.1.1:55 | | | |
| | ------> | | |
| | auth ? | | |
| | <------ | | |
| | OK auth | | |
| | | | |
| | ----------------------> | |
| |FCP bind_incoming | |
| | dst udp 10.1.1.1:55 | |
| | <---------------------- | |
| | OK dst udp 10.1.2.42:66 | |
| | -------------------------------------------> |
| | INV 10.1.2.42:66 |
/* process SIP OK, open NAT-enabled pinholes for outgoing and
incoming media as soon as SIP ACK arrives */
| | <------------------------------------------- |
| | 200 OK 10.1.3.1:77 |
| <-----------------| | |
| 200 OK 10.1.3.1 77| | |
| ----------------->| | |
| ACK | ----------------------> | |
| |FCP SET | |
| |PME='dst udp 10.1.3.1:77 | |
| | src udp 0.0.0.0:0 | |
| | if=in', action=PASS | |
| | <---------------------- | |
| | FCP OK | |
| | ----------------------> | |
| |FCP SET | |
| |PME='dst udp 10.1.2.42:66| |
| | src udp 0.0.0.0:0 | |
| | if=out', action=PASS , | |
| |modifier='dst udp | |
| | 10.1.1.1:55' | |
| | <---------------------- | |
| | FCP OK | |
| | -------------------------------------------> |
| | ACK | |
| ...............................................................> |
| RTP DST 10.1.3.1:77 |
| <...........................................~................... |
| RTP DST 10.1.1.1:55 RTP DST 10.1.2.42:66 |
/* close pinholes when either party sends SIP BYE */
| | <------------------------------------------- |
| <---------------- | BYE | |
| BYE | | |
Internet Draft Firewall Control Protocol June 2000
| ----------------->| | |
| 200 OK | ----------------------> | |
| |FCP RELEASE | |
| |PME='dst udp 10.1.3.1:77 | |
| | src udp 0.0.0.0:0 | |
| | if=in' | |
| | <---------------------- | |
| | FCP OK | |
| | ----------------------> | |
| |FCP RELEASE | |
| |PME='dst udp 10.1.2.42:66| |
| | src udp 0.0.0.0:0 | |
| | if=out' | |
| | <---------------------- | |
| | FCP OK | |
| | ----------------------> | |
| |FCP release_bind | |
| | dst udp 10.1.1.1:55 | |
| | <---------------------- | |
| | OK | |
| | -------------------------------------------> |
| | 200 OK | |
Figure 3: Protocol Flow for "SIP Session over NAT"
6.4 SIP and Mobile IP through Firewalls
This section gives hints on how FCP could be used to set up firewall
traversal for Mobile IP [19]. In the following examples, mobility
agents use FCP to permit data flows belonging to authenticated
mobile hosts. Note that this kind of filtering policy is not as
detailed and restrictive as an application-aware policy.
A typical scenario is shown in Figure 4. A mobile node M moved from
its home subnet to another one during a SIP call. The foreign subnet
is located on the external side of the firewall protecting the home
subnet. The foreign network deploys no firewall. M is using a
foreign agent care-of address. Media streams between M and C are
shown in the figure, SIP signaling is omitted.
Foreign subnet Internet Home subnet
---------------------------------><-----------><--------------------
+-------+
| | C>M C>M
+------+ M>C | call | +--------+ +-----+
| |--------------------------->|party C| | | | |
|mobile| | |-->| home |-->|home |
| node | +-------+ +-------+ |firewall| |agent|
| M |<--|foreign|<===========================| |<==| |
+------+ |agent | +--------+ +-----+
+-------+ encapsulated
MM' permission remains unchanged.
3) The home agent may optionally forbid all outbound streams
originated by M.
If reverse tunneling for mobile IP [20] is used as shown in Figure
5, the home agent will instruct the firewall to open tunnels between
trusted foreign agents and the home agent. If there is a firewall
deployed in the foreign network the foreign agent uses FCP to open
tunnels in the same way. Note that considerable trust is delegated
to the peer domain since inbound tunneled traffic is accepted as is.
Applying packet-filtering rules to tunneled packets could be used
for more restrictive policy.
Foreign subnet Internet Home subnet
---------------------------------><-----------><--------------------
+-------+ CC | | C>M
+------+ +--------+ | call | +--------+ +-----+
| | | | |party C|<--| |<--| |
|mobile| |foreign | +-------+-->| home |-->|home |
| node |-->+-------+==>|firewall|==============>|firewall|==>|agent|
| M |<--|foreign|<==| |<==============| |<==| |
+------+ |agent | +--------+ +--------+ +-----+
+-------+ : encapsulated M<-----------><--------------------
+-------+
M>C | | C>M C>M
+------+ M>C +--------+ | call | +--------+ +-----+
| |-------------->| |-->|party C| | | | |
|mobile| |foreign | | |-->| home |-->|home |
| node | +-------+ |firewall| +-------+ |firewall| |agent|
| M |<--|foreign|<==| |<==============| |<==| |
+------+ |agent | +--------+ +--------+ +-----+
+-------+ :
:............: encapsulated
M2543, 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 Performance", 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.
Internet Draft Firewall Control Protocol June 2000
[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] S. McCanne, C. Leres, V. Jacobson: "tcpdump, the protocol packet
capture and dumper program"; available at
ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
[17] Rusty Russel: "Linux IP Firewalling Chains",
http://www.rustcorp.com/linux/ipchains/
[18] P. Ferguson, D. Senie: "Network Ingress Filtering: Defeating
Denial of Service Attacks which Employ IP Source Address
Spoofing", RFC 2267, IETF, January 1998.
[19]C. Perkins: "IP Mobility Support", RFC 2002, IETF, October 1996.
[20] C. Montenegro: "Reverse Tunneling for Mobile IP", RFC 2344, May
1998.
[21] Shulzrinne, Casner, Frederick, Jacobson: "RTP: A Transport
Protocol for Real-Time Applications", Internet Draft, Internet
Engineering Task Force, March 2000, Work in progress.
[22] S. Kent, R. Atkinson: "Security Architecture for the Internet
Protocol", RFC 2401, IETF, November 1998.
B Glossary of Abbreviations
ALG Application Level Gateway
DMZ Demilitarized Zone
FCP Firewall Control Protocol
FTP File Transfer Protocol
IP Internet Protocol
HTTP Hypertext Transfer Protocol
MAC Message Authentication Check
MTU Maximum Transmission Unit
NAT Network Address Translation
NAPT Network Address Port Translation
RTP Transport Protocol for Real-time Applications
RTT Round Trip Time
SDP Session Description Protocol
SIP Session Initiation Protocol
TCP Transmission Control Protocol
TOS Type of Service
UDP User Datagram Protocol
D Authors' Addresses
Jiri Kuthan
GMD Fokus
Kaiserin-Augusta-Allee 31
D-10589 Berlin, Germany
E-mail: kuthan@fokus.gmd.de
Internet Draft Firewall Control Protocol June 2000
Jonathan Rosenberg
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07052
email: jdrosen@dynamicsoft.com
E Full Copyright Statement
Copyright (c) The Internet Society (2000). All Rights Reserved.
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 implementation 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.