One document matched: draft-savola-v6ops-firewalling-01.txt
Differences from draft-savola-v6ops-firewalling-00.txt
Internet Engineering Task Force P. Savola
Internet Draft CSC/FUNET
Expiration Date: September 2003
March 2003
Firewalling Considerations for IPv6
draft-savola-v6ops-firewalling-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
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.
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
There are quite a few potential problems regarding firewalling or
packet filtering in IPv6 environment. These include slight ambiguity
in the IPv6 specification, problems parsing packets beyond unknown
Extension Headers and Destination Options, and introduction of end-
to-end encrypted traffic and peer-to-peer applications. There may
also be need to extend packet matching to include some Extension
Header or Destination Option fields. This draft discusses these
issues to raise awareness and proposes some tentative solutions or
workarounds.
Savola [Expires September 2003] [Page 1]
Internet Draft draft-savola-v6ops-firewalling-01.txt March 2003
Table of Contents
1. Introduction ............................................... 2
1.1. Terminology ............................................ 3
2. Ambiguous Text in the IPv6 Specification ................... 4
2.1. The Problem ............................................ 4
2.2. Possible Solutions ..................................... 5
3. Parsing Extension Header Chains ............................ 5
3.1. The Problem ............................................ 5
3.2. Possible Solutions ..................................... 5
4. Parsing Unknown Destination Options and Security Policy .... 6
4.1. The Problem ............................................ 6
4.2. Possible Solutions ..................................... 6
5. Firewalls and End-to-End IPsec-encrypted ESP-traffic ....... 7
5.1. The Problem ............................................ 7
5.2. Possible Solutions ..................................... 7
6. Firewalls and Interactions with Peer-to-Peer Applications .. 8
6.1. The Problem ............................................ 8
6.2. Possible Solutions ..................................... 8
7. Security Considerations .................................... 8
8. Acknowledgements ........................................... 9
9. References ................................................. 9
9.1. Normative References ................................... 9
9.2. Informative References ................................. 9
Author's Address ............................................... 10
A. Possible Desirable Header Field Matching Extensions ........ 10
B. Amplification DoS Attack Using IPv6 Multicast .............. 10
1. Introduction
There are quite a few potential problems regarding firewalling or
packet filtering in IPv6 environment. These include slight ambiguity
in the IPv6 specification, problems parsing packets beyond unknown
Extension Headers and Destination Options, and introduction of end-
to-end encrypted traffic and peer-to-peer applications. There may
also be need to extend packet matching to include some Extension
Header or Destination Option fields. This draft discusses these
issues to raise awareness and proposes some tentative solutions or
workarounds.
On-link attacks using Neighbor Discovery are similar to ones
available through IPv4 ARP, and not typically applicable to
firewalls, and are therefore out of scope. A good summary of the
issues is available at [SENDREQ].
Savola [Expires September 2003] [Page 2]
Internet Draft draft-savola-v6ops-firewalling-01.txt March 2003
Also, implementation or policy-specific issues are out of scope;
these include e.g. issues of node-specific state creation (could be
problematic if networks were brute-force scanned) and applicability
of existing policies (e.g. blocking ICMPv6 would have very bad
effects, particularly if certain link-local messages receive no
special consideration).
In section 2, slightly ambiguous text in the IPv6 specification is
discussed. In section 3, syntactical problem with parsing unknown
Extension Headers is pointed out. In section 4, a similar problem
with Destination Options is discussed in the context of security
policy. In section 5, implications of end-to-end encrypted traffic
are considerated. In section 6, similar implications of peer-to-peer
applications are mentioned. In appendix A, some possibly useful
packet matching extensions for IPv6 are brought up.
A possible generic denial-of-service attack using multicast and
including amplification has also been noticed; as it is not firewall-
specific, it is described with in Appendix B.
1.1. Terminology
In this document, the term "firewall" is used to mean any kind of
packet filter; no special features (like statefullness or
application-specific packet inspection) is assumed.
When considering firewalls, one should note that there are several
ways to place and implement a firewall; in principle:
1. network firewall
2. network, user-controlled firewall
3. end-node, admin-controlled firewall
4. end-node firewall
The first is configured solely by an administrator, and placed in the
network to block or pass the traffic of multiple nodes or network in
an aggregated fashion.
The second is also configured by an administrator and placed in the
network, but the user may be able to affect some policy decisions
made in the firewall e.g. by some signalling protocol; ie. the policy
of the firewall can, to some extent, be influenced by the end-nodes.
The third, also sometimes called a distributed firewall, is a
firewall placed in the end-nodes, but controlled in some co-ordinated
Savola [Expires September 2003] [Page 3]
Internet Draft draft-savola-v6ops-firewalling-01.txt March 2003
fashion by an administrator [DISFW].
The last is the typical end-node firewall, policy set by the end-
user, or sometimes even the applications run on the end-node.
2. Ambiguous Text in the IPv6 Specification
2.1. The Problem
The [IPV6] specification forbids skipping over any of the headers
before processing them or processing them at all before reaching the
destination (section 4):
"With one exception, Extension Headers are not examined or processed
by any node along a packet's delivery path, until the packet reaches
the node (or each of the set of nodes, in the case of multicast)
identified in the Destination Address field of the IPv6 header.
There, normal demultiplexing on the Next Header field of the IPv6
header invokes the module to process the first Extension Header, or
the upper-layer header if no Extension Header is present. The
contents and semantics of each Extension Header determine whether or
not to proceed to the next header. Therefore, Extension Headers must
be processed strictly in the order they appear in the packet; a
receiver must not, for example, scan through a packet looking for a
particular kind of Extension Header and process that header prior to
processing all preceding ones."
And:
"If, as a result of processing a header, a node is required to
proceed to the next header but the Next Header value in the current
header is unrecognized by the node, it should discard the packet and
send an ICMP Parameter Problem message to the source of the packet,
with an ICMP Code value of 1 ("unrecognized Next Header type
encountered") and the ICMP Pointer field containing the offset of the
unrecognized value within the original packet. The same action
should be taken if a node encounters a Next Header value of zero in
any header other than an IPv6 header."
Similar applies to the specified Destination Options processing
behaviour: if the Option Type has been specified so that the packet
should not be processed further in the case of unrecognized options
(ie. the highest-order two bits are not "00"), should the firewall
also discard the packet and/or send ICMP Parameter Problem message
back to the source?
Are these also to be done by intermediate nodes (which, by some
definition, should not be processing Extension Headers or Destination
Savola [Expires September 2003] [Page 4]
Internet Draft draft-savola-v6ops-firewalling-01.txt March 2003
Options Header with Hop-by-Hop options as an exception); this seems
unlikely.
This wording clearly does not take into the account that there might
be middleboxes, or non-final destinations, that could be processing
the packet.
2.2. Possible Solutions
The correct behaviour must be made clear; the wording should be
clarified. Clarifications might be needed at least on:
1. whether intermediate nodes should be taken into account in the
text describing the header processing
2. intermediate nodes' behaviour when detecting unrecognized
headers
3. Parsing Extension Header Chains
3.1. The Problem
IPv4 [RFC1122] [RFC1812] silently ignores options it does not
recognize; options have a specific, pre-defined format. IPv6
Extension Headers are structured differently: the header format can
change, and generally it is not possible to parse the header, or
proceed to the following Extension Headers unless the processing of
the previous header has been implemented.
The above is problematic as it is often the case that a packet filter
will want to examine terminal headers, e.g. TCP or UDP. That is not
possible if there is a problem processing any one of the preceding
headers.
3.2. Possible Solutions
In the generic case, even ignoring the IPv6 specification, unknown
headers cannot be skipped over except by making some very wild
guesses of the content. Thus the solutions (or work-arounds) are:
1. always keep the packet filter up-to-date, so that it can parse
all types of Extension Headers
2. never introduce new Extension Headers, except possibly in a
very controlled manner; use Destination Options instead
Savola [Expires September 2003] [Page 5]
Internet Draft draft-savola-v6ops-firewalling-01.txt March 2003
3. standardize the format (for at least the first N bytes
including at least the length and the next header value) of
possibly later specified new Extension Headers, so that
skipping over headers could be possible
The first is not a workable solution in a generic case at least if
it's expected that new Extension Headers should be introducable: the
lifetime of firewall devices and software seems to be much longer
than one would expect. For example, it is good to consider the case
of buggy firewalls and ECN support [ECN]: even though software fixes
may have been available for a long time, upgrades have not taken
place, hindering the deployment of new technology.
The second seems quite a bleak work-around, but as currently
specified, there is little choice; most (if not all) new features can
probably be implemented using Destination Options. However, it's
still good to document and understand this deployment and
specification deadlock.
The third might be doable but it would require some standardization
effort.
4. Parsing Unknown Destination Options and Security Policy
4.1. The Problem
Similar to the above, Destination Options may also include unknown
options. However, the options are encoded in the TLV-format. So,
skipping over unknown options is technically possible.
However, especially in a very controlled environments, where a
firewall may implement a strict security policy, it may be desirable
to reject any options the firewall does not recognize (which may
cause the end-nodes to do something that has not been anticipated in
the security policy controlled by the firewall).
4.2. Possible Solutions
No protocol action seems to be necessary provided that the
implementation would not, in this case, send ICMP messages or discard
packets upon receiving an unknown header.
However, it may be desirable for firewall implementations to have a
feature controlling the handling behaviour of unrecognized
Destination Options.
Savola [Expires September 2003] [Page 6]
Internet Draft draft-savola-v6ops-firewalling-01.txt March 2003
5. Firewalls and End-to-End IPsec-encrypted ESP-traffic
5.1. The Problem
With the promise of the restoration of end-to-end transparency, and
if at least some of the challenges for implementing Public Key
Infrastructures are worked around, it may be possible that the amount
of end-to-end encrypted traffic will increase enermously. The
traffic is likely to be encrypted using IPsec.
In this case, on-the-path observers (such as a firewall) do not have
the possibility to examine usually critical headers (such as
TCP/UDP). This may result in an administrative decision to disable
IPsec-encrypted traffic by filtering it out completely.
5.2. Possible Solutions
It would be desirable, if the users wish to do so, be able to have
the firewall or some node the firewall is configured to trust as an
intermediary in IPsec Security Parameter Index (SPI)
negotiation/configuration, as that is the only visible way to
demultiplex encrypted content between two the source and destination.
However, even though this may mitigate the risks somewhat, but it
appears that SPI's could be reused (without the intermediary) in such
a way that entirely different kind of traffic could be sent. There
is no fix for this, by the definition of end-to-end encryption.
One could try to encode some interesting values, e.g. protocol
numbers and ports in the Flow Label field; one problem here is the
relatively limited length of 20 bits. But this would have to be done
in the source node, which is not usually (at least completely)
trusted in this context.
An approach, which has been proposed in the past in many forms has
been to specify an IPsec-like ESP-protocol which would allow
revealing only some portions of the packets, for example transport-
layer headers [ESVP]. To some extent, this would be helpful, but not
necessarily enough; for example, application-specific checking might
require access to the whole packet, especially if a different
solution to the problem noted in the next section is not found.
A possible approach would be to try to shift the focus, at least
partially, to end-node firewalls; if end-nodes are not particularly
trusted, an end-node, admin-controlled firewall might be provide a
reasonable tradeoff between security policy and cryptography.
There appears to be no network-based solution for this, which is
indeed a feature of end-to-end cryptography.
Savola [Expires September 2003] [Page 7]
Internet Draft draft-savola-v6ops-firewalling-01.txt March 2003
6. Firewalls and Interactions with Peer-to-Peer Applications
6.1. The Problem
As above, the restoration of end-to-end transparency provides a
possibility for a more wide-spread use of peer-to-peer applications.
Such applications are often a bit problematic from the firewall
perspective: it is often the practise to allow outbound (from the
protected site) traffic while allowing in only the related traffic
(and naturally some other administratively permitted traffic). Being
able to run (some) peer-to-peer applications easily in a controlled
environment would be valuable.
6.2. Possible Solutions
One workaround would be to try to standardize some default port
ranges (in an application-specific manner) for such applications as
these, for example in the above 32768 range. In this way, a site
could enable/disable (default) port ranges for (some) peer-to-peer
applications at will. A major disadvantage here would be that this
could violate the trust model: some applications could intentionally
try to use some other's port range to gain entry through the firewall
even if the default range was blocked. This implies there's at least
some form of trust here.
A real, but possibly quite a complex solution would be to implement
some form of peer-to-peer "pinholing" [MIDCOM]. This hasn't yet been
standardized even for IPv4 (though the concept is quite protocol-
independent).
A possible approach, as above, would be to try to shift, at least
partially, the focus to end-node firewalls; if end-nodes are not
particularly trusted, an end-node, admin-controlled firewall might be
provide a reasonable tradeoff between security policy and
cryptography.
7. Security Considerations
This draft discusses security considerations related to IPv6
firewalling. When discussing potential solutions for problems, the
weaknesses are also pointed out.
In general, the firewall does not, and cannot, often trust the
node(s) it protects. These may even belong to different
administrative entit(y/ies). In that case, making compromises will
usually open some holes in the firewall.
Savola [Expires September 2003] [Page 8]
Internet Draft draft-savola-v6ops-firewalling-01.txt March 2003
8. Acknowledgements
Brian Carpenter suggested an IPv6 firewall could support P2P
pinholing. Soo Guan Eng provided commentary.
9. References
9.1. Normative References
[ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC2373, July 1998.
[IPV6] Deering, S., Hinden, R., "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
9.2. Informative References
[DISFW] Bellovin, S., "Distributed Firewalls", ;login: in Nov
1999, http://www.research.att.com/~smb/papers/distfw.html
[ECN] Garzik, J., "ECN-under-Linux Unofficial Vendor Support
Page", http://gtf.org/garzik/ecn/, March 2002.
[ESVP] Kasera, S. (ed.), "IP Encapsulating Security Variable
Payload (ESVP)", work-in-progress,
draft-kasera-esvp-00.txt, Oct 2002.
[ICMPV6] Conta, A., Deering, S., "Internet Control Message
Protocol (ICMPv6)", RFC2463, December 1998.
[MIDCOM] Srisuresh, P. et al, "Middlebox communication
architecture and framework", RFC3303, August 2002.
[MIPV6] Johnson, D., et al, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-21.txt, work-in-progress,
Feb 2003.
[MIPV6CAO] O'Neill, A., "MIPv6 Care of Address Option",
draft-oneill-mipv6-cao-00.txt, work-in-progress,
Sep 2002.
[RFC1122] Braden, R. (Editor), "Requirements for Internet Hosts
-- Communication Layers", RFC1122, October 1989.
[RFC1812] Baker, F. (Editor), "Requirements for IP Version 4
Routers", RFC1812, June 1995.
Savola [Expires September 2003] [Page 9]
Internet Draft draft-savola-v6ops-firewalling-01.txt March 2003
[RHHAOSEC] Savola, P. "Security of IPv6 Routing Header and
Home Address Options", work-in-progress,
draft-savola-ipv6-rh-ha-security-03.txt, December 2002.
[SENDREQ] Nikander, P., el al., "IPv6 Neighbor Discovery trust
models and threats", work-in-progress,
draft-ietf-send-psreq-01.txt, Jan 2003.
Author's Address
Pekka Savola
CSC/FUNET
Espoo, Finland
EMail: psavola@funet.fi
A. Possible Desirable Header Field Matching Extensions
As Destination options and Extension Header types are taken into use,
it may be desirable for a firewall to support some matching against
certain header fields. These include, for example:
- whether or not a specific Extension Header or a Destination
Option is detected
- behaviour when an unknown (or specified) Extension Header or
Destination Option is detected
- (Routing Header -specific) being able to match segments left
(mainly, whether it is zero or not), type and the next-to-be-
swapped destination(s) [RHHAOSEC]
- (Home Address Option [MIPV6] -specific) being able to match
against the home address
- (Care-of Address Option [MIPV6COA] -specific) being able to match
against the care-of address used for ingress filtering
- (ESP/AH -specific) being able to match against SPI
- (Tunneled-traffic specific) being able to match against the
embedded IPv4 address in e.g. 6to4, ISATAP, etc.
Some of these are much more useful than others; the list is only
meant to give ideas about possibly useful (in some scenarios, at
least) functionalities.
B. Amplification DoS Attack Using IPv6 Multicast
It is possible to launch a denial-of-service attack using IPv6,
including a form of amplification based on multicast infrastructure.
Multicast address must not be used as a source address [ADDRARCH],
but explicit checks to drop those packets or respond to them have not
been specified. However, such attacks are not considered here.
Savola [Expires September 2003] [Page 10]
Internet Draft draft-savola-v6ops-firewalling-01.txt March 2003
By crafting packets, sent to multicast destinations, which are
certain to contain a response to the source address (the victim's
address) would seem to be potentially useful for an attacker:
src = <victim> (unicast-address)
dst = <multicast address> (w/ as many receivers as possible)
next-header=200 (something undefined)
or:
next-header=destination-options (or hop-by-hop options)
options-header=<an unknown option type starting with binary "10">
Now, both of these amount to the same thing: every node which
processes the packet and adheres to [IPV6] will generate an ICMP
parameter problem back to the source.
[ICMPV6] does not permit the first approach with an unknown extension
header, but additionally permits ICMP message generation with Path
MTU Discovery.
This is different to IPv4, where no ICMP errors are generated in
response to packets sent to multicast addresses [RFC1122]. Clearly,
when specifying, allowing the flexibility to define whether a
response to multicast packets would be sent was considered a feature,
but dangerous features have a tendency to being turned to bad uses.
In addition to amplification, this kind of attack would have an
effect on multicast-enabled router network as a large amount of
multicast forwarding state would be created.
Savola [Expires September 2003] [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 11:07:18 |