[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-v6ops-icmpv6-filtering-bcp

IPv6 Operations                                                E. Davies
Internet-Draft                                                Consultant
Expires: January 12, 2006                                     J. Mohacsi
                                                          NIIF/HUNGARNET
                                                           July 11, 2005


    Best Current Practice for Filtering ICMPv6 Messages in Firewalls
             draft-davies-v6ops-icmpv6-filtering-bcp-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 12, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   In networks supporting IPv6 the Internet Control Message Protocol
   version 6 (ICMPv6) plays a fundamental role with a large number of
   functions, and a correspondingly large number of message types and
   options.  A number of security risks are associated with uncontrolled
   forwarding of ICMPv6 messages, and it is desirable to configure site
   firewalls to intercept inappropriate usages of ICMPv6 which might
   allow an attacker outside a site to probe or compromise the site



Davies & Mohacsi        Expires January 12, 2006                [Page 1]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


   network.  On the other hand, compared with IPv4 and the corresponding
   protocol ICMP, ICMPv6 is essential to the functioning of IPv6 rather
   than a useful auxiliary.  Hence too aggressive filtering of ICMPv6
   messages can be detrimental to the establishment of IPv6
   communications.  This means that effective filtering of ICMPv6
   requires a more complex configuration than was needed for ICMP.  This
   document provides some recommendations for ICMPv6 firewall filter
   configuration that will allow propagation of ICMPv6 messages that are
   needed to maintain the functioning of the network but drop messages
   which are potential security risks.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Classifying ICMPv6 Messages  . . . . . . . . . . . . . . . .   5
     2.1  Error and Informational ICMPv6 Messages  . . . . . . . . .   5
     2.2  Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . .   6
     2.3  Network Topology and Address Scopes  . . . . . . . . . . .   6
     2.4  Role in Establishing Communication . . . . . . . . . . . .   6
   3.   Security Concerns for ICMPv6 Controllable by Firewall
        Configuration  . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1  Denial of Service Attacks  . . . . . . . . . . . . . . . .   7
     3.2  Probing  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.3  Redirection Attacks  . . . . . . . . . . . . . . . . . . .   8
     3.4  Renumbering Attacks  . . . . . . . . . . . . . . . . . . .   8
   4.   Filtering Recommendations  . . . . . . . . . . . . . . . . .   8
     4.1  Common Considerations  . . . . . . . . . . . . . . . . . .   8
     4.2  ICMPv6 Echo Request and Echo Response  . . . . . . . . . .   9
     4.3  Destination Unreachable Error Message  . . . . . . . . . .  10
     4.4  Packet Too Big Error Message . . . . . . . . . . . . . . .  10
     4.5  Time Exceeded Error Message  . . . . . . . . . . . . . . .  11
     4.6  Parameter Problem Error Message  . . . . . . . . . . . . .  12
     4.7  Neighbor Solicitation and Neighbor Advertisement
          Messages . . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.8  Router Solicitation and Router Advertisement Messages  . .  14
     4.9  Redirect Messages  . . . . . . . . . . . . . . . . . . . .  14
     4.10   Multicast Listener Discovery Messages  . . . . . . . . .  14
     4.11   Router Renumbering Messages  . . . . . . . . . . . . . .  15
     4.12   Node Information Query and Reply . . . . . . . . . . . .  15
     4.13   Mobile IPv6 Messages . . . . . . . . . . . . . . . . . .  16
     4.14   Unused and Experimental Messages . . . . . . . . . . . .  16
     4.15   Problems Resulting from ICMPv6 Transparency  . . . . . .  17
   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  17
   6.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  17
   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  17
   8.   References . . . . . . . . . . . . . . . . . . . . . . . . .  17
     8.1  Normative References . . . . . . . . . . . . . . . . . . .  17
     8.2  Informative References . . . . . . . . . . . . . . . . . .  18



Davies & Mohacsi        Expires January 12, 2006                [Page 2]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  19
        Intellectual Property and Copyright Statements . . . . . . .  20

















































Davies & Mohacsi        Expires January 12, 2006                [Page 3]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


1.  Introduction

   When a network supports IPv6 [RFC2460], the Internet Control Message
   Protocol version 6 (ICMPv6) [RFC2463], [I-D.ietf-ipngwg-icmp-v3]
   plays a fundamental role including being an essential component in
   establishing communications both at the interface level and for
   sessions to remote nodes.  This means that overly aggressive
   filtering of ICMPv6 may have a detrimental effect on the
   establishment of IPv6 communications.  On the other hand, allowing
   indiscriminate passage of all ICMPv6 messages can be a major security
   risk.  This document recommends a set of rules which seek to balance
   effective IPv6 communication against the needs of site security.
   [Author's note: The new versions of RFC2461, RFC2462 and RFC2463 have
   been taken into account in this draft, but not necessarily referenced
   as yet.]

   ICMPv6 has a large number of functions defined in a number of sub-
   protocols, and there are a correspondingly large number of messages
   and options within these messages.  The functions currently defined
   are:
   o  Returning error messages to the source if a packet could not be
      delivered.  Four different error messages are specified in
      [RFC2463].
   o  Simple monitoring of connectivity through echo requests and
      responses used by the ping and traceroute utilities.  The Echo
      Request and Echo Response messages are specified in [RFC2463].
   o  Finding neighbors (both routers and hosts) connected to the same
      link and determining their IP and link layer addresses.  These
      messages are also used to check the uniqueness of any addresses
      that an interface proposes to use (Duplicate Address Detection -
      DAD)) - DAD can be turned off if the network administrator
      believes that the configuration method used is bound to generate
      unique addresses.  Four messages - Neighbor Solicitation (NS),
      Neighbor Advertisement (NA), Router Solicitation (RS) and Router
      Advertisement (RA) - are specified in [RFC2461].
   o  Ensuring that neighbors remain reachable using the same IP and
      link layer addresses after initial discovery (Neighbor
      Unreachability Discovery - NUD) and notifying neighbors of changes
      to link layer addresses.  Uses NS and NA [RFC2461].
   o  Finding routers and determining how to obtain IP addresses to join
      the subnets supported by the routers.  Uses RS and RA [RFC2461].
   o  If stateless auto-configuration of hosts is enabled, communicating
      prefixes and other configuration information (including the link
      MTU and suggested hop count default) from routers to hosts.  Uses
      RS and RA [RFC2462].
   o  Redirecting packets to a more appropriate router on the local link
      for the destination address or pointing out that a destination is
      actually on the local link even if it is not obvious from the IP



Davies & Mohacsi        Expires January 12, 2006                [Page 4]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


      address (where a link supports multiple subnets).  This facility
      could be used by a malicious sender to divert packets and nodes
      should provide configuration options to prevent the messages being
      sent by routers and acted on by hosts.  The redirect message is
      specified in [RFC2461].
   o  Supporting renumbering of networks by allowing the prefixes
      advertised by routers to be altered.  Uses  NS, NA, RS and RA
      together with the Router Renumbering message specified in
      [RFC2894].
   o  Determining the Maximum Transmission Unit (MTU) along a path.  The
      Packet Too Big error message is essential to this function
      [RFC1981].
   o  Communicating which multicast groups have listeners on a link to
      the multicast capable routers connected to the link.  Uses
      messages Multicast Listener Query, Multicast Listener Report (two
      versions) and Multicast Listener Done (version 1 only) as
      specified in  Multicast Listener Discovery MLDv1 [RFC2710] and
      MLDv2[RFC3810].
   o  Providing support for some aspects of Mobile IPv6 especially
      dealing with the IPv6 Mobile Home Agent functionality provided in
      routers and needed to support a Mobile node homed on the link.
      The Home Agent Address Discovery Request and reply; and Mobile
      Prefix Solicitation and Advertisement messages are specified in
      [RFC3775]
   o  ICMPv6 can provide some basic information about nodes to
      interested parties [I-D.ietf-ipngwg-icmp-name-lookups].

   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
   type of addresses in ICMPv6 packets as well as the specific source
   and destination addresses.

   Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be
   treated as an auxiliary function with packets that can be dropped in
   most cases without damaging the functionality of the network.  This
   means that firewall filters for ICMPv6 have to be more carefully
   configured than was the case for ICMP, where typically a small set of
   blanket rules could be applied.

2.  Classifying ICMPv6 Messages

2.1  Error and Informational ICMPv6 Messages

   ICMPv6 messages contain an eight bit Type field interpreted as an
   integer between 0 and 255.  Messages with Type values less than or
   equal to 127 are Error Messages.  The remainder are Informational
   Messages.  In general terms, Error Messages with well-known
   (standardized) Type values would normally be expected to be allowed



Davies & Mohacsi        Expires January 12, 2006                [Page 5]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


   to be sent to or pass through firewalls, and may be essential to the
   establishment of communications (see Section 2.4 whereas
   Informational Messages will generally be the subject of policy rules,
   and those passing through firewalls can, in many but by no means all
   cases, be dropped without damaging IPv6 communications.

2.2  Addressing of ICMPv6

   ICMPv6 messages are sent using various kinds of source and
   destination address types.  The source address is usually a unicast
   address, but during address autoconfiguration message exchanges, the
   unspecified address :: is also used as a source address [RFC2462].
   The destination address can be either a well-known multicast address,
   a generated multicast address such as the solicited-node multicast
   address, an anycast address or a unicast address.  While many ICMPv6
   messages use multicast addresses most of the time, some also use
   unicast addresses sometimes.  For instance, the Router Advertisement
   messages are sent to the all-nodes multicast address when
   unsolicited, but can also be sent to a unicast address in response to
   a specific Router Solicitation.

2.3  Network Topology and Address Scopes

   ICMPv6 messages can be classified according to whether they are meant
   for end-to-end communications or communications within a link.  There
   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
   are used to announce an error in processing the original packet.  For
   instance, the address resolution messages are solely for local
   communications [RFC2461], whereas the Destination Unreachable
   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
   policies but local communications must not

   Local communications will use link-local addresses in many cases but
   may also use global unicast addresses for example when configuring
   global addresses.  Also some ICMPv6 messages in local communications
   may contravene the usual rules requiring compatible scopes for source
   and destination addresses.

2.4  Role in Establishing Communication

   Many ICMPv6 messages have a role in establishing communications to
   and from the firewall and such messages have to be accepted by
   firewalls for local delivery.  Which messages need to be accepted
   depend on whether the firewall is also acting as a router.  This type
   of communication establishment messages should not be passed through
   a firewall as they are normally intended for use within a link.



Davies & Mohacsi        Expires January 12, 2006                [Page 6]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


   On the other hand, some ICMPv6 error messages, which are sent either
   end-to-end or any-to-end. are essential to the establishment of
   communications.  For example the Packet Too Big error message is
   needed to establish the MTU along a path.  These messages must be
   passed through firewalls and might also be sent to and from firewalls
   to assist with establishment of communications.

   The remaining ICMPv6 messages which are not associated with
   communication establishment will normally be legitimately attempting
   to pass through a firewall from inside to out or vice versa, but
   decisions as to whether to allow them to pass or not can be made on
   the basis of local policy without interfering with the establishment
   of IPv6 communications.

   The filtering rules for the various message roles will generally be
   different.

3.  Security Concerns for ICMPv6 Controllable by Firewall Configuration

   A major concern with most ICMPv6 messages is that it is generally not
   possible to use IPsec or other means to authenticate the sender and
   validate the contents of some ICMPv6 messages.  To a large extent
   this is because a site can legitimately expect to receive certain
   error and other messages from almost any location in the wider
   Internet, and these messages may occur as a result of the first
   message sent to a destination.  Establishing security associations
   with all possible sources of ICMPv6 messages is therefore impossible.

   The inability to establish security associations to protect some
   messages that are needed to establish communications means that
   alternative means have to used to reduce the vulnerability of sites
   to ICMPv6 based attacks.  The most common way of doing this is to
   establish strict filtering policies in site firewalls to limit the
   unauthenticated ICMPv6 messages that can pass between the site and
   the wider Internet.  This makes control of ICMPv6 filtering a
   delicate balance between protecting the site by dropping most of the
   ICMPv6 traffic passing through the firewall and allowing enough of
   the traffic through to make sure that efficient communication can be
   established.

   Firewalls will normally be concerned to monitor ICMPv6 to control the
   following security concerns:

3.1  Denial of Service Attacks

   ICMPv6 can be used to cause a Denial of Service(DoS) in a number of
   ways, including simply sending excessive number sof ICMPv6 packets to
   destinations in the site and sending error messages which disrupt



Davies & Mohacsi        Expires January 12, 2006                [Page 7]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


   established commnuications by causing sessions to be dropped.  Also
   if spurious communication establishment messages can be passed on to
   link it might be possible to disrupt established communications.

3.2  Probing

   A major security consideration is preventing attackers probing the
   site to determine the topology and identify hosts that might be
   vulnerable to attack.  Carefully crafted but, often, malformed
   messages can be used to provoke ICMPv6 responses from hosts thereby
   informing attackers of potential targets for future attacks.

3.3  Redirection Attacks

   These attacks would normally have to be carried out locally on a
   link, but it is important to ensure that Redirect messages are not
   allowed through the firewall.  Redirection could be used simply for
   DoS as well as endeavouring to redirect traffic to a compromised
   node.

3.4  Renumbering Attacks

   Spurious Renumbering messages could lead to the disruption of a site
   and should not be allowed through a firewall in general.

4.  Filtering Recommendations

4.1  Common Considerations

   Depending on the classification of the message to be fitered (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, where deeper packet inspection is
   possible, it may be desirable to filter on, for example, the Code
   field of ICMPv6 error messages.

   Messages that are authenticated by means of an IPsec AH or ESP header
   may be subject to less strict policies than unauthenticated messages.
   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 of
   communications, local policy can be used to determine whether a
   message should be allowed or dropped.




Davies & Mohacsi        Expires January 12, 2006                [Page 8]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


   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
   travelling 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.

   Unless otherwise specified, the scopes of source and destination
   addresses of ICMPv6 messages should be matched, and packets with
   mismatched addresses should be dropped.

4.2  ICMPv6 Echo Request and Echo Response

   Echo Request (Type 128) uses unicast addresses as source addresses,
   but may be sent to any legal IPv6 address, even multicast and anycast
   addresses [RFC2463].  Echo Requests travel end-to-end but never have
   a role in establishing communications.  Similarly Echo Responses
   (Type 129) travel end-to-end and would have a unicast address as
   destination and either a unicast or anycast address as source.  They
   are used in combination for monitoring and debugging connectivity.
   o  It is desirable that Echo Requests are allowed to pass outwards
      through firewalls.
   o  Echo Requests may be allowed to pass inwards only towards selected
      hosts which are providing well-known services to the rest of the
      Internet.
   o  If possible, it is desirable to maintain state about Echo Requests
      passing through the firewall which can be used to limit the
      possible corresponding Echo Responses that may be returned.
   o  If policy requires, the possible source addresses for Echo
      Requests can be limited to certain machines, but in any case the
      source address should be an address owned by the site.
   o  If state is maintained, only one response should be allowed
      corresponding to each request.  Echo Responses should only be
      passed outwards from machines to which Echo Requests can be sent,
      and should only be passed inwards towards hosts which are allowed
      to originate Echo Requests.
   o  Both Echo Requets and Echo Responses should be rate limited in
      line with [RFC2463] and, if possible, the overall incoming rate
      from all sources destined for any given host should be limited to
      a value that the host is known to be able to handle.
   o  Messages with link local addresses in either source or destination
      should be dropped, except for messages coming from the inside
      directed to the firewall itself.



Davies & Mohacsi        Expires January 12, 2006                [Page 9]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


   o  Echo Response messages must have a unicast address as destination
      and may have a unicast, or anycast address as source.

4.3  Destination Unreachable Error Message

   Destination Unreachable (Type 1) error messages [RFC2463] are sent
   any-to-end between unicast addresses.  The message can be generated
   from any node which a packet traverses on the path when the node is
   unable to forward the packet for any reason except congestion.
   o  Incoming ICMPv6 Destination Unreachable messages may be passed
      through the firewall for debugging purposes where they relate to
      outgoing IPv6 packets that have previously been sent out through
      the firewall.  For preference, this should be implemented by means
      of a stateful packet inspection mechanism.  These messages should
      not be sent if the outgoing message was sent to a multicast
      address:  if possible any error message that is returned from a
      multicast address should be discarded.
   o  Outgoing ICMPv6 Destination Unreachable messages may be generated
      and passed out for all packets that have been allowed through the
      firewall.
   o  At most one Destination Unreachable message should be passed
      through the firewall in response to each packet that might result
      in an error if the firewall is able to manage this.

   Destination Unreachable messages are useful for debugging but are
   also important to speed up cycling through possible addresses, as
   they can avoid the need to wait through timeouts and hence can be
   part of the process of establishing communications.  It is a common
   practice in IPv4, to refrain from generating ICMP Destination
   Unreachable messages to attempt to hide the networking topology
   and/or service structure.  The same rule can be applied to IPv6 but
   this can slow down connection if a host has multiple addresses some
   of which are deprecated as when using privacy addresses [RFC3041].
   If policy allows the generation of ICMPv6 Destination Unreachable
   messages, it is important to provide the correct reason code, one of:
   no route to destination, administratively prohibited, beyond scope of
   source address, address unreachable, port unreachable, source address
   failed ingress/egress policy, reject route to destination.

4.4  Packet Too Big Error Message

   Packet Too Big (Type 2) error messages [RFC2463] are sent any-to-end
   between unicast addresses.  The message can be generated from any
   node which a packet traverses on the path when the node is unable to
   forward the packet because the packet is too large for the MTU of the
   next link.  This message is vital to the correct functioning of Path
   MTU Discovery and hence is part of the establishment of
   communications.  Since routers are not allowed to fragment packets,



Davies & Mohacsi        Expires January 12, 2006               [Page 10]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


   informing sources of the need to fragment large packets is more
   important than for IPv4.  If these messages are not generated when
   appropriate, hosts will continue to send packets which are too large
   or may assume that the route is congested.  Effectively parts of the
   Internet will become inaccessible.
   o  It is essential to allow incoming ICMPv6 Packet Too Big messages
      as responses to outgoing IPv6 packets so that Path MTU Discovery
      will operate properly.
   o  If possible, stateful packet inspection should be used to limit
      incoming Packet Too Big messages to legitimate responses to
      outgoing packets and to limit error messages to at most one per
      outgoing packet.  Note that this message can be geenrated as a
      result of messages sent to multicast addresses.
   o  It is essential to allow outgoing ICMPv6 Packet Too Big messages
      to be generated and passed through the firewall if the MTU is
      smaller on any link anywhere within the network protected by the
      firewall than the MTU on the link between the firewall and the ISP
      which connects the site to the rest of the Internet.  In transit
      networks, it will be necessary to pass Packet Too Big messages
      through the network.

   If a network chooses to generate packets that are no larger than the
   Guaranteed Minimum MTU (1280 octets) and the site's links to the
   wider internet have corresponding MTUs, Packet Too Big messages
   should not be expected at the firewall and can be dropped if they
   arrive.

4.5  Time Exceeded Error Message

   Time Exceeded (Type 3) error messages [RFC2463] can occur in two
   contexts:
   o  Code 0 are generated at any node on the path being taken by the
      packet and sent any-to-end between unicast addresses if the Hop
      Limit value is decremented to zero at any point on the path.
   o  Code 1 messages are generated at the destination node and sent
      end-to-end between unicast addresses if all the segments of a
      fragmented message are not received within the reassembly time
      limit

   Code 0 messages can be needed as part of the establishment of
   communications if the path to a particular destination requires an
   unusually large number of hops.  It is therefore essential to
   generate and forward Code 0 Time Exceeded messages for effective
   operation of IPv6 networks.

   Code 1 messages will generally only result from congestion in the
   network and it is less essential to propagate these messages.




Davies & Mohacsi        Expires January 12, 2006               [Page 11]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


   o  It is essential to allow incoming ICMPv6 Time Exceeded Code 0
      messages to be able discover destination systems not reachable due
      to a low Hop Limit value in the outgoing packets, so that the Hop
      Limit can be selectively increased for these packets.
   o  Incoming ICMPv6 Time Exceeded Code 1 messages may be enabled by
      policy if desired.
   o  If possible, stateful packet inspection should be used to limit
      incoming Time Exceeded messages to legitimate responses to
      outgoing packets and to limit error messages to at most one per
      outgoing packet.
   o  It is essential to generate and allow outgoing ICMPv6 Time
      Exceeded Code 0 messages to ensure that communications can be
      established to sites which generate packets with small hop limits
      or are traversing very long paths.
   o  Generation of outgoing ICMPv6 Time Exceeded Code 1 messages and
      allowing them through the firewall may be enabled by policy if
      desired.

4.6  Parameter Problem Error Message

   The great majority of Parameter Problem (Type 4) error messages will
   be generated by the destination node when processing destination
   options and other extension headers, and hence are sent end-to-end
   between unicast addresses.  Exceptionally, these messages might be
   generated by any node on the path if a faulty or unrecognized hop-by-
   hop option is included or from any routing waypoint if there are
   faulty or unrecognized destination options associated with a Type 0
   routing header.  In these cases the message will be sent any-to-end
   using unicast source and destination addresses.

   Parameter Problem Code 1 (Unrecognized Next Header) and Code 2
   (Unrecognized IPv6 Option) messages may result if a node on the path
   (usually the destination) is unable to process a correctly formed
   extension header or option.  If these messages are not returned to
   the source communication cannot be established, as the source would
   need to adapt its choice of options probably because the destination
   does not implement these capabilities.  Hence these messages need to
   be generated and allowed for effective IPv6 communications.

   Code 0 (Erroneous Header) messages indicate a malformed extension
   header generally as a result of incorrectly generated packets.  Hence
   these messages are useful for debugging purposes but it is unlikely
   that a node generating such packets could establish communications
   without human intervention to correct the problem.

   Code 2 messages, only, can be generated for packets with multicast
   destinatio addresses.




Davies & Mohacsi        Expires January 12, 2006               [Page 12]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


   o  It is essential that incoming ICMPv6 Parameter Problem messages
      with Code 1 or Code 2 are allowed as responses to outgoing IPv6
      packets to allow establishment of communications to sites which do
      not support unusual options.
   o  Incoming ICMPv6 Parameter Problem messages with Code 1 may be
      allowed by policy if desired.
   o  If possible, stateful packet inspection should be used to limit
      incoming Parameter Problem messages to legitimate responses to
      outgoing packets and to limit error messages to at most one per
      outgoing packet.
   o  It is essential to generate and allow outgoing ICMPv6 Parameter
      Problem Code 1 and Code 2 messages to ensure that communications
      can be established if it is known that nodes are not able to
      support certain options or extension headers.  Some risks
      associated with blanket generation  and forwarding of responses of
      this type are discussed at the end of this section.
   o  Generation of outgoing ICMPv6 Parameter Problem Code 0 messages
      and allowing them through the firewall may be enabled by policy if
      desired.

   It is possible that attackers may seek to probe or scan a network by
   deliberately generating packets with unknown extension headers or
   options, or faulty headers.  If nodes generate Parameter Problem
   error messages in all cases and these outgoing messages are allowed
   through firewalls, the attacker may be able to identify active
   addresses that can be probed further or learn about the network
   topology.  The vulnerability could be mitigated whilst helping to
   establish communications if the firewall was able to examine such
   error messages in depth and was configured to only allow Parameter
   Problem messages for headers which had been standardized but were not
   supported in the protected network.  If the network administrator
   believes that all nodes in the network support all legitimate
   extension headers then it would be reasonable to drop all outgoing
   Parameter Problem messages.

4.7  Neighbor Solicitation and Neighbor Advertisement Messages

   ICMPv6 Neighbor Solicitation and Neighbor Advertisement (Type 135 and
   136) messages are essential to establishment of communications on the
   local link.  Firewalls need to generate and accept these messages to
   allow them to establish interfaces onto their connected links.
   o  Firewalls must accept and generate ICMPv6 neighbor Solicitation
      and Neighbor Advertisement messages for local delivery on all
      interfaces as described in [RFC2461] and [RFC2462].
   o  Firewalls must not allow any Neighbor Solicitation or Neighbor
      Advertisement messages to pass through the firewall, either
      incoming or outgoing.




Davies & Mohacsi        Expires January 12, 2006               [Page 13]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


   Note that the address scopes of the source and destination addresses
   on Neighbor Solicitations and Neighbor Advertisements may not match.
   The exact functions which these messages will be carrying out depends
   on the mechanism being used to configure IPv6 addresses on the link
   (Stateless, Stateful or Static configuration).

4.8  Router Solicitation and Router Advertisement Messages

   ICMPv6 Router Solicitation and Router Advertisement(Type 133 and 134)
   messages are essential to establishment of communications on the
   local link.  Firewalls need to generate (since the firewall will
   generally be behaving as a router) and accept these messages to allow
   them to establish interfaces onto their connected links.
   o  Firewalls must accept and generate ICMPv6 Router Solicitation and
      Router Advertisement messages for local delivery on all interfaces
      as described in [RFC2461] and [RFC2462].
   o  Firewalls must not allow any Router Solicitation or Router
      Advertisement messages to pass through the firewall, either
      incoming or outgoing.

4.9  Redirect Messages

   ICMPv6 Redirect Messages(Type 137) are used on the local link to
   indicate that nodes are actually link-local and communications need
   not go via a router, or to indicate a more appropriate first hop
   router.  Although they can be used to make communications more
   efficient, they are not essential to the establishment of
   communications and may be a security vulnerability.
   o  Firewalls should generally implement a policy of not generating or
      accepting ICMPv6 Redirect messages for local delivery on any
      interface.
   o  Firewalls must not allow ICMPv6 Redirect messages to pass through
      the firewall, either incoming or outgoing.

4.10  Multicast Listener Discovery Messages

   Multicast Listener Discovery (MLD) version 1 [RFC2710] (Listener
   Query, Listener Report and Listener Done - Types 130, 131 and 132)
   and version 2 [RFC3810] (Listener Query and Listener Report Version 2
   - Types 130 and 143) messages are sent on the local link to
   communicate between multicast capable routers and nodes which wish to
   join or leave specific multicast groups.
   o  Firewalls must be able to generate ICMPv6 Listener Report messages
      on their interfaces for Solicited Node Multicast Groups as part of
      the address configuration process.  They may also have to generate
      ICMPv6 Listener Report version 2 messages and Listener Done
      messages for the same reason [Author's Note: The current versions
      of the standards are not specific about this.].



Davies & Mohacsi        Expires January 12, 2006               [Page 14]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


   o  Firewalls which are also acting as multicast routers need to be
      able to receive both types of  ICMPv6 Listener Report and Listener
      Done messages, and generate ICMPv6 Listener Query messages on
      relevant interfaces.
   o  Firewalls must not allow any of the MLD messages to pass throigh
      the firewall, wither incoming or outgoing.

4.11  Router Renumbering Messages

   ICMPv6 Router Renumbering (Type 138) command messages can be received
   and results messages sent by routers to change the prefixes which
   they advertise as part of Stateless Address Configuration [RFC2461],
   [RFC2462].  These messages are sent end-to-end to either the all-
   routers multicast address (site or local scope) or specific unicast
   addresses from a unicast address.

   Router Renumbering messages are required to be protected by IPsec
   authentication since they could be readily misused by attackers to
   disrupt or divert site communications.  Renumbering messages should
   be confined to sites for this reason.
   o  Firewalls which are acting as routers on sites which implement
      router renumbering functionality must accept for local delivery
      and generate appropriate ICMPv6 Router Renumbering messages on
      inward facing interfaces.  Such messages must be protected by
      IPsec authentication as described in [RFC2894].
   o  Firewalls must not accept ICMPv6 Router Renumbering messages on
      outward facing interfaces.
   o  Firewalls must not allow any Router Renumbering messages to pass
      through the firewall, either incoming or outgoing.

4.12  Node Information Query and Reply

   ICMPv6 Node Information Query and Reply (Type 139 and 140) messages
   are sent end-to-end between unicast addresses.  They can, in theory,
   be sent from any node to any other but it would generally not be
   desirable for nodes outside the local site to be able to send queries
   to nodes within the site.  Also these messages are not required to be
   authenticated.
   o  Firewall policy may allow ICMPv6 Node Information Query messages
      to be accepted for local delivery on inward facing interfaces and
      allow generation of corresponding Node Information reply messages
      on these interfaces.
   o  Firewalls must not accept or generate ICMPv6 Node Information
      messages on outward facing interfaces.
   o  Firewalls must not allow any ICMPv6 Node Information messages to
      pass through the firewall, either incoming or outgoing.





Davies & Mohacsi        Expires January 12, 2006               [Page 15]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


4.13  Mobile IPv6 Messages

   Mobile IPv6 [RFC3775] defines four ICMPv6 messages which are used to
   support mobile operations: Home Agent Address Discovery Request, Home
   Agent Address Discovery Reply, Mobile Prefix Solicitation and ICMP
   Mobile Prefix Advertisement(Type 144, 145, 146 and 147) messages.
   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
   from outside a site.  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
      must allow incoming Home Agent Address Discovery Request and
      Mobile Prefix Solicitation messages., and outgoing Home Agent
      Address Discovery Reply and ICMP Mobile Prefix Advertisement
      messages.  It may be desirable to limit the destination addresses
      for the incoming messages to links that are known to support home
      agents.
   o  If the site is prepared to host roaming mobile nodes, the firewall
      must allow outgoing Home Agent Address Discovery Request and
      Mobile Prefix Solicitation messages., and incoming Home Agent
      Address Discovery Reply and ICMP Mobile Prefix Advertisement
      messages.  Administrators may find it desirable to prevent fixed
      nodes which are normally resident on the site from behaving as
      mobile nodes by dropping outgoing messages from these nodes.
   o  If possible, stateful packet inspection should be used to match
      incoming and outgoing messages.

4.14  Unused and Experimental Messages

   A large number of ICMPv6 Type values are currently unused.  These
   values have not had a specific function registered with IANA.  This
   section describes how to treat messages which attempt to use these
   Type values in a way of which the network administrator (and hence
   the firewall) is not aware.

   [I-D.ietf-ipngwg-icmp-v3] defines a number of experimental Type
   values for ICMPv6 Error and Informational messages, which could be
   used in site specific ways.  These values should be treated in the
   same way as values which are not registered by IANA unless the
   network administrator is explicitly made aware of usage.

   Any ICMPv6 Informational messages of which the firewall is not aware
   should not be allowed to pass through the firewall or be accepted for
   local delivery on any of its interfaces.

   Any incoming ICMPv6 Error messages of which the firewall is not aware
   may be allowed through the firewall in line with the specification in
   [RFC2463], which requests delivery of unknown error messages to



Davies & Mohacsi        Expires January 12, 2006               [Page 16]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


   higher layer protocol processes.  However, administrators may wish to
   disallow forwarding of these incoming messages as a potential
   security risk.  Unknown outgoing Error messages must be dropped as
   the administrator should be aware of all messages that could be
   generated on the site.

4.15  Problems Resulting from ICMPv6 Transparency

   Because some ICMPv6 error packets need to be passed through a
   firewall in both directions.  This means that the ICMPv6 error
   packets can be exchanged between inside and outside without any
   filtering.

   Using this feature, malicious users can communicate between the
   inside and outside of a firewall bypassing the administrator's
   inspection (proxy, firewall etc.).  For example in might be possible
   to carry out a covert conversation through the payload of ICMPv6
   error messages or tunnel inappropriate encapsulated IP packets in
   ICMPv6 error messages.  This problem can be alleviated by filtering
   ICMPv6 errors using a stateful packet inspection mechanism to ensure
   that the packet carried as a payload is associated with legitimate
   traffic to or from the protected network.

5.  IANA Considerations

   There are no IANA considerations defined in this document.

6.  Acknowledgements

   Pekka Savola created the original IPv6 Security Overview document
   which contained suggestions for ICMPv6 filter setups.  This
   information has been incorporated into this document.  Some analysis
   of the classification of ICMPv6 messages and the term 'any-to-end'
   were used by Jari Arkko in a draft relating to ICMPv6 and IKE.

7.  Security Considerations

   This memo recommends filtering configurations for firewalls designed
   to minimize the security vulnerabilities that can arise in using the
   many different sub-protocols of ICMPv6 in support of IPv6
   communication.

8.  References

8.1  Normative References

   [I-D.ietf-ipngwg-icmp-name-lookups]
              Crawford, M. and B. Haberman, "IPv6 Node Information



Davies & Mohacsi        Expires January 12, 2006               [Page 17]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


              Queries", draft-ietf-ipngwg-icmp-name-lookups-11 (work in
              progress), May 2005.

   [I-D.ietf-ipngwg-icmp-v3]
              Conta, A., "Internet Control Message Protocol (ICMPv6)for
              the Internet Protocol Version  6 (IPv6) Specification",
              draft-ietf-ipngwg-icmp-v3-06 (work in progress),
              November 2004.

   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
              for IP version 6", RFC 1981, August 1996.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC2463]  Conta, A. and S. Deering, "Internet Control Message
              Protocol (ICMPv6) for the Internet Protocol Version 6
              (IPv6) Specification", RFC 2463, December 1998.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999.

   [RFC2894]  Crawford, M., "Router Renumbering for IPv6", RFC 2894,
              August 2000.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

8.2  Informative References

   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
              Stateless Address Autoconfiguration in IPv6", RFC 3041,
              January 2001.







Davies & Mohacsi        Expires January 12, 2006               [Page 18]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


Authors' Addresses

   Elwyn B. Davies
   Consultant
   Soham, Cambs
   UK

   Phone: +44 7889 488 335
   Email: elwynd@dial.pipex.com


   Janos Mohacsi
   NIIF/HUNGARNET
   Victor Hugo u. 18-22
   Budapest,   H-1132
   Hungary

   Phone: +36 1 4503070
   Email: mohacsi@niif.hu
































Davies & Mohacsi        Expires January 12, 2006               [Page 19]


Internet-Draft            ICMPv6 Filtering BCP                 July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Davies & Mohacsi        Expires January 12, 2006               [Page 20]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/