One document matched: draft-bajko-nsis-fw-reqs-08.txt
Differences from draft-bajko-nsis-fw-reqs-07.txt
NSIS Working Group Gabor Bajko
Internet Draft Nokia
Intended Status: Informational October, 2007
Document: <draft-bajko-nsis-fw-reqs-08.txt>
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 April 7, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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
resources. Firewalls can however present many issues with new
G. Bajko Expires April 7, 2008 [Page 1]
Requirements for Firewall Configuration October 2007
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.
Table of Content
1. Introduction 2
2. Terminology 3
3. Requirements 3
3.1 Functional Requirements 4
3.1.1 Pinholes creation 4
3.1.2 Creation of Pinholes without knowing the CN 5
3.1.3 Pinhole creation to enable communication when MIPv6 is used 5
3.1.4 Pinholes deletion 5
3.1.5 Packet filters 6
3.1.6 States update 7
3.1.7 Transport protocol preferences and Firewall configuration 7
3.1.8 Efficient use of the air interface 7
3.1.9 IP version 8
3.1.10 Grouping 8
3.1.11 Firewall Features 8
3.2 Security Requirements 9
4. Security Considerations 10
5. IANA Considerations 11
6. Contributors 12
7. Normative References 12
8. Informative References 12
1. Introduction
While the number 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
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 the above listed
problems: Application-Level-Gateways (ALGs) that by analyzing the
Bajko Expires October 6, 2007 [Page 2]
Requirements for Firewall Configuration October 2007
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.
2. Terminology
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.
3. Requirements
Bajko Expires October 6, 2007 [Page 3]
Requirements for Firewall Configuration October 2007
This section lists the requirements for a protocol to be used by
communication end points to configure the Firewalls on the path.
Based on different use cases, useful features are identified and
described. The security requirements are also analyzed.
3.1 Functional Requirements
3.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, protocol and IPsec SPI values.
A client SHOULD 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].
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.
Bajko Expires October 6, 2007 [Page 4]
Requirements for Firewall Configuration October 2007
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 it may posses; 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;
3.1.2 Creation of Pinholes without knowing the CN
The end point behind a Firewall MUST be able to create pinholes with
wildcard for CN source address, port, protocol and spi values field.
Reasoning.
Such capabilities are useful in the following scenarios:
a) The end point behind a Firewall 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 behind the Firewall does not yet know the address(es)
of the CNs: the end point behind the Firewall may e.g. want to host
a server (FTP, HTTP) or run applications such as P2P (the source
address of the expected CNs should be wildcarded at pinhole creation
phase).
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 Updates necessary for Route
Optimization.
3.1.3 Pinhole creation to enable communication when MIPv6 is used
The protocol MUST support the IPv6 Next Header value. In particular,
the protocol MUST support at least the value 135 (Mobility Header).
Such capability is useful in the following scenario:
By supporting the IPv6 Mobility Header [4] (Next Header value of
135), an MN would be able to open pinholes with wildcard for the
CN's source address, port, protocol and spi values, and specify that
only Mobility Header messages are to be allowed to pass through.
3.1.4 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
Bajko Expires October 6, 2007 [Page 5]
Requirements for Firewall Configuration October 2007
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. The client MUST be
informed of the resulting timeout value, in order to perform refresh
on a timely manner.
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,
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.
3.1.5 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.
Bajko Expires October 6, 2007 [Page 6]
Requirements for Firewall Configuration October 2007
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
3.1.6 States update
The client MUST be able to update the pinholes and/or packet filters
installed in the Firewall.
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
according to [5]. 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.
3.1.7 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 mechanisms in addition to setting pinholes. An
example is setting particular countermeasures, or specific filtering
mechanisms, or specific Firewall modes of operation.
3.1.8 Efficient use of the air interface
Bajko Expires October 6, 2007 [Page 7]
Requirements for Firewall Configuration October 2007
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.
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
3.1.9 IP version
The protocol MUST be applicable both for IPv4 and IPv6.
3.1.10 Grouping
The protocol SHOULD support grouping of related pinhole requests.
The protocol SHOULD support the creation of either all the pinholes
within a group (which may relate to one specific data flow or one
specific multimedia session) or none.
This capability might be useful:
- to applications which require multiple pinholes to be created in
order to operate successfully.
- when a pinhole range can only be created by multiple pinhole
requests (e.g. open a range, but block one in the middle).
The above requirement is intended to eliminate the error cases when
'n' number of pinholes are required for a data session, but only 'n-
1' pinholes were successfully created.
3.1.11 Firewall features
The protocol MAY allow the client to learn the features implemented
in the FW and whether those are enabled or disabled.
The protocol MAY 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:
Bajko Expires October 6, 2007 [Page 8]
Requirements for Firewall Configuration October 2007
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.
3.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.
A client MUST NOT be allowed to open a pinhole in the Firewall on
behalf of another end point, unless it is explicitly and securely
allowed to do so.
Bajko Expires October 6, 2007 [Page 9]
Requirements for Firewall Configuration October 2007
4. Security Considerations
Security is of major concern in case of Firewall traversal and
Firewall configuration. The protocol designed based on these
requirements must fulfill the security requirements listed in
section 3.
Bajko Expires October 6, 2007 [Page 10]
Requirements for Firewall Configuration October 2007
5. IANA Considerations
This specification does not request the creation of any new
parameter registries, nor does it require any other IANA
assignments.
Bajko Expires October 6, 2007 [Page 11]
Requirements for Firewall Configuration October 2007
6. Contributors
The following people contributed to this draft: Franck Le, Michael
Paddon, Trevor Plestid, Sebastian Thalanany, Hannes Tschofenig and
Martin Stiermeling.
7. Normative References
[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
[4] D Johnson et al, "Mobility Support in IPv6", IETF RFC 3775, June
2004
[5] T Narten el al, "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6", IETF RFC 3041, January 2001
8. Informative References
[1] Franck Le, Stefano Faccin, Basavaraj Patil, Hannes Tschofenig,
"Mobile IPv6 and Firewalls, Problem statement" IETF RFC 4487,
August 2004.
Author's Address
Gabor Bajko
Nokia
e-mail: gabor.bajko@nokia.com
Bajko Expires October 6, 2007 [Page 12]
Requirements for Firewall Configuration October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 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, THE
IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Bajko Expires October 6, 2007 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 22:59:54 |