One document matched: draft-bajko-nsis-fw-reqs-00.txt
NSIS Working Group Gabor Bajko
Internet Draft Franck Le
Document: <draft-bajko-nsis-FW-reqs-00.txt> Nokia
Michael Paddon
Qualcomm
Trevor Plestid
RIM
February, 2005
Requirements for Firewall Configuration Protocol
Status of this Memo
This document is an Internet-Draft and is subject to all
provisions of Section 3 of RFC 3667. By submitting this Internet-
Draft, each author represents that any applicable patent or other
IPR claims of which he or she is aware have been or will be
disclosed, and any of which he or she become aware will be
disclosed, in accordance with RFC 3668.
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.
This Internet-Draft will expire on August 5, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
1. Abstract
This document defines requirements for a Firewall Configuration
Protocol, has been produced by a number of 3GPP2 member companies
and presents their view for the requirements to a next generation
firewall configuration protocol.
1
Requirements for Firewall Configuration Protocol
February 2005
With the number of threats that keep increasing on the Internet,
many networks have decided to deploy firewalls to reduce the
possible risks and protect their users as well as their network
resources. Firewalls can however present many issues with new
protocols, applications and scenarios to be supported. Data packets
may be discarded at the firewalls. In addition, the clients may
often be the only parties that know the requirements and details of
the data communications. This document therefore explains why a
protocol allowing clients to configure firewalls would be useful,
and attempts to identify the requirements and features to be
supported by such a protocol.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
3. Table of Content
Status of this memo
1. Abstract 1
2. Conventions used in this document 2
3. Table of contents 2
4. Introduction 2
5. Requirements 4
5.1 Functional Requirements 4
5.1.1 Pinholes creation 4
5.1.2 Creation of Pinholes without knowing the CN 5
5.1.3 Pinholes deletion 6
5.1.4 Packet filters 6
5.1.5 States update 7
5.1.6 Transport protocol preferences and firewall configuration 7
5.1.7 Efficient use of the air interface 7
5.1.8 IP version 8
5.1.9 Firewall Features 8
5.2 Security Requirements 8
6. References 8
7. Appendix 8
8. AuthorÆs Addresses 9
4. Introduction
While the numbers of attacks keeps increasing with Denial of
Service, Distributed Denial of Service, virus, worms and other forms
of attacks, many networks are deploying firewalls to reduce the
threats.
Firewalls can however introduce several issues with new protocols,
applications, and scenarios to be supported. To mention few
examples, firewalls and Mobile IPv6 do not work well together [1].
Firewalls may present issues to many features, considered important
NSIS Working Group Expiration 8/14/05 2
Requirements for Firewall Configuration Protocol
February 2005
parts of the Mobile IPv6 protocol, such as Route Optimization which
may not be used in the presence of firewalls. Most firewalls are
also configured to block unsolicited incoming traffic. Connections
are typically authorized only when initiated by nodes in the network
protected by the firewalls. While this allows to reduce unwanted IP
traffic, such configuration may compromise the use of arbitrary peer
to peer protocols/applications, and may prevent end points in
networks protected by such firewalls to host servers.
Different approaches have been proposed to solve theabove listed
problems: Application-Level-Gateways (ALGs) that by analyzing the
signaling messages, create and remove the necessary pinholes in the
firewalls, have been developed; protocols allowing Application
Severs (AS) to create and delete pinholes in firewalls have also
been specified. However, it has to be noted that often, the end
point is the only party that knows the details and requirements of
the data communications:
a) Relying on some existing network entities (e.g. ALG, AS) to
interpret the signaling and open the pinholes in the firewalls may
result in misconfiguration: the created pinholes may not correspond
to the incoming and outgoing traffic, and the data packets may be
dropped at the firewalls (e.g. an end point may establish a
communication using SIP&SDP and may decide to use IPsec to protect
the media stream. If pinholes are created based on SIP&SDP
signaling, the final data packets may not match the pinholes.
Similar problems exist if Mobile IP is used: the packets may differ
from the states created in the firewalls).
b) Existing network entities may not have the ability to verify the
validity/authenticity of the signaling. E.g. Mobile IPv6 has been
designed to be an end-to-end protocol. A firewall on the path may
not know if a Binding Update is valid or a forged one. Only the end
point, thanks to the Return Routability Test, and thanks to the
IPsec Security Association with its Home Agent can know it. A
firewall cannot therefore know whether the states for the Mobile
Node should be updated or not, upon detecting a Binding Update
message.
c) For P2P protocols and applications, and for scenarios where the
end point wants to host a server, the end point is typically the
only entity that knows the requirements of the pinholes to be
created in the firewalls.
d) A key criteria is that the protocol supports extensibility for
higher level msessages. For example the protocol may want to define
different firewalls modes of operation. An example: for a given node
behind a firewall, existing stateful packet filtering technology
deals with it acting as an initiating endpoint. The node should
however also be able to act as a soliciting endpoint, where a
soliciting end point response to an initiating endpoint outside the
firewall creates pinholes.
NSIS Working Group Expiration 8/14/05 3
Requirements for Firewall Configuration Protocol
February 2005
A protocol allowing an end point to configure the firewall(s) or at
least indicating its requirements to the network would solve these
problems. Actually such protocol could also increase the security
since in some attacks as illustrated in the Overbilling one [2], end
points were forced to receive unwanted traffic and had to pay for
the undesired received data. A protocol allowing the end point to
install packet filters that block the unwanted traffic would prevent
such attack.
NOTE: Packets in the FW are (de)selected by matching them against a
set of "pinholes". A pinhole, as used in this document, is a
specification of acceptable ranges for various fields that may occur
in a packet.
5. Requirements
The following sections describe the requirements for such a
protocol. Based on different use cases, useful features are
identified and described. The security requirements are also
analyzed.
5.1 Functional Requirements
5.1.1 Pinholes creation
A client SHOULD be able to create pinholes and specify the
characteristics of the pinholes to be installed in the firewalls.
A client SHOULD be able to specify pinhole characteristics such that
any desired subset of the packets directed to the node will be
passed by the firewall. Characteristics should include (but not be
limited to) all IP headers and upper layer protocol headers.
A client SHOULD be able to specify pinholes that admit classes of
packets, i.e. a single pinhole should permit ranges of values in
header fields. (The mechanism must be efficient; 1000 ports
shouldn't equate to 1000 rules).
A client SHOULD be able to specify pinholes that refer to
encapsulated headers (Mobile IP or tunneling) or routing options
(Mobile IPv6).
A client SHOULD be permitted to open pinholes specifying any
internal address associated with it. A client MUST NOT be permitted
to open pinholes which specify internal addresses not associated
with it (e.g. multihoming case).
The following describes use cases where such capability is needed:
a) SIP-established-communications
NSIS Working Group Expiration 8/14/05 4
Requirements for Firewall Configuration Protocol
February 2005
After agreeing on the IP addresses and the ports on where to receive
the media stream, the node needs to open the appropriate pinholes in
the firewalls for the media traffic.
The end point should have a mean to indicate the characteristics
(e.g. IP addresses/port numbers) of the pinholes that need to be
installed in the firewalls. This mechanism must not be incompatible
with the standard statefull firewall pinholes creation mechanism.
NOTE: A stateful firewall is a firewall that keeps track of the
state of network connections (such as TCP streams) traveling across
it.
b) Mobile IP Home Agent
When a MN changes its location, it typically acquires a local IP
address (Care of Address). When that happens, several IP addresses
can be used by the MN for sending/receiving packets (e.g., HoA, CoA,
Home AgentÆs address), and those may take different format
(encapsulated, not encapsulated, etc.). If corresponding pinholes
are not opened, the firewall may block the packets. Similar issues
exist with MIPv6 signalling messages (e.g. HoTI, CoTI). Detailed
description can be found in [1].
The node should have a means to specify the required pinholes (e.g.
for the MIPv6 signalling, and for the incoming packets from the HA)
to one or more firewalls.
c) In some environments (e.g. 3GPP GPRS access) nodes possess a
network prefix for one of their interface, instead of one specific
address and may want to accept packets to a range of destination
addresses; or, a node behind a FW may want to accept connections for
a range of ports (e.g. default ones) or from a range of source
addresses;
5.1.2 Creation of Pinholes without knowing the CN
The end point SHOULD be able to create pinholes with wildcard for
any field (e.g. port number, IP address, etc.)
Such capabilities are useful in the following scenarios:
a) The end point should be able to open pinholes even without
knowing the characteristics (e.g. IP address) of its correspondent
nodes. This feature is needed for applications where the end point
does not yet know the CN: the end point may e.g. want to host a
server (FTP, HTTP) or run applications such as P2P.
b) This feature is also needed for the Mobile IPv6 protocol since a
Mobile Node may e.g. send a Binding Update from an IP address that
NSIS Working Group Expiration 8/14/05 5
Requirements for Firewall Configuration Protocol
February 2005
is not known before. The MIPv6 Correspondent Node needs to open the
pinholes to accept such Binding Update to allow Route Optimization.
5.1.3 Pinholes deletion
A client SHOULD be able to close any or all the pinholes it created
with a single protocol instance.
A client SHOULD be able to suggest a pinhole timeout. A firewall
SHOULD be able to override such suggestions.
A client SHOULD be able to refresh all associated pinhole timeouts
with a single protocol instance.
The protocol MUST have a means to allow a trusted 3rd party to take
an action instead of the client.
Such capabilities are useful in the following scenarios:
a) The client should be able to close a pinhole it created. The end
point may host a server but later, for different reasons, the end
point may decide not to host server anymore. Therefore, the end
point should be able to close the pinholes to stop incoming packets
at the network. This is particularly important for access networks
with limited bandwidth. The end point should also be able to close
all pinholes it created without listing them (e.g. a rebooting
node).
b) When opening the pinholes, each of the pinholes should be
associated with a lifetime to ensure that no pinholes are left in
the firewalls.
5.1.4 Packet filters
The protocol MUST support specifying the action to be taken for
packets matching the packet filters. For each packet filter, the
protocol MUST be able to indicate whether packets matching the
filter should 'PASS' or if the firewall should 'DROP' them. The
actions MUST be extendable.
Such capabilities are useful in the following scenarios:
a) Restricting the packets: the end point may have opened a pinhole
to accept packets from a specific node. However the end point may
not want to receive a specific type of packets from this end point
(e.g. packets with specific flags on). The end point could also have
opened a pinhole to accept incoming requests in the case it is
hosting a server. The end point may however have a list of nodes it
does not want to receive requests from.
b) Restricting the services: some service may be authorized by
default by the local network policy. The end point may however not
NSIS Working Group Expiration 8/14/05 6
Requirements for Firewall Configuration Protocol
February 2005
need such services and may prefer to drop the corresponding packets
at the firewall not to waste the access network resources.
c) Blocking Overbilling attack: Allowing the end point to install
filters in the firewall prevents the overbilling attacks
5.1.5 States update
The client SHOULD be able to update the pinholes and/or packet
filters installed in the firewall.
The client SHOULD be able to update the firewall states by
providing:
a) the fields to be updated
b) the values for the fields to be updated
This capability is useful in the following scenarios:
a) The end point may e.g. be a Mobile IPv6 Node and may change its
Care of Address. As described in [1], there is the need to update
the states in the firewall (section 4.3), otherwise data packets
will be dropped at the firewalls.
b) The end point may be changing its IP address for privacy reasons
(RFC 3041). The end point may have installed different filters rules
in the firewalls and in that case, the end point also has to update
the states in the firewalls for the filters to become applicable to
the new IP address.
c) Closing the previous rules and recreating new ones for the new
value may unnecessarily consume network resources (e.g. access link)
especially if there are many rules, and introduce latency to the
procedure.
5.1.6 Transport protocol preferences and firewall configuration
The granularity of the rules SHOULD allow an end point to specify
the TCP flags, and other transport protocol related information
(e.g. the end point should have the ability to specify that it does
not want to receive TCP SYN packets.
The protocol MUST be extendable to allow further more complex
actions.
The rationale is that there is an expected need to have to define
additional firewall mechanism in addition to setting pinholes. An
example is setting particular countermeasures, or specific filtering
mechanisms, or specific firewall modes of operation.
5.1.7 Efficient use of the air interface
NSIS Working Group Expiration 8/14/05 7
Requirements for Firewall Configuration Protocol
February 2005
The protocol SHOULD allow an end point to create, modify or delete
several firewall states with one protocol instance.
This capability is useful in some wireless networks, where the
access link resources are limited. This would reduce the overhead
and the delay of the procedures.
5.1.8 IP version
The protocol SHOULD be applicable both for IPv4 and IPv6.
5.1.9 Firewall features
The protocol SHOULD allow the client to learn the features
implemented in the FW and whether those are enabled or disabled.
The protocol SHOULD allow the client to configure the Firewall (e.g.
enable/disable a feature in the FW).
This capability is useful in the following scenarios:
Certain Firewalls implement different features aimed to protect
nodes within the network, like TCP Sequence Verifier or SYN Relay.
These features however, may prevent nodes in establishing end-to-end
communications using certain protocols (e.g. IPSec can not be used
with FWs implementing SYN Relay). Knowing in advance the features
enabled in the Firewall may help nodes choosing adequate protocols
and succeed with end-to-end communication.
5.2 Security requirements
The firewall MUST prevent an end point to update/close firewall
pinholes opened by other nodes, and to modify/delete a packet filter
installed by other nodes (to avoid fraud).
The firewall configuration protocol SHOULD not open the opportunity
for nodes to flood a target.
The client SHOULD be able to integrity protect and/or encrypt the
messages it sends to the firewall.
6. References
[1] Franck Le, Stefano Faccin, Basavaraj Patil, Hannes Tschofenig,
ôMobile IPv6 and Firewalls, Problem statementö IETF Internet
draft, August 2004.
[2] S.P0103-0, Network Firewall Configuration and Control, 3GPP2
TSG-S, Dec 2004.
7 Appendix
NSIS Working Group Expiration 8/14/05 8
Requirements for Firewall Configuration Protocol
February 2005
The following requirements represent requirements for Firewalls, and
are provided herein for information.
A firewall MUST be able to verify which internal addresses an
initiating endpoint is granted for use.
A firewall MUST limit the resources (especially memory and CPU time)
that a soliciting endpoint can consume.
The firewall SHOULD block outgoing packets with spoofed source
addresses (this might require the firewall to be able to associate
allocated addresses with link layer identifiers, i.e. PPP tunnels,
MAC addresses, etc.).
The firewall SHOULD reject requested pinholes that do not comply
with a predetermined policy.
Extensible actions
Examples of these extendable actions and firewall modes of operation
are;
-to specify firewall behavior for specific protocols, such as pass
all SIP packets
-to specify the configuration is being performed by a proxy, and
that the end node is not capable of self configuration, such that
default configuration may be applied to the firewall for that end
node
-to specify unique firewall behaviors for that end node only, such
as allow the firewall to operate in æsymetrical stateful firewallÆ
mode, allowing only the first ænÆ packets of an originating endpoint
outside the firewall to reach the solicting endpoint inside the
firewall. A soliciting end point response to an initiating endpoint
outside the firewall creates pinholes. This may be defined as a
æsymetrical stateful firewallÆ
-rate limiting of originating source IP to a particular end point
- allow a max number of "partially opened" sessions, 'fully opened'
defined after the CN source IP responds to packets from the MN
firewall sends packets to MN on behalf of the originating source to
properly complete an 'open' session, where for example the MN is a
server to prevent DOS attacks such as SYN ACK.
- For a particular protocol, the firewall provides the response to
the soliciting node outside the firewall, instead of the end node
inside the firewall. When a packet response comes back from the
soliciting node, then we have a authorized pinhole also known not to
be spoofed. Also, subsequent originating packets from the end node
also causes a pinhole. Otherwise subsequent incoming packets from
the soliciting node are permanently blocked (for that particular end
node only) Example is TCP SYN packets
8. Author's Addresses
NSIS Working Group Expiration 8/14/05 9
Requirements for Firewall Configuration Protocol
February 2005
Gabor Bajko
Nokia
e-mail: gabor.bajko@nokia.com
Franck Le
Nokia
e-mail: franck.le@nokia.com
Michael Paddon
Qualcomm
e-mail: mwp@qualcomm.com
Trevor Plestid
RIM
e-mail: tplestid@rim.com
NSIS Working Group Expiration 8/14/05 10
Requirements for Firewall Configuration Protocol
February 2005
Full Copyright Statement
Copyright (C) The Internet Society (year). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights."
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 implmentation 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."
NSIS Working Group Expiration 8/14/05 11
| PAFTECH AB 2003-2026 | 2026-04-24 07:36:26 |