One document matched: draft-bajko-nsis-fw-reqs-04.txt
Differences from draft-bajko-nsis-fw-reqs-03.txt
NSIS Working Group Gabor Bajko
Internet Draft Nokia
Document: <draft-bajko-nsis-FW-reqs-04.txt> January, 2006
Requirements for Firewall Configuration Protocol
Status of this Memo
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 becomes aware will be disclosed, in
accordance with Section 6 of BCP 79.
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 January 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
1. Abstract
3GPP2 is working in specifying a way to allow the mobile network
subscribers to configure the Firewalls in their network according to
their needs[3].
This document defines requirements for a Firewall Configuration
Protocol. It has been produced by a number of 3GPP2 member companies
and endorsed by 3GPP2. It contains 3GPP2 requirements to a next
generation firewall configuration protocol.
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
1
Requirements for Firewall Configuration Protocol
January 2006
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 5
5.1.4 Packet filters 6
5.1.5 States update 6
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. Contributors 9
7. References 9
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
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
NSIS Working Group Expiration 07/01/06 2
Requirements for Firewall Configuration Protocol
January 2006
are typically authorized only when initiated by nodes in the network
protected by the firewalls. While this allows to reduce unsolicited
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, an end point
is the only party that is aware of the details and requirements
associated with 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.
A protocol allowing an end point to configure the firewall(s) or at
least indicating its requirements to the network would solve these
problems. Such protocol would also mitigate the risk of inaccurate
billing as indicated in [2], where an end point is forced to receive
unsolicited traffic and incur extra charges.
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 filter
with values or acceptable ranges for various fields that may occur
in a packet.
NSIS Working Group Expiration 07/01/06 3
Requirements for Firewall Configuration Protocol
January 2006
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 MUST be able to create pinholes and specify the
characteristics of the pinholes to be installed in the firewalls.
It MUST be possible for a client to specify pinholes containing
ranges of IP addresses, port numbers and SPI values.
A client MUST be able to specify pinholes that refer to encapsulated
headers (tunnelled packets filtering).
A client MUST be able to specify pinholes that contain at least the
routing options (Mobile IPv6). The protocol must be flexible enough
to accomodate other IPv6 options and possibly for the ones which are
not yet defined.
A client SHOULD be permitted to open pinholes specifying any
internal address associated with it. (e.g. multihoming case).
The protocol SHOULD be able to validate the source IP address.
Reasoning
The following describes use cases where such capabilities are
needed:
a) SIP-established-communications
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.
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].
NSIS Working Group Expiration 07/01/06 4
Requirements for Firewall Configuration Protocol
January 2006
The node therefore needs to 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 MUST be able to create pinholes with wildcard for
source address, port, protocol and spi values field.
Reasoning.
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 (the source
address is wildcarded).
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
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 MUST be able to close any or all the pinholes it created
with a single protocol instance.
NOTE: a Firewall Configuration Protocol should provide a solution
for the above requirement in a single Firewall architecture. In a
multihomed scenario, with multiple Firewalls on alternative paths,
there should be a means for the Firewalls to keep themselves
synchronized.
A client MUST be able to suggest a pinhole timeout. A firewall
SHOULD be able to override such suggestions.
A client MUST be able to refresh all associated pinhole timeouts
with a single protocol instance.
NOTE: a Firewall Configuration Protocol should provide a solution
for the above requirement in a single Firewall architecture. In a
multihomed scenario, with multiple Firewalls on alternative paths,
NSIS Working Group Expiration 07/01/06 5
Requirements for Firewall Configuration Protocol
January 2006
there should be a means for the Firewalls to keep themselves
synchronized.
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 scenario:
a) The end point may host a server but later, for different reasons,
it may decide not to host server anymore. Therefore, the end point
should be able to close the pinholes it opened to stop incoming
packets at the network, maybe even before the lifetime of the
pinhole expires. This is particularly important for access networks
with limited bandwidth.
In addition, when opening the pinholes, each of the pinholes should
be associated with a lifetime to ensure that no pinholes are left in
the firewalls in case the MNs e.g. loose coverage and get
disconnected from the network.
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 packet from a specific node
(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 applications: some applications may be authorized by
default by the local network policy. The end point may however not
want to receive packets related to such applications and may prefer
to drop the corresponding packets at the firewall to avoid a wastage
of 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 MUST be able to update the pinholes and/or packet filters
installed in the firewall.
NSIS Working Group Expiration 07/01/06 6
Requirements for Firewall Configuration Protocol
January 2006
The client MUST 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 MUST 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
The protocol MUST allow an end point to create, modify or delete
several firewall states with one protocol instance.
NOTE: a Firewall Configuration Protocol should provide a solution
for the above requirement in a single Firewall architecture. In a
multihomed scenario, with multiple Firewalls on alternative paths,
there should be a means for the Firewalls to keep themselves
synchronized.
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.
NSIS Working Group Expiration 07/01/06 7
Requirements for Firewall Configuration Protocol
January 2006
It MUST be possible to open a pinhole with a single protocol
request/response pair of messages. This is required because:
a) a wireless link is a scarce and expensive resource
b) real-time applications are delay sensitive
5.1.8 IP version
The protocol MUST be applicable both for IPv4 and IPv6.
5.1.9 Firewall features
The protocol MUST allow the client to learn the features implemented
in the FW and whether those are enabled or disabled.
The protocol MUST provide a means to the client to configure the
Firewall (e.g. enable/disable a feature in the FW).
A Firewall MUST be able to authorise such request based on the NAI
of the client and the IP address used to send the request.
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 MUST not open the opportunity
for nodes to flood a target.
The client MUST be able to integrity protect and/or encrypt the
messages it sends to the firewall.
A firewall MUST perform authentication and integrity check on each
message from a client.
6. Contributors
The following people contributed to the initial version of this
draft: Franck Le, Michael Paddon, Trevor Plestid, Sebastien
Thalanany. Special thanks to Hannes Tschofenig for the valuable
comments and inputs he made to the document.
NSIS Working Group Expiration 07/01/06 8
Requirements for Firewall Configuration Protocol
January 2006
7. 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.
ftp://3gpp2.org
[3] X.P0036, Network Firewall Configuration and Control, 3GPP2 TSG-
X, April 2005
ftp://3gpp2.org
8. Author's Address
Gabor Bajko
Nokia
e-mail: gabor.bajko@nokia.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
NSIS Working Group Expiration 07/01/06 9
Requirements for Firewall Configuration Protocol
January 2006
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
NSIS Working Group Expiration 07/01/06 10
| PAFTECH AB 2003-2026 | 2026-04-23 10:56:35 |