< draft-ietf-v6ops-icmpv6-filtering-recs-01.txt   draft-ietf-v6ops-icmpv6-filtering-recs-02.txt >
IPv6 Operations E. Davies IPv6 Operations E. Davies
Internet-Draft Consultant Internet-Draft Consultant
Expires: December 15, 2006 J. Mohacsi Expires: January 10, 2007 J. Mohacsi
NIIF/HUNGARNET NIIF/HUNGARNET
June 13, 2006 July 9, 2006
Recommendations for Filtering ICMPv6 Messages in Firewalls Recommendations for Filtering ICMPv6 Messages in Firewalls
draft-ietf-v6ops-icmpv6-filtering-recs-01.txt draft-ietf-v6ops-icmpv6-filtering-recs-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 15, 2006. This Internet-Draft will expire on January 10, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
In networks supporting IPv6 the Internet Control Message Protocol In networks supporting IPv6 the Internet Control Message Protocol
version 6 (ICMPv6) plays a fundamental role with a large number of version 6 (ICMPv6) plays a fundamental role with a large number of
functions, and a correspondingly large number of message types and functions, and a correspondingly large number of message types and
options. A number of security risks are associated with uncontrolled options. ICMPv6 is essential to the functioning of IPv6 but there
forwarding of ICMPv6 messages. On the other hand, compared with IPv4 are a number of security risks associated with uncontrolled
and the corresponding protocol ICMP, ICMPv6 is essential to the forwarding of ICMPv6 messages. Filtering strategies designed for the
functioning of IPv6 rather than a useful auxiliary. corresponding protocol, ICMP, in IPv4 networks are not directly
applicable, because these strategies are intended to accommodate a
useful auxiliary protocol that may not be required for correct
functioning.
This document provides some recommendations for ICMPv6 firewall This document provides some recommendations for ICMPv6 firewall
filter configuration that will allow propagation of ICMPv6 messages filter configuration that will allow propagation of ICMPv6 messages
that are needed to maintain the functioning of the network but drop that are needed to maintain the functioning of the network but drop
messages which are potential security risks. messages which are potential security risks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Classifying ICMPv6 Messages . . . . . . . . . . . . . . . . . 6 2. Classifying ICMPv6 Messages . . . . . . . . . . . . . . . . . 6
2.1. Error and Informational ICMPv6 Messages . . . . . . . . . 6 2.1. Error and Informational ICMPv6 Messages . . . . . . . . . 6
2.2. Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . . 6 2.2. Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . . 6
2.3. Network Topology and Address Scopes . . . . . . . . . . . 7 2.3. Network Topology and Address Scopes . . . . . . . . . . . 7
2.4. Role in Establishing Communication . . . . . . . . . . . . 7 2.4. Role in Establishing Communication . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
3.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 8 3.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 9
3.2. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Redirection Attacks . . . . . . . . . . . . . . . . . . . 9 3.3. Redirection Attacks . . . . . . . . . . . . . . . . . . . 9
3.4. Renumbering Attacks . . . . . . . . . . . . . . . . . . . 9 3.4. Renumbering Attacks . . . . . . . . . . . . . . . . . . . 9
3.5. Problems Resulting from ICMPv6 Transparency . . . . . . . 9 3.5. Problems Resulting from ICMPv6 Transparency . . . . . . . 10
4. Filtering Recommendations . . . . . . . . . . . . . . . . . . 10 4. Filtering Recommendations . . . . . . . . . . . . . . . . . . 10
4.1. Common Considerations . . . . . . . . . . . . . . . . . . 10 4.1. Common Considerations . . . . . . . . . . . . . . . . . . 11
4.2. Recommendations for ICMPv6 Transit Traffic . . . . . . . . 12 4.2. Interaction of Link Local Messages with
4.2.1. Traffic that Must NOT be Dropped . . . . . . . . . . . 12 Firewall/Routers and Firewall/Bridges . . . . . . . . . . 12
4.2.2. Traffic that Normally Should Not be Dropped . . . . . 12 4.3. Recommendations for ICMPv6 Transit Traffic . . . . . . . . 12
4.2.3. Traffic that May be Dropped but will be Caught 4.3.1. Traffic that Must Not be Dropped . . . . . . . . . . . 13
Anyway . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.2. Traffic that Normally Should Not be Dropped . . . . . 13
4.2.4. Traffic for which a Dropping Policy Should be 4.3.3. Traffic that will be Dropped Anyway - No Special
Defined . . . . . . . . . . . . . . . . . . . . . . . 14 Attention Needed . . . . . . . . . . . . . . . . . . . 13
4.2.5. Traffic which Should be Dropped Unless a Good Case
can be Made . . . . . . . . . . . . . . . . . . . . . 14
4.3. Recommendations for ICMPv6 Local Configuration Traffic . . 15
4.3.1. Traffic that Must NOT be Dropped . . . . . . . . . . . 15
4.3.2. Traffic that Normally Should Not be Dropped . . . . . 16
4.3.3. Traffic that May be Dropped but will be Caught
Anyway . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.4. Traffic for which a Dropping Policy Should be 4.3.4. Traffic for which a Dropping Policy Should be
Defined . . . . . . . . . . . . . . . . . . . . . . . 17 Defined . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.5. Traffic which Should be Dropped Unless a Good Case 4.3.5. Traffic which Should be Dropped Unless a Good Case
can be Made . . . . . . . . . . . . . . . . . . . . . 17 can be Made . . . . . . . . . . . . . . . . . . . . . 15
4.4. Recommendations for ICMPv6 Local Configuration Traffic . . 16
4.4.1. Traffic that Must Not be Dropped . . . . . . . . . . . 16
4.4.2. Traffic that Normally Should Not be Dropped . . . . . 17
4.4.3. Traffic that will be Dropped Anyway - No Special
Attention Needed . . . . . . . . . . . . . . . . . . . 17
4.4.4. Traffic for which a Dropping Policy Should be
Defined . . . . . . . . . . . . . . . . . . . . . . . 17
4.4.5. Traffic which Should be Dropped Unless a Good Case
can be Made . . . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 20 Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 21
A.1. Destination Unreachable Error Message . . . . . . . . . . 20 A.1. Destination Unreachable Error Message . . . . . . . . . . 21
A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 20 A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 21
A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 21 A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 22
A.4. Parameter Problem Error Message . . . . . . . . . . . . . 21 A.4. Parameter Problem Error Message . . . . . . . . . . . . . 22
A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 22 A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 23
A.6. Neighbor Solicitation and Neighbor Advertisement A.6. Neighbor Solicitation and Neighbor Advertisement
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 23 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 23
A.7. Router Solicitation and Router Advertisement Messages . . 23 A.7. Router Solicitation and Router Advertisement Messages . . 24
A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 23 A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 24
A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 23 A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 24
A.10. Multicast Listener Discovery Messages . . . . . . . . . . 24 A.10. Multicast Listener Discovery Messages . . . . . . . . . . 24
A.11. Multicast Router Discovery Messages . . . . . . . . . . . 24 A.11. Multicast Router Discovery Messages . . . . . . . . . . . 25
A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 24 A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 25
A.13. Node Information Query and Reply . . . . . . . . . . . . . 24 A.13. Node Information Query and Reply . . . . . . . . . . . . . 25
A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 25 A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 25
A.15. Unused and Experimental Messages . . . . . . . . . . . . . 25 A.15. Unused and Experimental Messages . . . . . . . . . . . . . 26
Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 26 Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 36
1. Introduction 1. Introduction
When a network supports IPv6 [RFC2460], the Internet Control Message When a network supports IPv6 [RFC2460], the Internet Control Message
Protocol version 6 (ICMPv6) [RFC4443], [I-D.ietf-ipngwg-icmp-v3] Protocol version 6 (ICMPv6) [RFC4443], [I-D.ietf-ipngwg-icmp-v3]
plays a fundamental role including being an essential component in plays a fundamental role including being an essential component in
establishing communications both at the interface level and for establishing communications both at the interface level and for
sessions to remote nodes. This means that overly aggressive sessions to remote nodes. This means that overly aggressive
filtering of ICMPv6 may have a detrimental effect on the filtering of ICMPv6 may have a detrimental effect on the
establishment of IPv6 communications. On the other hand, allowing establishment of IPv6 communications. On the other hand, allowing
skipping to change at page 4, line 25 skipping to change at page 4, line 25
risk. This document recommends a set of rules which seek to balance risk. This document recommends a set of rules which seek to balance
effective IPv6 communication against the needs of site security. effective IPv6 communication against the needs of site security.
Readers familiar with ICMPv6 can skip to the recommended filtering Readers familiar with ICMPv6 can skip to the recommended filtering
rules in Section 4 and an example configuration script for Linux rules in Section 4 and an example configuration script for Linux
netfilter in Appendix B. netfilter in Appendix B.
ICMPv6 has a large number of functions defined in a number of sub- ICMPv6 has a large number of functions defined in a number of sub-
protocols, and there are a correspondingly large number of messages protocols, and there are a correspondingly large number of messages
and options within these messages. The functions currently defined and options within these messages. The functions currently defined
are: fall into a number of categories:
o Returning error messages to the source if a packet could not be Returning Error Messages
delivered. Four different error messages, each with a number of * Returning error messages to the source if a packet could not
sub-types are specified in [RFC4443]. be delivered. Four different error messages, each with a
o Simple monitoring of connectivity through echo requests and number of sub-types are specified in [RFC4443].
responses used by the ping and traceroute utilities. The Echo Connection Checking
Request and Echo Response messages are specified in [RFC4443]. * Simple monitoring of connectivity through echo requests and
o Finding neighbors (both routers and hosts) connected to the same responses used by the ping and traceroute utilities. The
link and determining their IP and link layer addresses. These Echo Request and Echo Response messages are specified in
messages are also used to check the uniqueness of any addresses [RFC4443].
that an interface proposes to use (Duplicate Address Detection - Discovery Functions
DAD)). Four messages - Neighbor Solicitation (NS), Neighbor * Finding neighbors (both routers and hosts) connected to the
Advertisement (NA), Router Solicitation (RS) and Router same link and determining their IP and link layer addresses.
Advertisement (RA) - are specified in [RFC2461]. These messages are also used to check the uniqueness of any
o Ensuring that neighbors remain reachable using the same IP and addresses that an interface proposes to use (Duplicate
link layer addresses after initial discovery (Neighbor Address Detection - DAD)). Four messages - Neighbor
Unreachability Discovery - NUD) and notifying neighbors of changes Solicitation (NS), Neighbor Advertisement (NA), Router
to link layer addresses. Uses NS and NA [RFC2461]. Solicitation (RS) and Router Advertisement (RA) - are
o Finding routers and determining how to obtain IP addresses to join specified in [RFC2461].
the subnets supported by the routers. Uses RS and RA * Ensuring that neighbors remain reachable using the same IP
[RFC2461].[[anchor2: [RFC Editor: Please update references to and link layer addresses after initial discovery (Neighbor
RFC2461 when the new version of RFC2461 is published.] --Authors]] Unreachability Discovery - NUD) and notifying neighbors of
o If stateless auto-configuration of hosts is enabled, communicating changes to link layer addresses. Uses NS and NA [RFC2461].
prefixes and other configuration information (including the link * Finding routers and determining how to obtain IP addresses
MTU and suggested hop limit default) from routers to hosts. Uses to join the subnets supported by the routers. Uses RS and
RS and RA [RFC2462]. [[anchor3: [RFC Editor: Please update RA [RFC2461].[[anchor2: [RFC Editor: Please update
references to RFC2462 when the new version of RFC2462 is references to RFC2461 when the new version of RFC2461 is
published.] --Authors]] published.] --Authors]]
o Using SEcure Neighbor Discovery (SEND) to authenticate a router * If stateless auto-configuration of hosts is enabled,
attached to a link, the Certificate Path Solicitation and communicating prefixes and other configuration information
Advertisement messages specified in [RFC3971] are used by hosts to (including the link MTU and suggested hop limit default)
retrieve the trust chain between a trust anchor and the router from routers to hosts. Uses RS and RA [RFC2462]. [[anchor3:
certificate from the router. [RFC Editor: Please update references to RFC2462 when the
o Redirecting packets to a more appropriate router on the local link new version of RFC2462 is published.] --Authors]]
for the destination address or pointing out that a destination is * Using SEcure Neighbor Discovery (SEND) to authenticate a
actually on the local link even if it is not obvious from the IP router attached to a link, the Certificate Path Solicitation
address (where a link supports multiple subnets). The Redirect and Advertisement messages specified in [RFC3971] are used
message is specified in [RFC2461]. by hosts to retrieve the trust chain between a trust anchor
o Supporting renumbering of networks by allowing the prefixes and the router certificate from the router.
advertised by routers to be altered. Uses NS, NA, RS and RA * Determining the Maximum Transmission Unit (MTU) along a
together with the Router Renumbering message specified in path. The Packet Too Big error message is essential to this
[RFC2894]. function [RFC1981].
o Determining the Maximum Transmission Unit (MTU) along a path. The * Providing a means to discover the IPv6 addresses associated
Packet Too Big error message is essential to this function with the link layer address of an interface (the inverse of
[RFC1981]. Neighbor Discovery, where the link layer address is
o Providing a means to discover the IPv6 addresses associated with discovered given an IPv6 address). Two messages, Inverse
the link layer address of an interface (the inverse of Neighbor Neighbor Discovery Solicitation and Advertisement messages
Discovery, where the link layer address is discovered given an are specified in [RFC3122].
IPv6 address). Two messages, Inverse Neighbor Discovery * Communicating which multicast groups have listeners on a
Solicitation and Advertisement messages are specified in link to the multicast capable routers connected to the link.
[RFC3122]. Uses messages Multicast Listener Query, Multicast Listener
o Communicating which multicast groups have listeners on a link to Report (two versions) and Multicast Listener Done (version 1
the multicast capable routers connected to the link. Uses only) as specified in Multicast Listener Discovery MLDv1
messages Multicast Listener Query, Multicast Listener Report (two [RFC2710] and MLDv2[RFC3810].
versions) and Multicast Listener Done (version 1 only) as * Discovering multicast routers attached to the local link.
specified in Multicast Listener Discovery MLDv1 [RFC2710] and Uses messages Multicast Router Advertisement, Multicast
MLDv2[RFC3810]. Router Solicitation and Multicast Router Termination as
o Discovering multicast routers attached to the local link. Uses specified in Multicast Router Discovery [RFC4286].
messages Multicast Router Advertisement, Multicast Router Reconfiguration Functions
Solicitation and Multicast Router Termination as specified in * Redirecting packets to a more appropriate router on the
Multicast Router Discovery [RFC4286]. local link for the destination address or pointing out that
o Providing support for some aspects of Mobile IPv6 especially a destination is actually on the local link even if it is
dealing with the IPv6 Mobile Home Agent functionality provided in not obvious from the IP address (where a link supports
routers and needed to support a Mobile node homed on the link. multiple subnets). The Redirect message is specified in
The Home Agent Address Discovery Request and Reply; and Mobile [RFC2461].
Prefix Solicitation and Advertisement messages are specified in * Supporting renumbering of networks by allowing the prefixes
[RFC3775] advertised by routers to be altered. Uses NS, NA, RS and RA
o An experimental extension to ICMPv6 specifies the ICMP Node together with the Router Renumbering message specified in
Information Query and Response messages which can be used to [RFC2894].
retrieve some basic information about nodes [I-D.ietf-ipngwg-icmp- Mobile IPv6 Support
name-lookups]. * Providing support for some aspects of Mobile IPv6 especially
o The SEAmless IP MOBility (seamoby) working group specified a pair dealing with the IPv6 Mobile Home Agent functionality
of experimental protocols which use an ICMPv6 message specified in provided in routers and needed to support a Mobile node
[RFC4065] to help in locating an access router and moving the homed on the link. The Home Agent Address Discovery Request
attachment point of a mobile node from one access router to and Reply; and Mobile Prefix Solicitation and Advertisement
another. messages are specified in [RFC3775]
Experimental Extensions
* An experimental extension to ICMPv6 specifies the ICMP Node
Information Query and Response messages which can be used to
retrieve some basic information about nodes [I-D.ietf-
ipngwg-icmp-name-lookups].
* The SEAmless IP MOBility (seamoby) working group specified a
pair of experimental protocols which use an ICMPv6 message
specified in [RFC4065] to help in locating an access router
and moving the attachment point of a mobile node from one
access router to another.
Many of these messages should only be used in a link-local context Many of these messages should only be used in a link-local context
rather than end-to-end, and filters need to be concerned with the rather than end-to-end, and filters need to be concerned with the
type of addresses in ICMPv6 packets as well as the specific source type of addresses in ICMPv6 packets as well as the specific source
and destination addresses. and destination addresses.
Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be
treated as an auxiliary function with packets that can be dropped in treated as an auxiliary function with packets that can be dropped in
most cases without damaging the functionality of the network. This most cases without damaging the functionality of the network. This
means that firewall filters for ICMPv6 have to be more carefully means that firewall filters for ICMPv6 have to be more carefully
skipping to change at page 7, line 23 skipping to change at page 7, line 34
are also messages that we can classify as 'any-to-end', which can be are also messages that we can classify as 'any-to-end', which can be
sent from any point within a path back to the source; typically these sent from any point within a path back to the source; typically these
are used to announce an error in processing the original packet. For are used to announce an error in processing the original packet. For
instance, the address resolution messages are solely for local instance, the address resolution messages are solely for local
communications [RFC2461], whereas the Destination Unreachable communications [RFC2461], whereas the Destination Unreachable
messages are any-to-end in nature. Generally end-to-end and any-to- messages are any-to-end in nature. Generally end-to-end and any-to-
end messages might be expected to pass through firewalls depending on end messages might be expected to pass through firewalls depending on
policies but local communications must not. policies but local communications must not.
Local communications will use link-local addresses in many cases but Local communications will use link-local addresses in many cases but
may also use global unicast addresses for example when configuring may also use global unicast addresses when configuring global
global addresses. Also some ICMPv6 messages in local communications addresses, for example. Also some ICMPv6 messages used in local
may contravene the usual rules requiring compatible scopes for source communications may contravene the usual rules requiring compatible
and destination addresses. scopes for source and destination addresses.
2.4. Role in Establishing Communication 2.4. Role in Establishing Communication
Many ICMPv6 messages have a role in establishing communications to Many ICMPv6 messages have a role in establishing communications to
and from the firewall and such messages have to be accepted by and from the firewall and such messages have to be accepted by
firewalls for local delivery. Generally a firewall will also by firewalls for local delivery. Generally a firewall will also be
acting as a router so that all the messages that might be used in acting as a router so that all the messages that might be used in
configuring a router interface need to be accepted and generated. configuring a router interface need to be accepted and generated.
This type of communication establishment messages should not be This type of communication establishment messages should not be
passed through a firewall as they are normally intended for use passed through a firewall as they are normally intended for use
within a link. within a link.
On the other hand, most ICMPv6 error messages traveling end-to-end or On the other hand, most ICMPv6 error messages traveling end-to-end or
any-to-end are essential to the establishment of communications. any-to-end are essential to the establishment of communications.
These messages must be passed through firewalls and might also be These messages must be passed through firewalls and might also be
sent to and from firewalls to assist with establishment of sent to and from firewalls to assist with establishment of
communications. For example the Packet Too Big error message is communications. For example the Packet Too Big error message is
needed to establish the MTU along a path. needed to establish the MTU along a path.
The remaining ICMPv6 messages which are not associated with The remaining ICMPv6 messages which are not associated with
communication establishment will normally be legitimately attempting communication establishment will normally be legitimately attempting
to pass through a firewall from inside to out or vice versa, but in to pass through a firewall from inside to out or vice versa, but in
most cases decisions as to whether to allow them to pass or not can most cases decisions as to whether to allow them to pass or not can
be made on the basis of local policy without interfering with the be made on the basis of local policy without interfering with the
skipping to change at page 8, line 43 skipping to change at page 9, line 7
the traffic through to make sure that efficient communication can be the traffic through to make sure that efficient communication can be
established. established.
SEND [RFC3971] has been specified as a means to improve the security SEND [RFC3971] has been specified as a means to improve the security
of local ICMPv6 communications. SEND sidesteps security association of local ICMPv6 communications. SEND sidesteps security association
bootstrapping problems that would result if IPsec was used. SEND bootstrapping problems that would result if IPsec was used. SEND
affects only link local messages and does not limit the filtering affects only link local messages and does not limit the filtering
which firewalls can apply and its role in security is therefore not which firewalls can apply and its role in security is therefore not
discussed further in this document. discussed further in this document.
Firewalls will normally be concerned to monitor ICMPv6 to control the Firewalls will normally be used to monitor ICMPv6 to control the
following security concerns: following security concerns:
3.1. Denial of Service Attacks 3.1. Denial of Service Attacks
ICMPv6 can be used to cause a Denial of Service(DoS) in a number of ICMPv6 can be used to cause a Denial of Service(DoS) in a number of
ways, including simply sending excessive numbers of ICMPv6 packets to ways, including simply sending excessive numbers of ICMPv6 packets to
destinations in the site and sending error messages which disrupt destinations in the site and sending error messages which disrupt
established communications by causing sessions to be dropped. Also established communications by causing sessions to be dropped. Also
if spurious communication establishment messages can be passed on to if spurious communication establishment messages can be infiltrated
link it might be possible to invalidate legitimate addresses or on to a link it might be possible to invalidate legitimate addresses
disable interfaces. or disable interfaces.
3.2. Probing 3.2. Probing
A major security consideration is preventing attackers probing the A major security consideration is preventing attackers probing the
site to determine the topology and identify hosts that might be site to determine the topology and identify hosts that might be
vulnerable to attack. Carefully crafted but, often, malformed vulnerable to attack. Carefully crafted but, often, malformed
messages can be used to provoke ICMPv6 responses from hosts thereby messages can be used to provoke ICMPv6 responses from hosts thereby
informing attackers of potential targets for future attacks. However informing attackers of potential targets for future attacks. However
the very large address space of IPv6 makes probing a less effective the very large address space of IPv6 makes probing a less effective
weapon as compared with IPv4 provided that addresses are not weapon as compared with IPv4 provided that addresses are not
allocated in an easily guessable fashion. This subject is explored allocated in an easily guessable fashion. This subject is explored
in more depth in [I-D.chown-v6ops-port-scanning-implications]. in more depth in [I-D.ietf-v6ops-scanning-implications].
3.3. Redirection Attacks 3.3. Redirection Attacks
A redirection attack could be used by a malicious sender to perform A redirection attack could be used by a malicious sender to perform
man-in-the-middle attacks or divert packets either to a malicious man-in-the-middle attacks or divert packets either to a malicious
monitor or to cause DoS by blackholing the packets. These attacks monitor or to cause DoS by blackholing the packets. These attacks
would normally have to be carried out locally on a link using the would normally have to be carried out locally on a link using the
Redirect message. Administrators need to decide if the improvement Redirect message. Administrators need to decide if the improvement
in efficiency from using Redirect messages is worth the risk of in efficiency from using Redirect messages is worth the risk of
malicious use. Factors to consider include the physical security of malicious use. Factors to consider include the physical security of
the link and the complexity of addressing on the link. For example, the link and the complexity of addressing on the link. For example,
on a wireless link, redirection would be a serious hazard due to the on a wireless link, redirection would be a serious hazard due to the
lack of physical security. On the other hand, with a wired link in a lack of physical security. On the other hand, with a wired link in a
secure building with complex addressing and redundant routers, the secure building with complex addressing and redundant routers, the
efficiency gains might well outweigh the small risk of a rogue node efficiency gains might well outweigh the small risk of a rogue node
being connected. being connected.
3.4. Renumbering Attacks 3.4. Renumbering Attacks
Spurious Renumbering messages could lead to the disruption of a site Spurious Renumbering messages can lead to the disruption of a site.
and should not be allowed through a firewall in general. Renumbering Although Renumbering messages are required to be authenticated with
messages are required to be authenticated with IPsec so that it is IPsec, so that it is difficult to carry out such attacks in practice,
difficult to carry out such attacks in practice. they should not be allowed through a firewall.
3.5. Problems Resulting from ICMPv6 Transparency 3.5. Problems Resulting from ICMPv6 Transparency
Because some ICMPv6 error packets need to be passed through a Because some ICMPv6 error packets need to be passed through a
firewall in both directions. This means that the ICMPv6 error firewall in both directions, malicious users can potentially use
packets can be exchanged between inside and outside without any these messages to communicate between inside and outside, bypassing
filtering. administrative inspection. For example it might be possible to carry
out a covert conversation through the payload of ICMPv6 error
Using this feature, malicious users can communicate between the messages or tunnel inappropriate encapsulated IP packets in ICMPv6
inside and outside of a firewall bypassing the administrator's error messages. This problem can be alleviated by filtering ICMPv6
inspection (proxy, firewall etc.). For example it might be possible errors using a deep packet inspection mechanism to ensure that the
to carry out a covert conversation through the payload of ICMPv6 packet carried as a payload is associated with legitimate traffic to
error messages or tunnel inappropriate encapsulated IP packets in or from the protected network.
ICMPv6 error messages. This problem can be alleviated by filtering
ICMPv6 errors using a deep packet inspection mechanism to ensure that
the packet carried as a payload is associated with legitimate traffic
to or from the protected network.
4. Filtering Recommendations 4. Filtering Recommendations
When designing firewall filtering rules for ICMPv6, the rules can be When designing firewall filtering rules for ICMPv6, the rules can be
divided into two classes: divided into two classes:
o Rules for ICMPv6 traffic transiting the firewall o Rules for ICMPv6 traffic transiting the firewall
o Rules for ICMPv6 directed to interfaces on the firewall o Rules for ICMPv6 directed to interfaces on the firewall
This section suggests some common considerations which should be This section suggests some common considerations which should be
borne in mind when designing filtering rules and then categorizes the borne in mind when designing filtering rules and then categorizes the
rules for each class. The categories are: rules for each class. The categories are:
o Messages that must not be dropped: usually because establishment o Messages that must not be dropped: usually because establishment
of communications will be prevented or severely impacted. of communications will be prevented or severely impacted.
o Messages that should not be dropped: administrators need to have a o Messages that should not be dropped: administrators need to have a
very good reason for dropping this category very good reason for dropping this category
o Messages that may be dropped but it is not essential because they o Messages that may be dropped in firewall/routers but it is not
would normally be dropped for other reasons (e.g., because they essential because they would normally be dropped for other reasons
would be using link-local addresses) or the protocol specification (e.g., because they would be using link-local addresses) or the
would cause them to be rejected if they had passed through a protocol specification would cause them to be rejected if they had
router. 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 o Messages that administrators may or may not want to drop depending
on local policy. on local policy.
o Messages that administrators should consider dropping (e.g., ICMP o Messages that administrators should consider dropping (e.g., ICMP
node information name lookup queries) node information name lookup queries)
More detailed analysis of each of the message types can be found in More detailed analysis of each of the message types can be found in
Appendix A. Appendix A.
4.1. Common Considerations 4.1. Common Considerations
skipping to change at page 11, line 12 skipping to change at page 11, line 25
may be subject to less strict policies than unauthenticated messages. may be subject to less strict policies than unauthenticated messages.
In the remainder of this section, we are generally considering what In the remainder of this section, we are generally considering what
should be configured for unauthenticated messages. In many cases it should be configured for unauthenticated messages. In many cases it
is not realistic to expect more than a tiny fraction of the messages is not realistic to expect more than a tiny fraction of the messages
to be authenticated. to be authenticated.
Where messages are not essential to the establishment of Where messages are not essential to the establishment of
communications, local policy can be used to determine whether a communications, local policy can be used to determine whether a
message should be allowed or dropped. message should be allowed or dropped.
Many of the messages used for establishment of communications on the
local link will be sent with link-local addresses for at least one of
their source and destination. Routers (and firewalls) conforming to
the IPv6 standards will not forward these packets; there is no need
to configure additional rules to prevent these packets traversing the
firewall/router. Also the specifications of ICMPv6 messages intended
for use only on the local link specify various measures which would
allow receivers to detect if the message had passed through a
firewall/router, including:
o Requiring that the hop limit in the IPv6 header is set to 255 on
transmission. On reception the hop limit is required to be still
255 which would not be the case if the packet had passed through a
firewall/router.
o Checking that the source address is a link-local unicast address.
Accordingly it is not essential to configure firewall rules to drop
illegal packets of these types. If they have non-link-local source
and destination addresses, allowing them to traverse the firewall,
they would be rejected because of the checks performed at the
destination. However, firewall administrators may still wish to log
or drop such illegal packets.
Depending on the capabilities of the firewall being configured, it Depending on the capabilities of the firewall being configured, it
may be possible for the firewall to maintain state about packets that may be possible for the firewall to maintain state about packets that
may result in error messages being returned or about ICMPv6 packets may result in error messages being returned or about ICMPv6 packets
(e.g., Echo Requests) that are expected to receive a specific (e.g., Echo Requests) that are expected to receive a specific
response. This state may allow the firewall to perform more precise response. This state may allow the firewall to perform more precise
checks based on this state, and to apply limits on the number of 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 ICMPv6 packets accepted incoming or outgoing as a result of a packet
traveling in the opposite direction. The capabilities of firewalls traveling in the opposite direction. The capabilities of firewalls
to perform such stateful packet inspection vary from model to model, to perform such stateful packet inspection vary from model to model,
and it is not assumed that firewalls are uniformly capable in this and it is not assumed that firewalls are uniformly capable in this
skipping to change at page 12, line 11 skipping to change at page 11, line 51
error message the packet can be dropped. This provides a partial error message the packet can be dropped. This provides a partial
defense against some possible attacks on TCP that use spoofed ICMPv6 defense against some possible attacks on TCP that use spoofed ICMPv6
error messages, but the checks can also be carried out at the error messages, but the checks can also be carried out at the
destination. For further information on these attacks see [I-D.gont- destination. For further information on these attacks see [I-D.gont-
tcpm-icmp-attacks]. tcpm-icmp-attacks].
In general, the scopes of source and destination addresses of ICMPv6 In general, the scopes of source and destination addresses of ICMPv6
messages should be matched, and packets with mismatched addresses messages should be matched, and packets with mismatched addresses
should be dropped if they attempt to transit a router. However some should be dropped if they attempt to transit a router. However some
of the address configuration messages carried locally on a link may of the address configuration messages carried locally on a link may
legitimately have mismatched addresses. Node implementations need to legitimately have mismatched addresses. Node implementations must
avoid over-zealous filtering of these messages delivered locally on a accept these messages delivered locally on a link and administrators
link. should be aware that they can exist.
4.2. Recommendations for ICMPv6 Transit Traffic 4.2. Interaction of Link Local Messages with Firewall/Routers and
Firewall/Bridges
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 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
which 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 assure for
themselves 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.
4.3. Recommendations for ICMPv6 Transit Traffic
This section recommends rules that should be applied to ICMPv6 This section recommends rules that should be applied to ICMPv6
traffic attempting to transit a firewall. traffic attempting to transit a firewall.
4.2.1. Traffic that Must NOT be Dropped 4.3.1. Traffic that Must Not be Dropped
Error messages that are essential to the establishment of Error messages that are essential to the establishment of
communications: communications:
o Destination Unreachable (Type 1) - All codes o Destination Unreachable (Type 1) - All codes
o Packet Too Big (Type 2) o Packet Too Big (Type 2)
o Time Exceeded (Type 3) - Code 0 only o Time Exceeded (Type 3) - Code 0 only
o Parameter Problem (Type 4) - Codes 1 and 2 only o Parameter Problem (Type 4) - Codes 1 and 2 only
Appendix A.4 suggests some more specific checks that could be Appendix A.4 suggests some more specific checks that could be
performed on Parameter Problem messages if a firewall has the performed on Parameter Problem messages if a firewall has the
necessary packet inspection capabilities. necessary packet inspection capabilities.
skipping to change at page 12, line 44 skipping to change at page 13, line 29
o Echo Response (Type 129) o Echo Response (Type 129)
For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be
possible, it is essential that the connectivity checking messages are possible, it is essential that the connectivity checking messages are
allowed through the firewall. It has been common practice in IPv4 allowed through the firewall. It has been common practice in IPv4
networks to drop Echo Request messages in firewalls to minimize the networks to drop Echo Request messages in firewalls to minimize the
risk of scanning attacks on the protected network. As discussed in 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 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 less severe and it is not necessary to filter IPv6 Echo Request
messages. messages.
4.2.2. Traffic that Normally Should Not be Dropped 4.3.2. Traffic that Normally Should Not be Dropped
Error messages other than those listed in Section 4.2.1 Error messages other than those listed in Section 4.3.1
o Time Exceeded (Type 3) - Code 1 o Time Exceeded (Type 3) - Code 1
o Parameter Problem (Type 4) - Code 0 o Parameter Problem (Type 4) - Code 0
Mobile IPv6 messages that are needed to assist mobility: Mobile IPv6 messages that are needed to assist mobility:
o Home Agent Address Discovery Request (Type 144) o Home Agent Address Discovery Request (Type 144)
o Home Agent Address Discovery Reply (Type 145) o Home Agent Address Discovery Reply (Type 145)
o Mobile Prefix Solicitation (Type 146) o Mobile Prefix Solicitation (Type 146)
o Mobile Prefix Advertisement(Type 147) o Mobile Prefix Advertisement(Type 147)
Administrators may wish to apply more selective rules as described in Administrators may wish to apply more selective rules as described in
Appendix A.14 depending on whether the site is catering for mobile Appendix A.14 depending on whether the site is catering for mobile
nodes which would normally be at home on the site and/or foreign nodes which would normally be at home on the site and/or foreign
mobile nodes roaming onto the site. mobile nodes roaming onto the site.
4.2.3. Traffic that May be Dropped but will be Caught Anyway 4.3.3. Traffic that will be Dropped Anyway - No Special Attention
Needed
The messages listed in this section are all involved with local The messages listed in this section are all involved with local
management of nodes connected to the link on which they were management of nodes connected to the logical link on which they were
initially transmitted. All these messages should never be propagated initially transmitted. All these messages should never be propagated
beyond the link on which they were initially transmitted. During beyond the link on which they were initially transmitted. If the
normal operations these messages will have destination addresses, firewall is a firewall/bridge rather than a firewall/router, these
mostly link local but in some cases global unicast addresses, of messages should be allowed to transit the firewall as they would be
interfaces on the local link. No special action is needed to filter intended for establishing communications between the two physical
messages with link-local addresses. As discussed in Section 4.1 parts of the link that are bridged into a single logical link.
these messages are specified so that either the receiver is able to
check that the message has not passed through a firewall/router or it During normal operations these messages will have destination
will be dropped at the first router it encounters. Administrators addresses, mostly link local but in some cases global unicast
may wish to consider providing rules to catch illegal packets sent addresses, of interfaces on the local link. No special action is
with hop limit = 1 to avoid ICMPv6 Time Exceeded messages being needed to filter messages with link-local addresses in a firewall/
generated for these packets. 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 Address Configuration and Router Selection messages (must be received
with hop limit = 255): with hop limit = 255):
o Router Solicitation (Type 133) o Router Solicitation (Type 133)
o Router Advertisement (Type 134) o Router Advertisement (Type 134)
o Neighbor Solicitation (Type 135) o Neighbor Solicitation (Type 135)
o Neighbor Advertisement (Type 136) o Neighbor Advertisement (Type 136)
o Redirect (Type 137) o Redirect (Type 137)
o Inverse Neighbor Discovery Solicitation (Type 141) o Inverse Neighbor Discovery Solicitation (Type 141)
o Inverse Neighbor Discovery Advertisement (Type 142) o Inverse Neighbor Discovery Advertisement (Type 142)
skipping to change at page 14, line 12 skipping to change at page 14, line 49
hop limit = 255): hop limit = 255):
o Certificate Path Solicitation (Type 148) o Certificate Path Solicitation (Type 148)
o Certificate Path Advertisement (type 149) o Certificate Path Advertisement (type 149)
Multicast Router Discovery messages (must have link-local source Multicast Router Discovery messages (must have link-local source
address and hop limit = 1): address and hop limit = 1):
o Multicast Router Advertisement (Type 151) o Multicast Router Advertisement (Type 151)
o Multicast Router Solicitation (Type 152) o Multicast Router Solicitation (Type 152)
o Multicast Router Termination (Type 153) o Multicast Router Termination (Type 153)
4.2.4. Traffic for which a Dropping Policy Should be Defined 4.3.4. Traffic for which a Dropping Policy Should be Defined
The message which the experimental Seamoby protocols are using will The message type that the experimental Seamoby protocols are using
be expected to have to cross site boundaries. Administrators should will be expected to have to cross site boundaries in normal
determine if they need to support these experiments and otherwise operation. Administrators should determine if they need to support
messages of this type should be dropped: these experiments and otherwise messages of this type should be
dropped:
o Seamoby Experimental (Type 150) o Seamoby Experimental (Type 150)
Error messages not currently defined by IANA: Error messages not currently defined by IANA:
o Unallocated Error messages (Types 5-99 and 102-126, inclusive) o Unallocated Error messages (Types 5-99 and 102-126, inclusive)
The base ICMPv6 specification suggests that error messages which are The base ICMPv6 specification suggests that error messages which are
not explicitly known to a node should be forwarded and passed to any 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 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 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 channel or form part of a DoS attack. Administrators should be aware
of this and determine whether they wish to allow these messages of this and determine whether they wish to allow these messages
through the firewall. through the firewall.
4.2.5. Traffic which Should be Dropped Unless a Good Case can be Made 4.3.5. Traffic which Should be Dropped Unless a Good Case can be Made
Node Information enquiry messages should generally not be forwarded Node Information enquiry messages should generally not be forwarded
across site boundaries. Some of these messages will be using non- across site boundaries. Some of these messages will be using non-
link-local unicast addresses so that they will not necessarily be link-local unicast addresses so that they will not necessarily be
dropped by address scope limiting rules: dropped by address scope limiting rules:
o Node Information Query (Type 139) o Node Information Query (Type 139)
o Node Information Response (Type 140) o Node Information Response (Type 140)
Router Renumbering messages should not be forwarded across site Router Renumbering messages should not be forwarded across site
boundaries. As originally specified, these messages may use a site boundaries. As originally specified, these messages may use a site
skipping to change at page 15, line 16 skipping to change at page 16, line 4
Messages with types in the experimental allocations: Messages with types in the experimental allocations:
o Types 100, 101, 200 and 201. o Types 100, 101, 200 and 201.
Messages using the extension type numbers until such time as ICMPv6 Messages using the extension type numbers until such time as ICMPv6
needs to use such extensions: needs to use such extensions:
o Types 127 and 255. o Types 127 and 255.
All informational messages with types not explicitly assigned by All informational messages with types not explicitly assigned by
IANA, currently: IANA, currently:
o Types 154 - 199 inclusive and 202 - 254 inclusive. o Types 154 - 199 inclusive and 202 - 254 inclusive.
Note that the base ICMPv6 specification requires that informational Note that the base ICMPv6 specification requires that informational
messages with unknown types must be silently discarded. messages with unknown types must be silently discarded.
4.3. Recommendations for ICMPv6 Local Configuration Traffic 4.4. Recommendations for ICMPv6 Local Configuration Traffic
This section recommends filtering rules for ICMPv6 traffic addressed This section recommends filtering rules for ICMPv6 traffic addressed
to an interface on a firewall. For a small number of messages, the to an interface on a firewall. For a small number of messages, the
desired behavior may differ between interfaces on the site or private 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 side of the firewall and the those on the public Internet side of the
firewall. firewall.
4.3.1. Traffic that Must NOT be Dropped 4.4.1. Traffic that Must Not be Dropped
Error messages that are essential to the establishment of Error messages that are essential to the establishment of
communications: communications:
o Destination Unreachable (Type 1) - All codes o Destination Unreachable (Type 1) - All codes
o Packet Too Big (Type 2) o Packet Too Big (Type 2)
o Time Exceeded (Type 3) - Code 0 only o Time Exceeded (Type 3) - Code 0 only
o Parameter Problem (Type 4) - Codes 1 and 2 only o Parameter Problem (Type 4) - Codes 1 and 2 only
Connectivity checking messages: Connectivity checking messages:
o Echo Request (Type 128) o Echo Request (Type 128)
o Echo Response (Type 129) o Echo Response (Type 129)
As discussed in Section 4.2.1, dropping connectivity checking As discussed in Section 4.3.1, dropping connectivity checking
messages will prevent the firewall being the destination of a Teredo messages will prevent the firewall being the destination of a Teredo
tunnel and it is not considered necessary to disable connectivity tunnel and it is not considered necessary to disable connectivity
checking in IPv6 networks because port scanning is less of a security checking in IPv6 networks because port scanning is less of a security
risk. risk.
There are a number of other sets of messages which play a role in There are a number of other sets of messages which play a role in
configuring the node and maintaining unicast and multicast configuring the node and maintaining unicast and multicast
communications through the interfaces of a node. These messages must communications through the interfaces of a node. These messages must
not be dropped if the node is to successfully participate in an IPv6 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 network. The exception to this is the Redirect message for which an
explicit policy decision should be taken (see Section 4.3.4). explicit policy decision should be taken (see Section 4.4.4).
Address Configuration and Router Selection messages: Address Configuration and Router Selection messages:
o Router Solicitation (Type 133) o Router Solicitation (Type 133)
o Router Advertisement (Type 134) o Router Advertisement (Type 134)
o Neighbor Solicitation (Type 135) o Neighbor Solicitation (Type 135)
o Neighbor Advertisement (Type 136) o Neighbor Advertisement (Type 136)
o Inverse Neighbor Discovery Solicitation (Type 141) o Inverse Neighbor Discovery Solicitation (Type 141)
o Inverse Neighbor Discovery Advertisement (Type 142) o Inverse Neighbor Discovery Advertisement (Type 142)
Link-local multicast receiver notification messages: Link-local multicast receiver notification messages:
skipping to change at page 16, line 14 skipping to change at page 17, line 4
Address Configuration and Router Selection messages: Address Configuration and Router Selection messages:
o Router Solicitation (Type 133) o Router Solicitation (Type 133)
o Router Advertisement (Type 134) o Router Advertisement (Type 134)
o Neighbor Solicitation (Type 135) o Neighbor Solicitation (Type 135)
o Neighbor Advertisement (Type 136) o Neighbor Advertisement (Type 136)
o Inverse Neighbor Discovery Solicitation (Type 141) o Inverse Neighbor Discovery Solicitation (Type 141)
o Inverse Neighbor Discovery Advertisement (Type 142) o Inverse Neighbor Discovery Advertisement (Type 142)
Link-local multicast receiver notification messages: Link-local multicast receiver notification messages:
o Listener Query (Type 130) o Listener Query (Type 130)
o Listener Report (Type 131) o Listener Report (Type 131)
o Listener Done (Type 132) o Listener Done (Type 132)
o Listener Report v2 (Type 143) o Listener Report v2 (Type 143)
SEND Certificate Path notification messages: SEND Certificate Path notification messages:
o Certificate Path Solicitation (Type 148) o Certificate Path Solicitation (Type 148)
o Certificate Path Advertisement (type 149) o Certificate Path Advertisement (type 149)
Multicast Router Discovery messages : Multicast Router Discovery messages :
o Multicast Router Advertisement (Type 151) o Multicast Router Advertisement (Type 151)
o Multicast Router Solicitation (Type 152) o Multicast Router Solicitation (Type 152)
o Multicast Router Termination (Type 153) o Multicast Router Termination (Type 153)
4.3.2. Traffic that Normally Should Not be Dropped 4.4.2. Traffic that Normally Should Not be Dropped
Error messages other than those listed in Section 4.3.1: Error messages other than those listed in Section 4.4.1:
o Time Exceeded (Type 3) - Code 1 o Time Exceeded (Type 3) - Code 1
o Parameter Problem (Type 4) - Code 0 o Parameter Problem (Type 4) - Code 0
4.3.3. Traffic that May be Dropped but will be Caught Anyway 4.4.3. Traffic that will be Dropped Anyway - No Special Attention
Needed
Router Renumbering messages must be authenticated using IPsec, so it Router Renumbering messages must be authenticated using IPsec, so it
is not essential to filter these messages even if they are not is not essential to filter these messages even if they are not
allowed at the firewall: allowed at the firewall/router:
o Router Renumbering (Type 139) o Router Renumbering (Type 139)
Mobile IPv6 messages that are needed to assist mobility: Mobile IPv6 messages that are needed to assist mobility:
o Home Agent Address Discovery Request (Type 144) o Home Agent Address Discovery Request (Type 144)
o Home Agent Address Discovery Reply (Type 145) o Home Agent Address Discovery Reply (Type 145)
o Mobile Prefix Solicitation (Type 146) o Mobile Prefix Solicitation (Type 146)
o Mobile Prefix Advertisement(Type 147) o Mobile Prefix Advertisement(Type 147)
It may be desirable to drop these messages, especially on public It may be desirable to drop these messages, especially on public
interfaces, if the firewall is not also providing mobile Home Agent interfaces, if the firewall is not also providing mobile Home Agent
services, but they will be ignored otherwise. services, but they will be ignored otherwise.
skipping to change at page 17, line 4 skipping to change at page 17, line 44
o Home Agent Address Discovery Request (Type 144) o Home Agent Address Discovery Request (Type 144)
o Home Agent Address Discovery Reply (Type 145) o Home Agent Address Discovery Reply (Type 145)
o Mobile Prefix Solicitation (Type 146) o Mobile Prefix Solicitation (Type 146)
o Mobile Prefix Advertisement(Type 147) o Mobile Prefix Advertisement(Type 147)
It may be desirable to drop these messages, especially on public It may be desirable to drop these messages, especially on public
interfaces, if the firewall is not also providing mobile Home Agent interfaces, if the firewall is not also providing mobile Home Agent
services, but they will be ignored otherwise. services, but they will be ignored otherwise.
The message used by the experimental Seamoby protocols may be dropped The message used by the experimental Seamoby protocols may be dropped
but will be ignored if the service is not implemented: but will be ignored if the service is not implemented:
o Seamoby Experimental (Type 150) o Seamoby Experimental (Type 150)
4.3.4. Traffic for which a Dropping Policy Should be Defined 4.4.4. Traffic for which a Dropping Policy Should be Defined
Redirect messages provide a significant security risk and Redirect messages provide a significant security risk and
administrators should take a case-by-case view of whether firewalls, administrators should take a case-by-case view of whether firewalls,
routers in general and other nodes should accept these messages: routers in general and other nodes should accept these messages:
o Redirect (Type 137) o Redirect (Type 137)
Conformant nodes must provide configuration controls which allow Conformant nodes must provide configuration controls which allow
nodes to control their behavior with respect to Redirect messages so nodes to control their behavior with respect to Redirect messages so
that it should only be necessary to install specific filtering rules that it should only be necessary to install specific filtering rules
under special circumstances, such as if Redirect messages are under special circumstances, such as if Redirect messages are
accepted on private interfaces but not public ones. accepted on private interfaces but not public ones.
If a node implements the experimental Node Information service, the If a node implements the experimental Node Information service, the
administrator needs to make an explicit decision as to whether the administrator needs to make an explicit decision as to whether the
node should respond to or accept Node Information messages on each node should respond to or accept Node Information messages on each
skipping to change at page 17, line 40 skipping to change at page 18, line 33
o Unallocated Error messages (Types 5-99 and 102-126, inclusive) o Unallocated Error messages (Types 5-99 and 102-126, inclusive)
The base ICMPv6 specification suggests that error messages which are The base ICMPv6 specification suggests that error messages which are
not explicitly known to a node should be forwarded and passed to any 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 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 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 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 of this and determine whether they wish to allow these messages to be
sent to the firewall. sent to the firewall.
4.3.5. Traffic which Should be Dropped Unless a Good Case can be Made 4.4.5. Traffic which Should be Dropped Unless a Good Case can be Made
Messages with types in the experimental allocations: Messages with types in the experimental allocations:
o Types 100, 101, 200 and 201. o Types 100, 101, 200 and 201.
Messages using the extension type numbers until such time as ICMPv6 Messages using the extension type numbers until such time as ICMPv6
needs to use such extensions: needs to use such extensions:
o Types 127 and 255. o Types 127 and 255.
All informational messages with types not explicitly assigned by All informational messages with types not explicitly assigned by
IANA, currently: IANA, currently:
skipping to change at page 19, line 43 skipping to change at page 20, line 33
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, December 2005. RFC 4286, December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
7.2. Informative References 7.2. Informative References
[I-D.chown-v6ops-port-scanning-implications]
Chown, T., "IPv6 Implications for TCP/UDP Port Scanning",
draft-chown-v6ops-port-scanning-implications-02 (work in
progress), October 2005.
[I-D.gont-tcpm-icmp-attacks] [I-D.gont-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP", Gont, F., "ICMP attacks against TCP",
draft-gont-tcpm-icmp-attacks-05 (work in progress), draft-gont-tcpm-icmp-attacks-05 (work in progress),
October 2005. October 2005.
[I-D.ietf-v6ops-scanning-implications]
Chown, T., "IPv6 Implications for Network Scanning",
draft-ietf-v6ops-scanning-implications-00 (work in
progress), June 2006.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001. January 2001.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
February 2006. February 2006.
[netfilter] [netfilter]
netfilter.org, "The netfilter.org project", Firewalling, netfilter.org, "The netfilter.org project", Firewalling,
skipping to change at page 23, line 37 skipping to change at page 24, line 24
ICMPv6 Redirect Messages(Type 137) are used on the local link to ICMPv6 Redirect Messages(Type 137) are used on the local link to
indicate that nodes are actually link-local and communications need indicate that nodes are actually link-local and communications need
not go via a router, or to indicate a more appropriate first hop not go via a router, or to indicate a more appropriate first hop
router. Although they can be used to make communications more router. Although they can be used to make communications more
efficient, they are not essential to the establishment of efficient, they are not essential to the establishment of
communications and may be a security vulnerability, particularly if a communications and may be a security vulnerability, particularly if a
link is not physically secured. Conformant nodes are required to link is not physically secured. Conformant nodes are required to
provide configuration controls which suppress the generation of provide configuration controls which suppress the generation of
Redirect messages and allow them to be ignored on reception. Using Redirect messages and allow them to be ignored on reception. Using
Redirect messages on a wireless link is particularly hazardous Redirect messages on, for example, a wireless link without link level
because of the lack of physical security. encryption/authentication is particularly hazardous because the link
is open to eavesdroppring and packet injection.
A.9. SEND Certificate Path Messages A.9. SEND Certificate Path Messages
SEND [RFC3971] uses two messages (Certificate Path Solicitation and SEND [RFC3971] uses two messages (Certificate Path Solicitation and
Advertisement - Types 148 and 149) sent from nodes to supposed Advertisement - Types 148 and 149) sent from nodes to supposed
routers on the same local link to obtain a certificate path which routers on the same local link to obtain a certificate path which
will allow the node to authenticate the router's claim to provide will allow the node to authenticate the router's claim to provide
routing services for certain prefixes. If a link connected to a routing services for certain prefixes. If a link connected to a
firewall/router is using SEND, the firewall must be able to exchange firewall/router is using SEND, the firewall must be able to exchange
these messages with nodes on the link that will use its routing these messages with nodes on the link that will use its routing
skipping to change at page 25, line 13 skipping to change at page 25, line 47
authenticated. authenticated.
A.14. Mobile IPv6 Messages A.14. Mobile IPv6 Messages
Mobile IPv6 [RFC3775] defines four ICMPv6 messages which are used to Mobile IPv6 [RFC3775] defines four ICMPv6 messages which are used to
support mobile operations: Home Agent Address Discovery Request, Home support mobile operations: Home Agent Address Discovery Request, Home
Agent Address Discovery Reply, Mobile Prefix Solicitation and ICMP Agent Address Discovery Reply, Mobile Prefix Solicitation and ICMP
Mobile Prefix Advertisement(Type 144, 145, 146 and 147) messages. Mobile Prefix Advertisement(Type 144, 145, 146 and 147) messages.
These messages are sent end-to-end between unicast addresses of a These messages are sent end-to-end between unicast addresses of a
mobile node and its home agent. They must be expected to be sent mobile node and its home agent. They must be expected to be sent
from outside a site. The two Mobile prefix messages should be from outside a site and must traverse site-boundary firewalls toreach
protected by the use of IPsec authentication. the home agent in order for Mobile IPv6 to function. The two Mobile
prefix messages should be protected by the use of IPsec
authentication.
o If the site provides home agents for mobile nodes, the firewall o If the site provides home agents for mobile nodes, the firewall
must allow incoming Home Agent Address Discovery Request and must allow incoming Home Agent Address Discovery Request and
Mobile Prefix Solicitation messages, and outgoing Home Agent Mobile Prefix Solicitation messages, and outgoing Home Agent
Address Discovery Reply and ICMP Mobile Prefix Advertisement Address Discovery Reply and ICMP Mobile Prefix Advertisement
messages. It may be desirable to limit the destination addresses messages. It may be desirable to limit the destination addresses
for the incoming messages to links that are known to support home for the incoming messages to links that are known to support home
agents. agents.
o If the site is prepared to host roaming mobile nodes, the firewall o If the site is prepared to host roaming mobile nodes, the firewall
must allow outgoing Home Agent Address Discovery Request and must allow outgoing Home Agent Address Discovery Request and
Mobile Prefix Solicitation messages, and incoming Home Agent Mobile Prefix Solicitation messages, and incoming Home Agent
skipping to change at page 26, line 36 skipping to change at page 27, line 25
site that may or may not support Mobile IPv6. site that may or may not support Mobile IPv6.
#!/bin/bash #!/bin/bash
# Set of prefixes on the trusted ("inner") side of the firewall # Set of prefixes on the trusted ("inner") side of the firewall
export INNER_PREFIXES="2001:DB8:85::/60" export INNER_PREFIXES="2001:DB8:85::/60"
# Set of hosts providing services so that they can be made pingable # Set of hosts providing services so that they can be made pingable
export PINGABLE_HOSTS="2001:DB8:85::/64" export PINGABLE_HOSTS="2001:DB8:85::/64"
# Configuration option: Change this to 1 if errors allowed only for # Configuration option: Change this to 1 if errors allowed only for
# existing sessions # existing sessions
export STATE_ENABLED=0 export STATE_ENABLED=0
# Configuration option: Change this to 1 if messages to/from link
# local addresses should be filtered.
# Do not use this if the firewall is a bridge.
# Optional for firewalls that are routers.
export FILTER_LINK_LOCAL_ADDRS=0
# Configuration option: Change this to 0 if the site does not support # Configuration option: Change this to 0 if the site does not support
# Mobile IPv6 Home Agents - see Appendix A.14 # Mobile IPv6 Home Agents - see Appendix A.14
export HOME_AGENTS_PRESENT=1 export HOME_AGENTS_PRESENT=1
# Configuration option: Change this to 0 if the site does not support # Configuration option: Change this to 0 if the site does not support
# Mobile IPv6 mobile nodes being present on the site - # Mobile IPv6 mobile nodes being present on the site -
# see Appendix A.14 # see Appendix A.14
export MOBILE_NODES_PRESENT=1 export MOBILE_NODES_PRESENT=1
ip6tables -N icmpv6-filter ip6tables -N icmpv6-filter
ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter
skipping to change at page 27, line 4 skipping to change at page 27, line 45
# see Appendix A.14 # see Appendix A.14
export MOBILE_NODES_PRESENT=1 export MOBILE_NODES_PRESENT=1
ip6tables -N icmpv6-filter ip6tables -N icmpv6-filter
ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter
# Match scope of src and dest else deny # Match scope of src and dest else deny
# This capability is not provided for in base ip6tables functionality # This capability is not provided for in base ip6tables functionality
# An extension (agr) exists which may support it. # An extension (agr) exists which may support it.
#@TODO@ #@TODO@
# ECHO REQUESTS AND RESPONSES # ECHO REQUESTS AND RESPONSES
# =========================== # ===========================
# Allow outbound echo requests from prefixes which belong to the site # Allow outbound echo requests from prefixes which belong to the site
# for inner_prefix in $INNER_PREFIXES for inner_prefix in $INNER_PREFIXES
do do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type echo-request -j ACCEPT --icmpv6-type echo-request -j ACCEPT
done done
# Allow inbound echo requests towards only predetermined hosts # Allow inbound echo requests towards only predetermined hosts
# for pingable_host in $PINGABLE_HOSTS for pingable_host in $PINGABLE_HOSTS
do do
ip6tables -A icmpv6-filter -p icmpv6 -d $pingable_host \ ip6tables -A icmpv6-filter -p icmpv6 -d $pingable_host \
--icmpv6-type echo-request -j ACCEPT --icmpv6-type echo-request -j ACCEPT
done done
if [ "$STATE_ENABLED" -eq "1" ] if [ "$STATE_ENABLED" -eq "1" ]
then then
# Allow incoming and outgoing echo reply messages # Allow incoming and outgoing echo reply messages
# only for existing sessions # only for existing sessions
ip6tables -A icmpv6-filter -m state -p icmpv6 \ ip6tables -A icmpv6-filter -m state -p icmpv6 \
skipping to change at page 27, line 45 skipping to change at page 28, line 40
done done
# Incoming echo replies to prefixes which belong to the site # Incoming echo replies to prefixes which belong to the site
for inner_prefix in $INNER_PREFIXES for inner_prefix in $INNER_PREFIXES
do do
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type echo-reply -j ACCEPT --icmpv6-type echo-reply -j ACCEPT
done done
fi fi
# Deny icmps to/from link local addresses # Deny icmps to/from link local addresses
# These rules should be redundant as routers should not forward # If the firewall is a router:
# link local addresses but to be sure... # These rules should be redundant as routers should not forward
ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP # link local addresses but to be sure...
ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP # DO NOT ENABLE these rules if the firewall is a bridge
if [ "$FILTER_LINK_LOCAL_ADDRS" -eq "1" ]
then
ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP
ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP
fi
# Drop echo replies which have a multicast address as a # Drop echo replies which have a multicast address as a
# destination # destination
ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \ ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \
--icmpv6-type echo-reply -j DROP --icmpv6-type echo-reply -j DROP
# DESTINATION UNREACHABLE ERROR MESSAGES # DESTINATION UNREACHABLE ERROR MESSAGES
# ====================================== # ======================================
if [ "$STATE_ENABLED" -eq "1" ] if [ "$STATE_ENABLED" -eq "1" ]
 End of changes. 61 change blocks. 
229 lines changed or deleted 290 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/