< draft-kuthan-fcp-01.txt   draft-kuthan-fcp-02.txt >
Internet Engineering Task Force Jiri Kuthan Internet Engineering Task Force Jiri Kuthan
Internet Draft GMD Fokus Internet Draft GMD Fokus
draft-kuthan-fcp-01.txt Jonathan Rosenberg draft-kuthan-fcp-02.txt Jonathan Rosenberg
June, 2000 dynamicsoft November, 2000 dynamicsoft
Expires: December 2000 Expires: May 2001
Firewall Control Protocol Framework and Requirements Middlebox Communication: Framework and Requirements
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The purpose of this document is to collect and put under discussion The purpose of this document is to develop framework and
requirements for a protocol allowing for decomposition of requirements for a protocol that will allow for communicating
application-awareness from packet processing in firewalls. The control data associated with IP/transport-layer data flows or
protocol will be used by application-aware entities to control aggregates of them between intermediate packet processing devices
packet flows of applications traversing firewalls dynamically. This and external controllers.
kind of control allows applications using session control protocols
to traverse firewalls while still retaining restrictive packet The protocol will be extensible in order to allow for communicating
filtering policy. Network management tools may also utilize the arbitrary control data associated with packet flows and defining
protocol to manage packet-processing policies. We suggest an packet flow processing. It will include provisions for verifying the
extensible framework that may be used for management of arbitrary integrity of each message as well as ensuring authentication of all
per-flow control states in network nodes. parties involved in the transactions.
A major application of this protocol will be the control of packet
processing policies in decomposed firewalls/NATs/NAT-PTs by
externalized Application Level Gateways. This particular use will
relieve firewalls/NATs from application-layer processing to improve
their maintainability and performance.
Examples of other possible applications include but are not limited
to buffer management and load balancing.
Contents
1 Introduction.....................................................2
2 Terminology......................................................3
3 Case Study: Traversal of Applications Using Session Control
Protocols across Firewalls/NATs ..................................5
4 Protocol Requirements for FCP....................................7
4.1 FCP Operational Model..........................................7
4.2 Functional Requirements: Management of Packet Flow Processing
States .........................................................7
4.3 Rule Manipulation Operations...................................7
4.4 Soft-state Rule Design.........................................7
4.5 Rule Language..................................................7
4.5.1 Packet Matching Expressions..................................8
4.5.2 Rule Processing Precedence...................................8
4.5.3 Control State Content........................................9
4.6 Feedback......................................................10
4.7 Security......................................................11
4.8 Reliability...................................................11
4.9 Real-time Operation...........................................11
4.10 Extensibility................................................11
4.11 On Support Specific to NAT/NAPT/NAT-PT.......................12
5 Related Issues..................................................13
5.1 Access Control................................................13
5.2 Rule Ownership................................................13
5.3 Default Flows.................................................13
5.4 Location of FCP Controllers...................................14
6 Open Issues.....................................................14
6.1 Location of Intermediate Devices..............................14
7 Performance and Scalability Considerations......................15
8 Security Considerations.........................................15
9 Document Status.................................................15
10 Acknowledgments................................................16
1 Introduction 1 Introduction
Firewalls are trusted, administrator-maintained devices used to Though the Internet has been designed to provide network layer
protect networks from external attacks by enforcing restrictions on connectivity end to end [2] it actually consists of mixed network
information flows. The restriction policies are centrally defined realms. These include IPv4 networks, IPv6 networks, networks hidden
and maintained by network administrators. The firewalls consist of behind NATs and firewalls. This problem was referred to as
Application Level Gateways (ALGs) and packet filters. ALGs are "transparency loss" and discussed in [3]. Applications being run
application-aware entities acting on behalf of untrusted hosts at across mixed realms may experience lack of interoperability or
application layer. They examine application protocol flows and allow suboptimal performance.
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
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 To assists applications in traversing network boundaries Application
restrictive. It is frequently deployed in corporate networks. Level Gateways (ALGs) embedded in intermediate devices have been
Unfortunately, it makes firewall traversal difficult for used. However, tight coupling of application and network/transport
applications that use session bundles. This means that such layer processing results in reduced maintainability of the
applications (e.g., SIP [1], H.323 [2], and FTP [3]) negotiate IP intermediate devices. Built-in application awareness typically
addresses and port numbers with a session control protocol requires updates of operating systems with new applications or
dynamically and then use the negotiated addresses to establish versions of it. Operators of such systems wanting to support new
packet streams for transport of raw data. This technique is useful, applications cannot use software supplied by third parties and are
for example, if multiple applications want to receive RTP [21] flows at the mercy of vendors of their equipment. Furthermore, support of
and cannot share the same TCP/UDP port number or an application uses numerous application protocols increases complexity of such
port numbers to demultiplex multiple incoming RTP flows. It is also integrated systems and may affect performance.
necessary if IP address information is dynamic.
Without a kind of firewall control these applications cannot open To deal with this sort of problems we suggest decomposition of
firewall pinholes for their data streams dynamically. Additionally, application awareness from network/transport layer processing. We
they need to query or set address translations for their packet assume that applications control network/transport layer processing
flows if the packet filters deploy network address translation in intermediate devices through a generic application-independent
(NAT)[15]. Only then will they be able to include the translated control protocol. In the common case, the application-awareness
addresses in their session control protocols. resides in proxies ("externalized ALGs") that hide boundary
traversals from end-devices.
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 +----------+ FCP | | Per-Flow | |
for implementation of very fine security policies that meet +----------+|..........| | State | |
application needs but still remain restrictive. Decomposition of | ALGs ||..........| FCP | Table | | policy +--------+
application-awareness from packet processing is likely to increase +----------+ | unit |-----------| | protocol | policy |
performance of packet filters and make maintenance of the | | ACL ~~~~~~~~~~~~~~+ server |
application-awareness easier. Application logic residing in __________+------+-----------+ | +--------+
arbitrary external ALGs may be used for this purpose without having | Intermediate |
to make packet filters understand the individual applications. End- | Device |
devices do remain unchanged. The only needed extension is a control +--------------------+
protocol between the ALGs and packet filters. Device | |
Interfaces | | ...
IN OUT ...
Legend: .... FCP
~~~~ policy protocol
For example, a trusted, administrator-maintained SIP may open Figure 1: Middlebox Communication Architecture
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 The rest of this document describes framework and requirements for
between the packet filters and their controllers. We call this the missing piece, the control protocol. We refer to this protocol
protocol "Firewall Control Protocol" (FCP). We use the term FCP to as Flow Processing Control Protocol (FCP). Discussion on how FCP
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 maps or does not map to an existing protocol is out of scope of this
document. document. Section 2 defines terms used throughout this memo. In
Section 3, we demonstrate the use of the FCP in a case study. We
formulate protocol requirements in Section 4. Issues that are
related to protocol operation but do not affect protocol
specification are summarized in Section 5. Unresolved issues are
identified in Section 6. Section 7 reviews performance issues.
Security is considered in Section 8 and status of this memo in
Section 9.
The FCP framework is described as follows. Section 2 defines terms 2 Terminology
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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",
SIP +---------+_____________ | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
________|SIP Proxy| \ | this document are to be interpreted as described in RFC 2119.
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 matching expression - expression that specifies values of
header fields of packets to be selected. The inspected header
fields MAY be but are not limited to source and destination IP
addresses, TCP/UDP port numbers, etc.
o Packet flow - a sequence of packets matched by a packet matching
expression.
o Rule - a packet matching expression and control state used to
determine processing of packets matched by the expression.
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 of such
protocols are SIP, H.323, RTSP.
o Proxy - an intermediary server that relays application messages
from one entity to another one. A proxy acts as server for message
senders and as client on behalf of the senders for message
receivers. It may be used for enforcement of application-level
policies such as content filtering or message translation. With
applications using session control protocols, proxies typically
relay session control protocols and do not relay data flows
belonging to a session.
o Packet filter - a network device 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 identified
by a port numbe only from/to a trusted proxy.
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 [10].
o Bind - a pair consisting of an original and translated endpoint
address.
o Intermediate device - a packet-processing device located along
end-to-end path. It may be a packet filter, NAT, intrusion
detection system, load balancer, etc.
o Firewall - centrally maintained devices set-up to increase network
security by putting restrictions on information flows. The
restrictions are applied with packet filters at the packet level
and/or proxies at the application level. Optionally, NATs may be
used. Note that the term "firewall" is sometimes used to refer to
packet filters.
o Application Level Gateways (ALGs) - application-aware modules that
control processing state in firewalls/NATs and manipulate
application messages to accomplish firewall/NAT traversal.
Typically, ALGs are embedded in firewalls/NATs. They may also be
externalized to remote proxies if a control interface between them
and firewalls/NATs is provided [4].
o Flow Processing Control Protocol (FCP) - protocol for
communicating flow processing policy between external controllers
and intermediate devices. The intermediate devices accept only
authorized FCP requests. The authorization can come from an
internal access control list or an external policy server.
o Access Control List (ACL) - policy defining who may
access/manipulate controlled devices with FCP. The ACLs may be
outsourced to an external policy server.
3 Case Study: Traversal of Applications Using Session Control Protocols
across Firewalls/NATs
Firewalls are trusted, administrator-maintained devices used to
increase network security by enforcing restrictions on information
flows. The restriction policies are centrally defined and maintained
by network administrators. The firewalls consist of proxies and
packet filters. Proxies 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 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 proxies to pass through. It
provides higher security by being more restrictive. Thus, it is
frequently deployed in corporate networks.
Unfortunately, this policy makes firewall traversal difficult for
applications using session bundles. This means that such
applications (e.g., SIP [5], H.323 [6], RTSP[7], and FTP
[8])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 data. This technique is
useful, for example, if multiple applications want to receive RTP
[9] 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.
As a result, dynamically created sessions fail to traverse firewalls
deploying static 'default-deny' filtering policies. If network
address translation (NAT)[10] is deployed the traversal fails as
well because session signaling conveys unroutable IP addresses and
port numbers. This problem has been addressed in firewalls/NATs by
usage of embedded Application Level Gateways (ALGs) [15]. They adapt
packet processing policy to application needs dynamically. However,
embedded ALGs suffer from limited maintainability, increase
complexity of firewalls/NATs and fail to operate if message
authentication or encryption is used.
Thus we suggest using external application proxies that control
firewalls/NATs and relieve them from application processing.
Arbitrary application proxies may be added to manageable firewalls
easily. Hop-by-hop security is enabled. Existing software such as
SIP proxies or H.323 gatekeepers may be used without duplicating the
applications' protocol stacks in the firewalls/NATs. The reference
scheme is depicted in Figure 2:. There are FCP-enabled, trusted,
administrator-maintained proxies acting as external ALGs and
controlling a packet filter located within the same administrative
domain. The packet filter implements the 'default-deny' packet
filtering policy. It permits session control traffic from and to the
trusted proxies and accepts FCP requests from them. The proxies use
their application-awareness to control the packet filter dynamically
with FCP. They also enforce application-level policy such as
dropping messages infected with known viruses, or lacking user
authentication. The policy decisions may be delegated to an external
policy server.
+--------+
| App. |
| Policy | +---------+ SIP
| Server |~~~~~~~~~| SIP +_____________ |
+--------+ ________| Proxy | \ |
/ +---------+.. +----+---------------+ / +---------+.. +----+---------------+
| : FCP +------+-----------+ | | : FCP +------+-----------+ |__
| +----------+ :...........| | | | | RSTP +----------+ :...........| | Per-Flow | |__
| |management| | | Per-Flow | | SIP | ____| RSTP |..............| | State | |__
| | tools |..............| FCP | State | | | / | Proxy |______________| FCP | Table | |
| +----------+ | unit | Table | | | | +----------+ | unit | -------- | |
| FTP +---------+.............| | | | | | FTP +---------+.............| | ACL | |
| _____|FTP Proxy|_____________+------+-----------+ | | | _____|FTP Proxy|_____________+------+-----------+ |
| / +---------+ | Packet | | | / +---------+ | Packet |
| | -----| Filter | | | | -----| Filter |--
+-----------+ / +----+---------------+ +-----------+ /-----| |--
+-----------+| data streams / | +-----------+| data streams // +----+---------------+
+-----------+||----------------/ | +-----------+||----------->----// |
|end-devices|| (RTP, ftp-data, etc.) | |end-devices||------------<----- |
+-----------+ | +-----------+ (RTP, ftp-data, etc.) |
Inside | Outside Inside | Outside
Legend: ---- raw data streams Legend: ---- raw data streams
____ application control protocols ____ application control protocols
.... Firewall Control Protocol .... FCP
~~~~ policy protocol
Figure 1: FCP Architecture
2 Terminology
o Endpoint address - general term describing source or destination of Figure 2: Use of FCP for Firewall/NAT Decomposition
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.
o Flow descriptor - packet-matching expression describing a packet 4 Protocol Requirements for FCP
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 4.1 FCP Operational Model
3.1 Management of Packet Flow Processing States In the remainder of this document we assume a model in which packet
processing in an intermediate device located at a network edge is
determined by an ordered set of rules. The rules consist of packet
matching expressions and control state. The packet matching
expressions select packets and associated control state determines
how selected packets are treated. A packet may match multiple packet
matching expressions. If this happens the first one will be taken.
The rules are manipulated with FCP dynamically. Multiple FCP
controllers MAY control a single intermediate device. It is expected
that only a few trusted hosts from a single administrative domain
will act as FCP controllers.
The primary goal of FCP is to allow for dynamic management of packet 4.2 Functional Requirements: Management of Packet Flow Processing
filtering rules in a decomposed manner. From a general point of view States
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 The primary goal of FCP is to allow for remote dynamic management of
packet flows or classes of flows are identified by packet matching packet flow processing rules. As a minimum requirement, the FCP MUST
expressions and associated with per-flow control states. The control enable controllers to permit/forbid processing of specific packet
state determines how matched packets are handled. Both flow matching flows and request/release NAT/NAPT/NAT-PT[11] translations.
expressions and associated states are manipulated by FCP.
3.1.1 State Manipulation Operations 4.3 Rule Manipulation Operations
FCP MUST allow for setting, releasing and querying packet flow FCP MUST allow for setting, releasing and querying packet flow
processing rules. Operations like modification of existing rules and processing rules. Operations like modification of existing rules and
keeping them alive are most likely to be implemented with the 'set' keeping them alive are most likely to be implemented with the 'set'
operation. This increases protocol reliability in case of message operation.
loss/duplication and/or failure of the controlled node.
The 'set' operation MAY either specify values of updated state The 'set' operation MAY either specify values of updated state
elements explicitly or omit them to allow controlled entities to elements explicitly or omit them to allow controlled entities to
assign appropriate values. These MAY be default values (e.g. 0 for assign appropriate values. These MAY be default values (e.g. 0 for
packet counter), ephemeral values, or current values if the state packet counter), ephemeral values, or current values if the state
elements already exists (useful for keep-alive messages). elements already exists (useful for keep-alive messages).
3.1.2 Packet Matching Expressions 4.4 Soft-state Rule Design.
To avoid accumulation of stale rules in case of controller failures
rules MUST have timers that expire if they are no more refreshed by
controllers. FCP MUST enable controllers to refresh rules
periodically. FCP MUST also allow controllers to set the timer's
length -- it is frequently a controller that knows best what timer
length is appropriate. If a controller does not specify timer value
explicitly a default value will be assigned. A trivial value for
infinite timer MUST be defined.
4.5 Rule Language
This section specifies requirements for the language of packet This section specifies requirements for the language of packet
matching expressions. Note that FCP-controlled hosts have to rules. Note that FCP-controlled hosts have to understand all
understand all expressions written in this language but FCP expressions written in this language but FCP controllers may use
controllers may use only a subset of them. only a subset of them.
A) Matching expressions are used to identify packet flows or classes 4.5.1 Packet Matching Expressions
of them. Experiences from packet filters like tcpdump [16] could
be adopted. As a minimum requirement, the language of packet A) As a minimum requirement, the language of packet matching
matching expression MUST allow for specification of the following expressions MUST allow for specification of the following
protocols and their respective header fields: protocols and their respective header fields:
- IPv4: source and destination IP address or group of them, - IPv4: source and destination IP address or group of them
protocol number, TOS field determined by a netmask, protocol number, TOS field
- IPv6: source and destination IP address or group of them, next - IPv6: source and destination IP address or group of them
header fields (Note that multiple fields may need to be determined by a netmask, next header fields (Note that multiple
traversed until a match is found.), traffic class field fields may need to be traversed until a match is found.),
- UDP: port numbers traffic class field
- TCP: port numbers, SYN, FIN, ACK and RST flags - UDP: source and destination port numbers or group of them
- ICMP: type and code - TCP: source and destination port numbers or group of them, "SYN
- IGMP: type packets" permission
Compatibility with ipsec selectors (see Section 4.4.2 in [22]) is - ICMP: type and code
REQUIRED except the names that are subject to future extensions of - IGMP: type
FCP.
B) Notion of packet filter interfaces is needed in the expressions B) FCP controllers MUST be able to specify in which direction
because different flow processing policies may apply at different packets may traverse controlled devices. This requires notion of
interfaces. For example, a packet filter may want to drop all device interfaces. The notion of interface is abstract and
packets coming from the network inside of the firewall with source independent on interface technology and assigned IP address.
address not belonging to the network [18]. Predefined interface Support for generic predefined interface names "in", "out",
classes such as "in", "out", and "DMZ" (demilitarized zone) are "loopback" (synonym for senders and receivers located at the
REQUIRED. controlled device), and "DMZ" (demilitarized zone) is REQUIRED.
Packet traversal direction may be expressed in various ways, for
example by inbound and outbound interfaces or by interface and
direction in which packets pass it.
C) The ability to specify precedence is REQUIRED to enable 4.5.2 Rule Processing Precedence
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.
3.1.3 Control State Content The ability to indicate desired rule processing precedence is
REQUIRED to enable controlled devices to resolve conflicts between
multiple applicable matching rules in a predictable manner. If no
precedence is specified for a rule, default precedence will be
assigned by FCP-controlled device. Multiple rules MAY share a single
precedence.
The control state associated with a packet matching expression MAY Note: Though precedence sharing leaves processing order of rules
include flow processing actions, timer information, encryption with the same precedence undetermined it greatly simplifies
policy, statistics, traffic limitations, etc. Members of the control certain common cases. For example, allocating a single precedence
states are subject to future extensions. This section discusses core for all dynamically generated firewall pinholes does not affect
control state members. firewall's behavior because all the pinhole rules result in the
same action, which is packet forwarding. Then none of multiple FCP
controllers needs to determine at which position a new rule will
be inserted in a rule base.
A) Actions define whether matched packets are processed. The 4.5.3 Control State Content
REQUIRED actions are 'passing packets' and 'dropping packets with or
without ICMP notification'.
B) Packet modifiers describe one or more rules for changing content The control state associated with a packet matching expression in a
of matched packets if needed. For example, these rules may be rule keeps information related to a packet flow. It MAY include flow
used to control network address/port translation or QoS processing actions, timer information, number of matched packets,
classification. The modifier rules will consist of identification traffic limitations, etc. Members of the control states are subject
of the packet fields to be changed (syntax possibly a subset of to future extensions.
packet matching expression language), operators (at least the
assignment operator is required) and values. Modifier support is The following control state members are REQUIRED:
OPTIONAL. If implemented, the modifier has to be able to change
A) "Action" defines whether matched packets are forwarded. It takes
the values 'pass packets', 'drop packets with or without ICMP
notification'.
B) "Rule timer" defines time remaining until state expiration. See
also discussion of soft-state rule design.
C) "Logging" of asynchronous events related to a rule. The protocol
MUST allow FCP controllers to request logging of asynchronous
events such as packet match and timer expiration. The protocol
MUST enable controllers to specify log level and frequency. The
log frequency is used to avoid voluminous logging if an event
occurs frequently. Choice of the notification/logging mechanism
is a configuration option that does not need to be specified with
FCP.
D) Unique "flow state identifiers" are REQUIRED unless matching
expressions are uniquely identifiable. Otherwise, state
modification/releasing could not work consistently. The
identifiers may be generated either by controllers or by
controlled devices. They may be random or ephemeral. If
controllers generate them, they MUST be random to avoid
collisions with identifiers generated by other controllers. If
controlled devices generate identifiers, they MAY be ephemeral.
Ephemeral identifiers are typically shorter but lose their
uniqueness under a failure.
E) "Packet modifier" allows to describe one or more rules for re-
writing header fields of matched accepted packets. The modifier
rules will consist of identification of the packet fields to be
changed, operators (at least the assignment operator is REQUIRED)
and operands. In particular, the modifier MUST be able to change
the following protocol header fields: the following protocol header fields:
- IPv4: IP addresses, TOS field - IPv4: IP addresses, TOS field
- IPv6: IP addresses, traffic class field - IPv6: IP addresses, traffic class field
- UDP: port numbers - UDP: port numbers
- TCP: 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 Note that if modifiers are used packet checksums MUST be
are REQUIRED. See also discussion of soft-state rule design in the recalculated.
next section.
D) Unique flow state identifiers are REQUIRED unless matching The following control state members are RECOMMENDED:
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. F) "Packet counter" keeps number of packets matched by a rule.
Opening dynamic pinholes in firewalls makes only sense if they are G) "Maximum packets per second" specifies the maximum allowed packet
closed on session termination. To avoid unreleased rules due to rate of a flow. Packets exceeding this rate will be dropped.
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.
3.1.5 Reflexive Rules H) "Maximum bitrate" specifies the maximum allowed bitrate of a
flow. Packets exceeding this rate will be dropped.
In order to allow replies to TCP/UDP data flows originated from the I) "Inactivity timer" specifies period of time after which a rule is
internal side of firewall while still keeping the filtering policy released if no packet matches.
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 J) "Reflexive Rules": In order to allow replies to TCP/UDP data
RECOMMENDED. If implemented, FCP MUST allow to specify their flows originated from the internal side of firewall while still
inactivity timers, and to which interface they apply. 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 their generation 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
whenever a new flow matches an explicit rule. No controller's
intervention is needed. The reflexive rules are valid only
temporarily. They MUST be 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 creation of
reflexive rules is supported, FCP MUST allow to specify values of
their control state members.
3.2 Responses Note: 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 of reverse flow to addresses before
modification.
This section discusses content of FCP responses. FCP controllers 4.6 Feedback
need to receive feedback on their control messages in order to learn
about results of requested operations. Positive responses indicate FCP controllers need to receive feedback on their control messages
successful operation and may possibly describe content of the in order to learn about results of requested operations. Both
controlled states or part of them. Controlled state or part of it is positive and negative responses are REQUIRED.
always returned if it was asked for by 'query' operation.
Positive responses indicate successful operation and MAY possibly
describe content of the controlled states or part of them. Per-flow
control 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. Negative responses indicate failures and describe reasons for them.
Minimum negative responses REQUIRED are "Authentication needed", Minimum negative responses REQUIRED are "Authentication failed",
"Not permitted", "Syntax Error", "Unknown control state field", and "Not permitted", "Syntax Error".
"Invalid control state field value".
3.3 Security 4.7 Security
In order to prevent unauthorized entities from learning the firewall In order to prevent unauthorized entities from manipulating the
state and controlling it the FCP channel MUST be private and state of controlled device the FCP channel MUST be secure. It MUST
authenticated. include provisions for verifying the integrity of each message as
well as ensuring authentication of all parties involved in the
transaction.
FCP privacy by encryption is REQUIRED since no general assumption It is RECOMMENDED that the FCP channel is private so that a
can be made about the privacy of transmission channel. The malicious listener cannot find out packet processing policy easily.
encryption may take place either at lower layers (IPSec, TSL) or at
the FCP layer. The security protocols may take place either at lower layers (IPSec,
TSL) or at the FCP layer.
Though IP-address based authentication may be satisfactory in Though IP-address based authentication may be satisfactory in
particular cases cryptographic authentication is REQUIRED generally. particular cases cryptographic authentication is REQUIRED generally.
Note that the authentication takes place between FCP controllers and
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 Note that we discuss the security between FCP controllers and
controlled device. Security mechanisms used by applications to
communicate with FCP controllers are a separate issue out of
scope of this memo.
4.8 Reliability
As with almost any other control protocol reliability is REQUIRED As with almost any other control protocol reliability is REQUIRED
regardless if it is implemented by FCP itself or an underlying regardless if it is implemented by FCP itself or an underlying
transport protocol. transport protocol.
3.5 Real-time Operation 4.9 Real-time Operation
The protocol transactions must be fast in terms of RTT to avoid The protocol transactions must be fast in terms of RTT to avoid
introducing delays to applications. Unless network loss results in introducing delays to applications. Unless network loss results in
retransmission, total transaction time SHOULD be as close to one RTT retransmission, total transaction time SHOULD be 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 Note: If TCP is used as underlying protocol to provide
reliability, pre-established TCP connections may be used to
reduce transaction time.
How to establish a relation between the controlled packet filters 4.10 Extensibility
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 Protocol extensibility is REQUIRED in order to enable reuse of FCP
which of them it should control in order to get an application for control of a variety of packet-processing mechanisms. In
through a firewall? In fact, it is impossible unless the controller particular, adding new control state fields (e.g., buffer management
knows routing tables along the path between end-devices and the information), new reply codes and elements of packet matching
firewalls. expression language MUST be supported.
3.7.3 Subscribe-Notify The protocol MUST convey protocol version number in order to make
transition to potential future versions easier.
The protocol MUST allow FCP controllers to request logging of 4.11 On Support Specific to NAT/NAPT/NAT-PT
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 One of the FCP purposes is to communicate NAT/NAPT/NAT-PT binds
between controllers and controlled devices. Knowledge of the binds
is necessarily needed by session control proxies to operate
properly.
Packet filters deploying NAT translate only endpoint addresses The primary question is who creates the binds. One alternative is
conveyed in IP/UDP/TCP headers. ALGs are needed to translate controllers request a new bind and NATs create and return it. The
endpoint addresses conveyed in session control protocols. Thus, other choice is the controllers create a bind and instruct NATs to
external ALGs have to have the ability to query or/and set address use it.
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 Locating the bind logic in NATs follows the decomposition concept
deploys NAT. This knowledge is needed since FCP flows for scenarios "IP/transport intelligence in controlled devices, application
with NATs can differ from those without them. For example, a SIP intelligence out of them". It relieves controllers such as SIP
proxy must find out the address translation before forwarding an proxies from maintenance of the address pools and making bind
INVITE if NAT is enabled. The same proxy does not have to do assignments. It avoids collisions that would be due if multiple
anything at this call stage if no NAT is deployed. The knowledge of controllers would access a single device. (We do not consider
NAT deployment may be statically configured in the FCP controllers splitting a pool of public addresses among multiple controllers a
or preferably obtained with a protocol from controlled nodes. FCP solution. It would beat the purpose of NAT which is address
could be used for this purpose at the beginning of every sharing.)
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. A minor drawback of this logic placement is it requires two-stage
Controller-driven NAT compels ALGs to maintain address pools. transactions if NATs are co-located with firewalls. In the first
Clearly more than one would expect from, for example, SIP proxy. stage, a controller must find out, if NAT applies to a given address
Additionally, synchronization of address pool management would need and request a bind to include in its signaling. In the second stage,
to be solved for multiple controllers. Thus, management by when application signaling is over, it permits a packet flow using
controlled nodes seems to be the more viable alternative. the reserved translation. With bind logic residing in controllers,
both operations may be done jointly in the second phase and the
first phase can be skipped.
In this case, FCP controllers MUST have the additional ability to A specific scenario where locating the bind logic to controllers is
query and release a binding or group of them between private and advantageous is if a controller wants to make sure the same address
public endpoint addresses. Binding of address groups is needed, for translation is applied in multiple controlled devices. Clearly, this
example, to accommodate RTP [21] which recommends allocation of even would not be possible if the devices assigned the binds
port numbers for itself, subsequent port number for RTCP and independently.
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.
4 Performance Issues We leave the answer to location of bind intelligence to
configuration. It is REQUIRED that FCP supports both alternatives.
The following protocol operations are REQUIRED:
The 'default-deny-and-dynamic-open' filtering policy compels o FCP controllers MUST be able to request NAT translations. If NAT
stateful packet filters to maintain potentially huge tables of is used, controlled devices allocate an address translation and
filtering rules. The rule lookup-processing overhead grows with return it.
number of rules and may lead to increased packet latency. Mechanisms o FCP controllers MUST be able to set NAT translations. (Note that
for fast rule lookup in large, frequently changing filter databases this can be accomplished with modifiers.) Controlled devices MUST
are needed. Results of some recent research in this area were be able to indicate if the translation cannot be set because it is
published in [7], [8], and [9]. already reserved.
Both complex packet matching expressions as well as complex actions o With NAPT, allocating port blocks is REQUIRED, i.e., FCP
such as packet modification may affect filtering performance. The controllers MUST be able to request a translation of a contiguous
trade-off between rule complexity and processing speed is left to be block of port numbers and controlled devices MUST allocate a
resolved by administrator. contiguous block of translated port numbers to such request. The
least significant bit of both private and translated port numbers
MUST be same. It is needed, for example, by RTP [9], which
recommends allocation of even port numbers for itself, subsequent
port number for RTCP and contiguous block of port numbers for
layered encoding applications.
o The controllers MUST be able to release the allocated bindings.
o The allocated address bindings are subject to timer expiration in
a similar way as soft-state packet-processing rules are.
5 Related Issues 5 Related Issues
This Section explicitly names related features that are out of scope This Section explicitly names related features that are out of scope
of protocol requirements and are matter of implementation, of protocol requirements and are matter of implementation,
administrative policy or anything else. administrative policy or anything else.
5.1 Complex versus Fast Rules 5.1 Access Control
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 There may be different access control lists (ACLs) defining who may
what rules. For example, an access policy may specify that an FCP access and modify what rules in an intermediate device. For example,
controller may only control rules describing traffic to and from a an ACL may specify that an FCP controller may only control rules
specific subnet. Additionally, it may define in which way the describing traffic to and from a specific subnet. Additionally, it
controller is required to authenticate and which precedence it may may define in which way the controller is required to authenticate
use for its rules. The access control policies are out of scope of and which precedence it may use for its rules. The access control
FCP. The only required FCP feature is authentication support. policies may be stored and applied locally or they may be outsourced
to an external policy server using a policy protocol. In either case
they are out of scope of FCP. The only required FCP feature is
authentication support.
5.3 State Ownership 5.2 Rule Ownership
Multiple controllers may control a single node with FCP. It is Multiple controllers may control a single device with FCP. It is
desirable to avoid modification of per-flow control states by other desirable to avoid modification of per-flow control states by other
entities than those that created them (perhaps with exception of a entities than those that created them (perhaps with exception of a
network manager). However, the state ownership is not a protocol but network manager). Thus, the controlled devices MUST implement the
packet filter requirement. The only required protocol functionality notion of rule ownership. The only required protocol functionality
is authentication. is authentication.
5.4 Default Flows 5.3 Default Flows
If a packet does not match any of matching expressions maintained in 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. a packet filter a default rule has to be applied. Otherwise, packet
Otherwise, packet handling would be undefined. Thus, all packet handling would be undefined. Thus, all packet filters controlled by
filters controlled by FCP must always maintain the default rule. The FCP must always maintain the default rule. The matching expression
matching expression of the rule matches all packets at lowest of the rule matches all packets at lowest priority so that any other
priority so that any other matching rules take precedence over it. matching rules take precedence over it. The content of the default
The content of the default control state may be modified with FCP, control state MAY be modified with FCP, the matching expression MUST
the matching expression may not. NOT.
6 Examples 5.4 Location of FCP Controllers
FCP controllers may be located on any side of controlled network
device. Their location with respect to the controlled device does
not affect protocol specification but may result in different
protocol flows. For example, an application proxy located on the
private side of a NAT needs to set up a single permanent translation
that enables it to receive inbound messages and forward them to
their destinations. If the proxy is located on the public side, it
needs to set up multiple translations for inbound messages forwarded
to individual destinations located on the private side.
6 Open Issues
6.1 Location of Intermediate Devices
Determining which intermediate device a controller should control is
out of the scope of this document. Administrators can accomplish
this task manually. Alternatively, a discovery protocol could be
used.
A difficult problem arises if packet flows may take path through
multiple intermediate devices at the network edge. FCP controllers
cannot easily determine which of them they should control. The
problem is illustrated in the example depicted in Figure 3:
IN | OUT
+-----+ SIP +------------+ +-------+
| SIP |____________| firewall 1 |____________| SIP |
|proxy|............| | | proxy |
+-----+ : +------------+ +-------+
| : FCP ... | |
| MGCP : +------------+ MGCP |
| :.......|firewall i | |
+--------+ : +------------+ +-------+
|media | : ... | ?<-------|media |
|gateway |--->? : +------------+ |gateway|
+--------+ :..|firewall N | +-------+
+------------+
|
Figure 3: Controlling Multiple Intermediate Devices
In this example, multiple firewalls 1 .. N are present in a network.
A SIP proxy relays SIP signaling, has knowledge of all the firewalls
and is authorized to control them. It knows source and destination
endpoints of data flows belonging to a session but does not know
which of the firewalls they will traverse. It cannot calculate it
because it does not know routing tables along the entire end-to-end
path.
Solutions are still sought. A possible solution is to let
controllers instruct all controlled devices in parallel, most likely
using multicast. This solution scales only for a small number of
controlled devices. With NAT, it assumes the translation assignments
to be communicated from FCP controllers to controlled devices.
7 Performance and Scalability Considerations
The ability to add processing rules to control packet-processing
devices dynamically may result in creation of large and rapidly
changing rule tables. For example, if FCP is used to open pinholes
in a 'default-deny-and-dynamic-open' firewall for Internet telephony
sessions the table size grows with number of sessions linearly. The
lookup processing overhead grows as well and may lead to increased
packet latency. Maintenance of per-flow states makes use of FCP
meaningful only in network edges.
Mechanisms for fast rule lookup in large, frequently changing filter
databases are needed. Results of some recent research in this area
were published in [12], [13], and [14]. Use of packet modification
may also affect processing performance.
A performance improvement may be reached administratively by
definition of an application-aware rule precedence policy. A
controller may request that rules for packet flows with higher
expected packet rate will be assigned a higher precedence than rules
for packet flows with lower packet rate. Then, the most commonly
accessed rules will be processed first and average packet processing
time will decrease. Note that this mechanism is not extremely fair
to streams with low bandwidth consumption since their processing
time will increase.
8 Security Considerations
The security requirements for the control protocol are described in
Section 4.7. Note that security of the protocol does not help alone.
Additionally, security of the entire control system is subject to
security of the FCP controllers and access control in FCP-controlled
devices (see Section 5.1.).
9 Document Status
This document is in the stage of collection of requirements and open
issues. Numerous updates result from discussions on the foglamps
mailing list. Previous versions were issued as draft-kuthan-fcp-
{00|01}.txt.
10 Acknowledgments
Numerous people have been contributing to collection of these
requirements. Many document clarifications and enhancements resulted
from discussions on the foglamps mailing list. We specially
acknowledge the following people for their help: Scott Bradner,
Stefan Foeckel, Melinda Shore, Dave Oran, and Jon Peterson. The
firewall traversal problem was stated in [15], [16].
Appendixes
A Examples
This section shows how to use FCP by examples. Many of the 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 refer to the application described in Section 3 and use SIP as a
protocols. prominent example of a session control protocol.
6.1 FCP Transaction Examples A.1 FCP Transaction Examples
This section illustrates how FCP requests could look like. The This section illustrates how FCP requests could look like. The
requests in the following examples use abstract syntax in this form: requests in the following examples use abstract syntax in this form:
<state manipulation operation> <state manipulation operation>
PME=<packet matching expression> PME=<packet matching expression>
[<control-state-element-id> [=<value>] ...] [<control-state-element-id> [=<value>] ...]
The syntax of packet matching expression is borrowed from The syntax of packet matching expression is borrowed from tcpdump.
tcpdump[16]. A keyword 'if' specifying at which filter's interface An additional keyword 'if' specifies interface to whose incoming
the matching expression applies is added. A similar syntax is used queue the matching expression is applied. A similar syntax is used
for definition of packet modifiers. Discussion on how these abstract for definition of packet modifiers. Discussion on how these abstract
FCP examples map or do not map to existing protocols is out of scope FCP examples map or do not map to existing protocols is out of scope
of this document. of this document.
In the examples bellow, a protected host behind the firewall has the In the examples bellow, a protected host behind a firewall has the
address 10.1.1.1, an outside host has the address 10.1.3.1 and the address 10.1.1.1, an outside host has the address 130.149.17.15 and
packet filter has 10.1.2.42. the firewall's outbound interface has 193.174.152.25.
Example 1: Opening a Pinhole in a Packet Filter for an Outgoing Flow 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 In this example, a controller opens a pinhole for a packet flow
being sent from the inside to the outside host. being sent from the inside to the outside host.
SET SET
PME='if in and udp src port 55 and src host 10.1.1.1 and udp dst 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' port 77 and dst host 130.149.17.15'
action=pass action=pass
=> REPLY: OK => REPLY: OK
Example 2: Opening a Pinhole in a Packet Filter w/NAPT for an Example 2: Opening a Pinhole in a Packet Filter w/NAPT for an
Outgoing Flow Outgoing Flow
In this example, a controller queries a NAT bind and opens a pinhole
for a translated packet flow being sent from the outside to the
inside host through a NAT.
In this example, a controller opens a pinhole for a packet flow QUERY_NAT_TRANSLATION
being sent from the outside to the inside host through a NAT. Before udp:10.1.1.1:55
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 => REPLY: NAT_OK, udp:10.1.1.1:55=udp:193.174.152.25:48374
SET SET
PME='dst host 10.1.2.42 and udp dst port 66 if out and src host PME='dst host 10.1.1.1 and udp dst port 55 and if out and src host
10.1.3.1 and udp src 77' 130.149.17.15 and udp src 77'
action=PASS action=PASS
modifier='dst host = 10.1.1.1, udp dst port = 55'
=> REPLY: OK => REPLY: OK
Example 3: TOS Control Example 3: TOS Control
The controller instructs the controlled node to set TOS of matched The controller instructs the controlled device to set TOS of matched
packets to hexadecimal value 0x10. packets to hexadecimal value 0x10.
SET SET
PME='if in and udp src port 55 and src host 10.1.1.1 and udp dst 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' port 77 and dst host 130.149.17.15'
modifier='tos0x10' modifier='tos=0x10'
=> REPLY: OK => REPLY: OK
Example 4: Querying Number of Matched Packets Example 4: Querying Number of Matched Packets
QUERY QUERY
PME='if in and udp src port 55 and src host 10.1.1.1 and udp dst 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' port 77 and dst host 130.149.17.15'
packet_count packet_count
=> REPLY: OK, packet_count=333 => REPLY: OK, packet_count=333
Example 5: Refreshing Per-Flow State Example 5: Refreshing Per-Flow State
SET SET
PME='if in and udp src port 55 and src host 10.1.1.1 and udp dst 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' port 77 and dst host 130.149.17.15'
=> REPLY: OK => REPLY: OK
Example 6: Prevention of Spoofed Packets Originating from Local Example 6: Network Ingress Filtering
Network
See [18] for more details on this scenario. See [17] for more details on this scenario. The first rule denies
all packets on the "in" interface. The second rule with higher
priority explicitly permits packets from the 10.1.2 network.
SET SET
PME='if in and not src net 10.1.2' PME='if in'
precedence=default
action=drop(no_ICMP) action=drop(no_ICMP)
=> REPLY: OK => REPLY: OK
SET
PME='if in and src net 10.1.2'
precedence=high
action=pass
=> REPLY: OK
Example 7: Reflexive HTTP Rules Example 7: Reflexive HTTP Rules
The next rule allows controlled packet filters to create temporary The next rule allows controlled packet filters to create temporary
rules that permit inbound TCP packets for HTTP transactions rules that permit inbound TCP packets for HTTP transactions
initiated from the internal side of firewall. initiated from the internal side of a firewall.
SET SET
PME='if in and tcp dst port 80' PME='if in and tcp dst port 80'
REFLEXIVE='permit=yes, timer=180s, apply_to=out' REFLEXIVE='permit=yes, timer=180s, if=out'
=> REPLY: OK => REPLY: OK
If an HTTP request from 10.1.1.1:37313 to 10.1.3.1:80 matches this If an HTTP request from 10.1.1.1:37313 to 130.149.17.15:80 matches
rule a reflexive rule of the following form is generated: 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 PME='if=out and tcp src port 80 and src host 130.149.17.15 and tcp
port 37313 and dst host 10.1.1.1' dst port 37313 and dst host 10.1.1.1'
Example 8: Packet Redirection Example 8: Packet Redirection
In this scenario, all HTTP traffic from inside network is redirected In this scenario, all HTTP traffic from inside network is redirected
to a Web proxy (10.1.4.4) transparently. This scenario is sometimes to a Web proxy (10.1.4.4) transparently. This scenario is sometimes
also referred as 'transparent proxy'. The rule allows for automatic also referred as 'transparent proxy'. The rule allows for automatic
creation of reflexive rules. creation of reflexive rules.
SET SET
PME='if in and tcp dst port 80' PME='if in and tcp dst port 80'
modifier='ip dst host = 10.1.4.4' modifier='ip dst host = 10.1.4.4'
reflexive_rules='permit=yes, inactivity_timer=240s, if=dmz' reflexive_rules='permit=yes, inactivity_timer=240s, if=dmz'
=> REPLY: OK => REPLY: OK
If an HTTP request from 10.1.1.1:37313 to 10.1.3.1:80 matches this If an HTTP request from 10.1.1.1:37313 to 130.149.17.15:80 matches
rule a reflexive rule of the following form is generated: 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 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' port 37313 and dst host 10.1.1.1'
modifier='ip src host=10.1.3.1' modifier='ip src host=130.149.17.15
6.2 Using FCP to Get a SIP/SDP Session through a 'Default-Deny' A.2 Using FCP to Get an Outgoing SIP/SDP Session through a 'Default-
Firewall Deny' Firewall w/NAPT
This example illustrates how FCP can be used to get an outgoing SIP This example illustrates how FCP can be used to get an outgoing SIP
call through a firewall deploying 'default-deny' packet filtering call through a firewall deploying 'default-deny' packet filtering
policy. Network configuration as displayed in Figure 1 is assumed: policy. Network configuration as displayed in Figure 1 is assumed:
The packet filter allows SIP signaling only from/to a SIP proxy, the The packet filter allows SIP signaling only from/to a SIP proxy, the
proxy rejects calls considered untrustworthy, and instructs the proxy rejects calls considered untrustworthy, and instructs the
packet filter to open pinholes for RTP streams belonging to packet filter to open pinholes for RTP streams belonging to
trustworthy SIP/SDP sessions for the time of session duration. trustworthy SIP/SDP sessions for the time of session duration.
Additionally, NAPT is deployed.
Precise timing of opening and closing pinholes in SIP sessions and Precise timing of opening and closing pinholes in SIP sessions and
issues such as 183 provisional media and re-invites are subject to issues such as 183 provisional media and re-invites are subject to
discussion which is out of scope of this document. Management of discussion which is out of scope of this document. Management of
RTCP and ICMP pinholes is omitted for the sake of simplification. RTCP and ICMP pinholes is omitted for the sake of simplification.
Note that the pinholes in the packet filter are quiet 'wide'. This Note that the pinholes in the packet filter are quite 'wide'. This
means they allow packets with arbitrary source address and port means they allow packets with arbitrary source address and port
number to pass through because SDP does not communicate source number to pass through because SDP does not communicate source
endpoint addresses. endpoint addresses.
Notation: In the diagram "INV 10.1.1.1:55" means an INVITE message 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 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 receiving address and port for an incoming media-stream. Similarly
"200 OK 10.1.3.:77" indicates an OK response with IP address "200 OK 130.149.17.15: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 130.149.17.15 and port 77 for receiving media. The value 0.0.0.0:0
for any IP address and port number. Per-flow control states in this stands for any IP address and port number. Per-flow control states
example are identified by packet matching expressions. 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 | |
| | 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 | | INSIDE | OUTSIDE |
+---------------------------------------------+--------------------+ +---------------------------------------------+--------------------+
10.1.1.1 10.1.2.42 10.1.3.1 10.1.1.1 193.174.152.25 130.149.17.15
UAC SIP Proxy AuthServer NAT/FW UAS UAC SIP Proxy AuthServer NAT/FW UAS
| | | | | | | | | |
| | | | | | | | | |
/* process SIP invitation, bind to a public address for receiving /* process SIP invitation, bind to a public address for receiving
media, modify the invitation accordingly; do not open firewall media, modify the invitation accordingly; do not open firewall
pinholes until both parties agree to establish a call; note pinholes until both parties agree to establish a call; note
that binding of source address for outgoing media is not done that binding of source address for outgoing media is not done
because SDP does not care about source addresses */ because SDP does not care about source addresses */
| ----------------->| | | | | ----------------->| | | |
| INV 10.1.1.1:55 | | | | | INV 10.1.1.1:55 | | | |
| | ------> | | | | | ------> | | |
| | auth ? | | | | | auth ? | | |
| | <------ | | | | | <------ | | |
| | OK auth | | | | | OK auth | | |
| | | | | | | | | |
| | ----------------------> | | | | ----------------------> | |
| |FCP bind_incoming | | | |FCP query_nat | |
| | dst udp 10.1.1.1:55 | | | | udp :10.1.1.1:55 | |
| | <---------------------- | | | | <---------------------- | |
| | OK dst udp 10.1.2.42:66 | | | |OK udp:193.174.152.25:66 | |
| | -------------------------------------------> | | | -------------------------------------------> |
| | INV 10.1.2.42:66 | | | INV 193.174.152.25:66 |
/* process SIP OK, open NAT-enabled pinholes for outgoing and /* process SIP OK, open NAT-enabled pinholes for outgoing and
incoming media as soon as SIP ACK arrives */ incoming media as soon as SIP ACK arrives */
| | <------------------------------------------- | | | <------------------------------------------- |
| | 200 OK 10.1.3.1:77 | | | 200 OK 130.149.17.15:77 |
| <-----------------| | | | <-----------------| | |
| 200 OK 10.1.3.1 77| | | | 200 OK 130.149.17.15:77 | |
| ----------------->| | | | ----------------->|--------------------------------------------->|
| ACK | ----------------------> | | | ACK | ----------------------> | |
| |FCP SET | | | |FCP SET | |
| |PME='dst udp 10.1.3.1:77 | | | |PME='dst udp 130.149.17.15:77 |
| | src udp 0.0.0.0:0 | | | | src udp 0.0.0.0:0 | |
| | if=in', action=PASS | | | | if=in', action=PASS | |
| | <---------------------- | | | | <---------------------- | |
| | FCP OK | | | | FCP OK | |
| | ----------------------> | | | | ----------------------> | |
| |FCP SET | | | |FCP SET | |
| |PME='dst udp 10.1.2.42:66| | | |PME='dst udp 10.1.1.1:55 | |
| | src udp 0.0.0.0:0 | | | | src udp 0.0.0.0:0 | |
| | if=out', action=PASS , | | | | if=out', action=PASS | |
| |modifier='dst udp | |
| | 10.1.1.1:55' | |
| | <---------------------- | | | | <---------------------- | |
| | FCP OK | | | | FCP OK | |
| | -------------------------------------------> | | | -------------------------------------------> |
| | ACK | | | | ACK | |
| ...............................................................> | | ...............................................................> |
| RTP DST 10.1.3.1:77 | | UDP/RTP DST 130.149.17.15:77 |
| <...........................................~................... | | <...........................................~................... |
| RTP DST 10.1.1.1:55 RTP DST 10.1.2.42:66 | | UDP/RTP DST 10.1.1.1:55 UDP/RTP DST 193.174.152.25:66|
/* close pinholes when either party sends SIP BYE */ /* close pinholes when either party sends SIP BYE */
| | <------------------------------------------- | | | <------------------------------------------- |
| <---------------- | BYE | | | <---------------- | BYE | |
| BYE | | | | BYE | | |
| ----------------->| | | | ----------------->| | |
| 200 OK | ----------------------> | | | 200 OK | ----------------------> | |
| |FCP RELEASE | | | |FCP RELEASE | |
| |PME='dst udp 10.1.3.1:77 | | | |PME='dst udp 130.149.17.15:77 |
| | src udp 0.0.0.0:0 | | | | src udp 0.0.0.0:0 | |
| | if=in' | | | | if=in' | |
| | <---------------------- | | | | <---------------------- | |
| | FCP OK | | | | FCP OK | |
| | ----------------------> | | | | ----------------------> | |
| |FCP RELEASE | | | |FCP RELEASE | |
| |PME='dst udp 10.1.2.42:66| | | |PME='dst udp 10.1.1.1:55 | |
| | src udp 0.0.0.0:0 | | | | src udp 0.0.0.0:0 | |
| | if=out' | | | | if=out' | |
| | <---------------------- | | | | <---------------------- | |
| | FCP OK | | | | FCP OK | |
| | ----------------------> | | | | ----------------------> | |
| |FCP release_bind | | | |FCP release_bind | |
| | dst udp 10.1.1.1:55 | | | | udp 10.1.1.1:55 | |
| | <---------------------- | | | | <---------------------- | |
| | OK | | | | OK | |
| | -------------------------------------------> | | | -------------------------------------------> |
| | 200 OK | | | | 200 OK | |
Figure 3: Protocol Flow for "SIP Session over NAT" Figure 4: 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
M<C M<C
Figure 4: Firewall Traversal of SIP and Mobile IP
In this scenario, the following packet filtering policy could be set
up with FCP:
1) Home agent is allowed to send encapsulated mobile IP traffic
anywhere it wants through the firewall.
2) 'C>M' 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
---------------------------------><-----------><--------------------
+-------+ C<M
encapsulated M>C | | C>M
+------+ +--------+ | call | +--------+ +-----+
| | | | |party C|<--| |<--| |
|mobile| |foreign | +-------+-->| home |-->|home |
| node |-->+-------+==>|firewall|==============>|firewall|==>|agent|
| M |<--|foreign|<==| |<==============| |<==| |
+------+ |agent | +--------+ +--------+ +-----+
+-------+ : encapsulated M<C :...........:
:...........: FCP
FCP
Figure 5: Reverse Tunneling of SIP and Mobile IP
If reverse tunneling is not used and the foreign network deploys a
firewall the foreign agent can use FCP to permit data flows
originating from the mobile host. Otherwise, the packets would be
filtered out by anti-spoofing rules. See Figure 6.
Foreign subnet Internet Home subnet
---------------------------------><-----------><--------------------
+-------+
M>C | | C>M C>M
+------+ M>C +--------+ | call | +--------+ +-----+
| |-------------->| |-->|party C| | | | |
|mobile| |foreign | | |-->| home |-->|home |
| node | +-------+ |firewall| +-------+ |firewall| |agent|
| M |<--|foreign|<==| |<==============| |<==| |
+------+ |agent | +--------+ +--------+ +-----+
+-------+ :
:............: encapsulated
M<C FCP M<C
Figure 6: SIP and Mobile IP w/2 Firewalls
7 Security Considerations
The security requirements for the control protocol are described in
Section 3.3. Note that security of the protocol does not help alone.
Additionally, security of the entire control system is subject to
security of the FCP controllers and authentication policy installed
in the hosts under FCP control.
Security provided by FCP-controlled systems is subject to
administration policy maintained in FCP controllers.
8 Document Status
This document is in the stage of collection of requirements and open
issues. In the next stage, translation of the open issues into
requirements and discussion of all the requirements will follow.
Finally, the requirements will be mapped to protocols.
8 Acknowledgments
Numerous people contributed, are contributing and committed to
contribute to collection of these requirements. The firewall
traversal problem was stated in [11], [12].
Appendix B Bibliography
A Bibliography 1 S. Bradner: " The Internet Standards Process -- Revision 3", RFC
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg: "SIP: 1602, IETF, October 1996.
Session Initiation Protocol", RFC 2543, IETF, March 1999. 2 B. Carpenter: "Achitectural Principle of the Internet", RFC 1958,
[2] ITU-T Recommendation H.323. "Packet-based Multimedia IETF, June 1996.
Communications Systems," 1998. 3 B. Carpenter: "Internet Transparency", RFC 2775, IETF, February
[3] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", RFC 2000.
959, IETF. October 1985. 4 P. Srisuresh: " Framework for interfacing with Network Address
[4] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "The Simple Translator", IETF, Internet Draft, July 2000. Work in progress.
Network Management Protocol", RFC 1157, IETF, May 1990[5] M. 5 M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg: "SIP:
Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones: Session Initiation Protocol", RFC 2543, IETF, March 1999.
"SOCKS Protocol Version 5", RFC 1928, IETF, April 1996. 6 ITU-T Recommendation H.323. "Packet-based Multimedia
[6] Postel, J. and Reynolds, J.: "Telnet Protocol Specification", Communications Systems," 1998.
RFC 854, IETF, May 1983. 7 H. Schulzrinne, A. Rao, R. Lanphier: "Real Time Streaming
[7] A. Feldmann, S. Muthukrishnann: "Tradeoffs for Packet Protocol", RFC 2326, IETF, April 1998.
Classification", In Proc. IEEE INFOCOM 2000, 2000. 8 Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", RFC
[8] V. Srinivasan, S. Suri, G. Varghese: "Packet Classification 959, IETF. October 1985.
Using Tuple Space Search", In Proc. ACM SIGCOMM '99, 1999. 9 Schulzrinne, Casner, Frederick, Jacobson: "RTP: A Transport
[9] P. Gupta, N. McKeown: "Packet Classification on Multiple Protocol for Real-Time Applications", Internet Draft, Internet
Fields", In Proc. ACM SIGCOMM '99, 1999. Engineering Task Force, March 2000, Work in progress.
[10] J. Touch: "Report on MD5 Performance", RFC 1810, IETF, June 10 P. Srisuresh and M. Holdrege: "IP network address translator
1995. (NAT) terminology and considerations", RFC 2663, IETF, August
[11] J. Rosenberg, D. Drew, H. Schulzrinne: "Getting SIP through 1999.
Firewalls and NATs", Internet Draft, Internet Engineering Task 11 G. Tsirtsis, P. Srisuresh: "Network Address Translation -
Force, Feb. 2000. Work in progress. Protocol Translation (NAT-PT)", RFC 2766, IETF, February 2000.
[12] M. Shore: "H.323 and Firewalls: Problem Statement and Solution 12 A. Feldmann, S. Muthukrishnann: "Tradeoffs for Packet
Framework", Internet Engineering Task Force, Feb. 2000. Work in Classification", In Proc. IEEE INFOCOM 2000, 2000.
progress. 13 V. Srinivasan, S. Suri, G. Varghese: "Packet Classification Using
Tuple Space Search", In Proc. ACM SIGCOMM '99, 1999.
[13] S. Mercer, A. Molitor, M. Hurry, T. Ngo: "H.323 Firewall Control 14 P. Gupta, N. McKeown: "Packet Classification on Multiple Fields",
Interface (HFCI)", Nov. 1998. Expired Internet Draft. In Proc. ACM SIGCOMM '99, 1999.
[14] F. Baker: "IP Forwarding Table MIB", RFC 1354, IETF. July 1992. 15 J. Rosenberg, D. Drew, H. Schulzrinne: "Getting SIP through
[15] P. Srisuresh and M. Holdrege: "IP network address translator Firewalls and NATs", Internet Draft, Internet Engineering Task
(NAT) terminology and considerations", RFC 2663, IETF, August Force, Feb. 2000. Work in progress.
1999. 16 M. Shore: "H.323 and Firewalls: Problem Statement and Solution
[16] S. McCanne, C. Leres, V. Jacobson: "tcpdump, the protocol packet Framework", Internet Engineering Task Force, Feb. 2000. Work in
capture and dumper program"; available at progress.
ftp://ftp.ee.lbl.gov/tcpdump.tar.Z 17 P. Ferguson, D. Senie: "Network Ingress Filtering: Defeating
[17] Rusty Russel: "Linux IP Firewalling Chains", Denial of Service Attacks which Employ IP Source Address
http://www.rustcorp.com/linux/ipchains/ Spoofing", RFC 2827, IETF, May 2000.
[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 C Glossary of Abbreviations
ACL Access Control List
ALG Application Level Gateway ALG Application Level Gateway
DMZ Demilitarized Zone DMZ Demilitarized Zone
FCP Firewall Control Protocol FCP Flow Processing Control Protocol
FTP File Transfer Protocol FTP File Transfer Protocol
IP Internet Protocol IP Internet Protocol
HTTP Hypertext Transfer Protocol HTTP Hypertext Transfer Protocol
MAC Message Authentication Check MGCP Media Gateway Control Protocol
MTU Maximum Transmission Unit NAPT Network Address Port Translation
NAT Network Address Translation NAT Network Address Translation
NAPT Network Address Port Translation NAT-PT Network Address Translation - Protocol Translation
RTP Transport Protocol for Real-time Applications RTP Transport Protocol for Real-time Applications
RTSP Real Time Streaming Protocol
RTT Round Trip Time RTT Round Trip Time
SDP Session Description Protocol SDP Session Description Protocol
SIP Session Initiation Protocol SIP Session Initiation Protocol
TCP Transmission Control Protocol TCP Transmission Control Protocol
TOS Type of Service TOS Type of Service
UDP User Datagram Protocol UDP User Datagram Protocol
D Authors' Addresses D Authors' Addresses
Jiri Kuthan Jiri Kuthan
GMD Fokus GMD Fokus
Kaiserin-Augusta-Allee 31 Kaiserin-Augusta-Allee 31
D-10589 Berlin, Germany D-10589 Berlin, Germany
E-mail: kuthan@fokus.gmd.de E-mail: kuthan@fokus.gmd.de
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
200 Executive Drive 200 Executive Drive
Suite 120 Suite 120
West Orange, NJ 07052 West Orange, NJ 07052
email: jdrosen@dynamicsoft.com email: jdrosen@dynamicsoft.com
E Full Copyright Statement E Full Copyright Statement
Copyright (c) The Internet Society (2000). All Rights Reserved. Copyright (c) The Internet Society (2000). All Rights Reserved.
 End of changes. 127 change blocks. 
725 lines changed or deleted 764 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/