4. Filtering Recommendations
When designing firewall filtering rules for ICMPv6, the rules can be
divided into two classes:
o Rules for ICMPv6 traffic transiting the firewall, with some minor
variations for
* firewalls protecting end sites or individual hosts, and
* firewalls protecting transit sites
o Rules for ICMPv6 directed to interfaces on the firewall
Firewalls integrated with an individual host ("end host firewalls")
can be treated as end site firewalls, but the special considerations
discussed in Section 4.2 may be relevant because the firewall is not
a router.
This section suggests some common considerations that should be borne
in mind when designing filtering rules and then categorizes the rules
for each class. The categories are:
o Messages that must not be dropped: usually because establishment
or maintenance of communications will be prevented or severely
impacted.
o Messages that should not be dropped: administrators need to have a
very good reason for dropping this category.
o Messages that may be dropped in firewall/routers, but these
messages may already be targeted to drop for other reasons (e.g.,
because they are using link-local addresses) or because the
protocol specification would cause the messages to be rejected if
they had passed through a router. Special considerations apply to
transit traffic if the firewall is not a router as discussed in
Section 4.2.
o Messages that administrators may or may not want to drop depending
on local policy.
o Messages that administrators should consider dropping (e.g., ICMP
node information name lookup queries).
More detailed analysis of each of the message types can be found in
Appendix A.
4.1. Common Considerations
Depending on the classification of the message to be filtered (see
Section 2), ICMPv6 messages should be filtered based on the ICMPv6
type of the message and the type (unicast, multicast, etc.) and scope
(link-local, global unicast, etc.) of source and destination
addresses. In some cases, it may be desirable to filter on the Code
field of ICMPv6 error messages.
Messages that can be authenticated on delivery, probably because they
contain an IPsec AH header or ESP header with authentication, may be
subject to less strict policies than messages that cannot be
authenticated. In the remainder of this section, we are generally
considering what should be configured for unauthenticated messages.
In many cases, it is not realistic to expect more than a tiny
fraction of the messages to be authenticated.
Where messages are not essential to the establishment or maintenance
of communications, local policy can be used to determine whether a
message should be allowed or dropped.
Depending on the capabilities of the firewall being configured, it
may be possible for the firewall to maintain state about packets that
may result in error messages being returned or about ICMPv6 packets
(e.g., Echo Requests) that are expected to receive a specific
response. This state may allow the firewall to perform more precise
checks based on this state, and to apply limits on the number of
ICMPv6 packets accepted incoming or outgoing as a result of a packet
traveling in the opposite direction. The capabilities of firewalls
to perform such stateful packet inspection vary from model to model,
and it is not assumed that firewalls are uniformly capable in this
respect.
Firewalls that are able to perform deep packet inspection may be able
to check the header fields in the start of the errored packet that is
carried by ICMPv6 error messages. If the embedded packet has a
source address that does not match the destination of the error
message, the packet can be dropped. This provides a partial defense
against some possible attacks on TCP that use spoofed ICMPv6 error
messages, but the checks can also be carried out at the destination.
For further information on these attacks see [ICMP-ATTACKS].
In general, the scopes of source and destination addresses of ICMPv6
messages should be matched, and packets with mismatched addresses
should be dropped if they attempt to transit a router. However, some
of the address configuration messages carried locally on a link may
legitimately have mismatched addresses. Node implementations must
accept these messages delivered locally on a link, and administrators
should be aware that they can exist.
ICMPv6 messages transiting firewalls inbound to a site may be treated
differently depending on whether they are addressed to a node on the
site or to some other node. For end sites, packets addressed to
nodes not on the site should be dropped, but would generally be
forwarded by firewalls on transit sites.
Firewalls can be implemented both as IP routers (firewall/routers)
and as link layer bridges (e.g., Ethernet bridges) that are
transparent to the IP layer although they will actually be inspecting
the IP packets as they pass through (firewall/bridges).
Many of the messages used for establishment and maintenance of
communications on the local link will be sent with link-local
addresses for at least one of their source and destination. Routers
conforming to the IPv6 standards will not forward these packets;
there is no need to configure additional rules to prevent these
packets traversing a firewall/router, although administrators may
wish to configure rules that would drop these packets for insurance
and as a means of monitoring for attacks. Also, the specifications
of ICMPv6 messages intended for use only on the local link specify
various measures that would allow receivers to detect if the message
had passed through a router, including:
o Requiring that the hop limit in the IPv6 header is set to 255 on
transmission. Receivers verify that the hop limit is still 255,
to ensure that the packet has not passed through a router.
o Checking that the source address is a link-local unicast address.
Accordingly, it is not essential to configure firewall/router rules
to drop out-of-specification packets of these types. If they have
non-link-local source and destination addresses, allowing them to
traverse the firewall/router, they would be rejected because of the
checks performed at the destination. Again, firewall administrators
may still wish to configure rules to log or drop such out-of-
specification packets.
For firewall/bridges, slightly different considerations apply. The
physical links on either side of the firewall/bridge are treated as a
single logical link for the purposes of IP. Hence, the link local
messages used for discovery functions on the link must be allowed to
transit the transparent bridge. Administrators should ensures that
routers and hosts attached to the link containing the firewall/bridge
are built to the correct specifications so that out-of-specification
packets are actually dropped as described in the earlier part of this
section.
An end host firewall can generally be thought of as a special case of
a firewall/bridge, but the only link-local messages that need to be
allowed through are those directed to the host's interface.
4.3. Recommendations for ICMPv6 Transit Traffic
This section recommends rules that should be applied to ICMPv6
traffic attempting to transit a firewall.
4.3.1. Traffic That Must Not Be Dropped
Error messages that are essential to the establishment and
maintenance of communications:
o Destination Unreachable (Type 1) - All codes
o Packet Too Big (Type 2)
o Time Exceeded (Type 3) - Code 0 only
o Parameter Problem (Type 4) - Codes 1 and 2 only
Appendix A.4 suggests some more specific checks that could be
performed on Parameter Problem messages if a firewall has the
necessary packet inspection capabilities.
Connectivity checking messages:
o Echo Request (Type 128)
o Echo Response (Type 129)
For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be
possible, it is essential that the connectivity checking messages are
allowed through the firewall. It has been common practice in IPv4
networks to drop Echo Request messages in firewalls to minimize the
risk of scanning attacks on the protected network. As discussed in
Section 3.2, the risks from port scanning in an IPv6 network are much
less severe, and it is not necessary to filter IPv6 Echo Request
messages.
4.3.2. Traffic That Normally Should Not Be Dropped
Error messages other than those listed in Section 4.3.1:
o Time Exceeded (Type 3) - Code 1
o Parameter Problem (Type 4) - Code 0
Mobile IPv6 messages that are needed to assist mobility:
o Home Agent Address Discovery Request (Type 144)
o Home Agent Address Discovery Reply (Type 145)
o Mobile Prefix Solicitation (Type 146)
o Mobile Prefix Advertisement (Type 147)
Administrators may wish to apply more selective rules as described in
Appendix A.14 depending on whether the site is catering for mobile
nodes that would normally be at home on the site and/or foreign
mobile nodes roaming onto the site.
4.3.3. Traffic That Will Be Dropped Anyway -- No Special Attention
The messages listed in this section are all involved with local
management of nodes connected to the logical link on which they were
initially transmitted. All these messages should never be propagated
beyond the link on which they were initially transmitted. If the
firewall is a firewall/bridge rather than a firewall/router, these
messages should be allowed to transit the firewall as they would be
intended for establishing communications between the two physical
parts of the link that are bridged into a single logical link.
During normal operations, these messages will have destination
addresses, mostly link local but in some cases global unicast
addresses, of interfaces on the local link. No special action is
needed to filter messages with link-local addresses in a firewall/
router. As discussed in Section 4.1, these messages are specified so
that either the receiver is able to check that the message has not
passed through a router or it will be dropped at the first router it
encounters.
Administrators may also wish to consider providing rules in firewall/
routers to catch illegal packets sent with hop limit = 1 to avoid
ICMPv6 Time Exceeded messages being generated for these packets.
Address Configuration and Router Selection messages (must be received
with hop limit = 255):
o Router Solicitation (Type 133)
o Router Advertisement (Type 134)
o Neighbor Solicitation (Type 135)
o Neighbor Advertisement (Type 136)
o Redirect (Type 137)
o Inverse Neighbor Discovery Solicitation (Type 141)
o Inverse Neighbor Discovery Advertisement (Type 142)
Link-local multicast receiver notification messages (must have link-
local source address):
o Listener Query (Type 130)
o Listener Report (Type 131)
o Listener Done (Type 132)
o Listener Report v2 (Type 143)
SEND Certificate Path notification messages (must be received with
hop limit = 255):
o Certificate Path Solicitation (Type 148)
o Certificate Path Advertisement (Type 149)
Multicast Router Discovery messages (must have link-local source
address and hop limit = 1):
o Multicast Router Advertisement (Type 151)
o Multicast Router Solicitation (Type 152)
o Multicast Router Termination (Type 153)
4.3.4. Traffic for Which a Policy Should Be Defined
The message type that the experimental Seamoby protocols are using
will be expected to have to cross site boundaries in normal
operation. Transit sites must allow these messages to transit the
site. End site administrators should determine if they need to
support these experiments and otherwise messages of this type should
be dropped:
o Seamoby Experimental (Type 150)
Error messages not currently defined by IANA:
o Unallocated Error messages (Types 5-99 inclusive and 102-126
inclusive)
The base ICMPv6 specification suggests that error messages that are
not explicitly known to a node should be forwarded and passed to any
higher-level protocol that might be able to interpret them. There is
a small risk that such messages could be used to provide a covert
channel or form part of a DoS attack. Administrators of end sites
should be aware of this and determine whether they wish to allow
these messages through the firewall. Firewalls protecting transit
sites must allow all types of error messages to transit the site but
may adopt different policies for error messages addressed to nodes
within the site.
All informational messages with types not explicitly assigned by
IANA, currently:
o Unallocated Informational messages (Types 154-199 inclusive and
202-254 inclusive).
Note that the base ICMPv6 specification requires that received
informational messages with unknown types must be silently discarded.
Transit sites must allow these messages to transit the site. End
site administrators can either adopt a policy of allowing all these
messages through the firewall, relying on end hosts to drop
unrecognized messages, or drop all such messages at the firewall.
Different policies could be adopted for inbound and outbound
messages.
If administrators choose to implement policies that drop currently
unallocated error or informational messages, it is important to
review the set of messages affected in case new message types are
assigned by IANA.
4.3.5. Traffic That Should Be Dropped Unless a Good Case Can Be Made
Node Information enquiry messages should generally not be forwarded
across site boundaries. Some of these messages will be using non-
link-local unicast addresses so that they will not necessarily be
dropped by address scope limiting rules:
o Node Information Query (Type 139)
o Node Information Response (Type 140)
Router Renumbering messages should not be forwarded across site
boundaries. As originally specified, these messages may use a site
scope multicast address or a site local unicast address. They should
be caught by standard rules that are intended to stop any packet with
a multicast site scope or site local destination being forwarded
across a site boundary provided these are correctly configured.
Since site local addresses have now been deprecated, it seems likely
that changes may be made to allow the use of unique local addresses
or global unicast addresses. Should this happen, it will be
essential to explicitly filter these messages at site boundaries. If
a site has internal as well as boundary firewalls, individual
policies should be established for the internal firewalls depending
on whether or not the site wishes to use Router Renumbering:
o Router Renumbering (Type 138)
Messages with types in the experimental allocations:
o Types 100, 101, 200, and 201.
Messages using the extension type numbers until such time as ICMPv6
needs to use such extensions:
o Types 127 and 255.
4.4. Recommendations for ICMPv6 Local Configuration Traffic
This section recommends filtering rules for ICMPv6 traffic addressed
to an interface on a firewall. For a small number of messages, the
desired behavior may differ between interfaces on the site or private
side of the firewall and the those on the public Internet side of the
firewall.
4.4.1. Traffic That Must Not Be Dropped
Error messages that are essential to the establishment and
maintenance of communications:
o Destination Unreachable (Type 1) - All codes
o Packet Too Big (Type 2)
o Time Exceeded (Type 3) - Code 0 only
o Parameter Problem (Type 4) - Codes 1 and 2 only
Connectivity checking messages:
o Echo Request (Type 128)
o Echo Response (Type 129)
As discussed in Section 4.3.1, dropping connectivity checking
messages will prevent the firewall being the destination of a Teredo
tunnel and it is not considered necessary to disable connectivity
checking in IPv6 networks because port scanning is less of a security
risk.
There are a number of other sets of messages that play a role in
configuring the node and maintaining unicast and multicast
communications through the interfaces of a node. These messages must
not be dropped if the node is to successfully participate in an IPv6
network. The exception to this is the Redirect message for which an
explicit policy decision should be taken (see Section 4.4.4).
Address Configuration and Router Selection messages:
o Router Solicitation (Type 133)
o Router Advertisement (Type 134)
o Neighbor Solicitation (Type 135)
o Neighbor Advertisement (Type 136)
o Inverse Neighbor Discovery Solicitation (Type 141)
o Inverse Neighbor Discovery Advertisement (Type 142)
Link-Local Multicast Receiver Notification messages:
o Listener Query (Type 130)
o Listener Report (Type 131)
o Listener Done (Type 132)
o Listener Report v2 (Type 143)
SEND Certificate Path Notification messages:
o Certificate Path Solicitation (Type 148)
o Certificate Path Advertisement (Type 149)
Multicast Router Discovery messages:
o Multicast Router Advertisement (Type 151)
o Multicast Router Solicitation (Type 152)
o Multicast Router Termination (Type 153)
4.4.2. Traffic That Normally Should Not Be Dropped
Error messages other than those listed in Section 4.4.1:
o Time Exceeded (Type 3) - Code 1
o Parameter Problem (Type 4) - Code 0
4.4.3. Traffic That Will Be Dropped Anyway -- No Special Attention
Router Renumbering messages must be authenticated using IPsec, so it
is not essential to filter these messages even if they are not
allowed at the firewall/router:
o Router Renumbering (Type 138)
Mobile IPv6 messages that are needed to assist mobility:
o Home Agent Address Discovery Request (Type 144)
o Home Agent Address Discovery Reply (Type 145)
o Mobile Prefix Solicitation (Type 146)
o Mobile Prefix Advertisement (Type 147)
It may be desirable to drop these messages, especially on public
interfaces, if the firewall is not also providing mobile home agent
services, but they will be ignored otherwise.
The message used by the experimental Seamoby protocols may be dropped
but will be ignored if the service is not implemented:
o Seamoby Experimental (Type 150)
4.4.4. Traffic for Which a Policy Should Be Defined
Redirect messages provide a significant security risk, and
administrators should take a case-by-case approach to whether
firewalls, routers in general, and other nodes should accept these
messages:
o Redirect (Type 137)
Conformant nodes must provide configuration controls that allow nodes
to control their behavior with respect to Redirect messages so that
it should only be necessary to install specific filtering rules under
special circumstances, such as if Redirect messages are accepted on
private interfaces but not public ones.
If a node implements the experimental Node Information service, the
administrator needs to make an explicit decision as to whether the
node should respond to or accept Node Information messages on each
interface:
o Node Information Query (Type 139)
o Node Information Response (Type 140)
It may be possible to disable the service on the node if it is not
wanted, in which case these messages will be ignored and no filtering
is necessary.
Error messages not currently defined by IANA:
o Unallocated Error messages (Types 5-99 inclusive and 102-126
inclusive)
The base ICMPv6 specification suggests that error messages that are
not explicitly known to a node should be forwarded and passed to any
higher-level protocol that might be able to interpret them. There is
a small risk that such messages could be used to provide a covert
channel or form part of a DoS attack. Administrators should be aware
of this and determine whether they wish to allow these messages to be
sent to the firewall.
4.4.5. Traffic That Should Be Dropped Unless a Good Case Can Be Made
Messages with types in the experimental allocations:
o Types 100, 101, 200, and 201.
Messages using the extension type numbers until such time as ICMPv6
needs to use such extensions:
o Types 127 and 255.
All informational messages with types not explicitly assigned by
IANA, currently:
o Types 154-199 inclusive and 202-254 inclusive.
Note that the base ICMPv6 specification requires that received
informational messages with unknown types must be silently discarded.
