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

Versions: 00 draft-ietf-opsec-icmp-filtering

Operational Security Capabilities                                F. Gont
for IP Network Infrastructure                                    G. Gont
(opsec)                                                          UTN/FRH
Internet-Draft                                            March 30, 2008
Intended status: Informational
Expires: October 1, 2008


              Recommendations for filtering ICMP messages
                 draft-gont-opsec-icmp-filtering-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 October 1, 2008.

Abstract

   This document document provides advice on the filtering of ICMPv4 and
   ICMPv6 messages.  Additionaly, it discusses the operational and
   interoperability implications of such filtering.










Gont & Gont              Expires October 1, 2008                [Page 1]


Internet-Draft               ICMP Filtering                   March 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Internet Control Message Protocol version 4 (ICMP) . . . . . .  5
     2.1.  ICMPv4 error messages  . . . . . . . . . . . . . . . . . .  5
       2.1.1.  Destination Unreachable (Type 3) . . . . . . . . . . .  6
         2.1.1.1.  Net Unreachable (code 0) . . . . . . . . . . . . .  6
         2.1.1.2.  Host Unreachable (code 1)  . . . . . . . . . . . .  7
         2.1.1.3.  Protocol Unreachable (code 2)  . . . . . . . . . .  7
         2.1.1.4.  Port Unreachable (code 3)  . . . . . . . . . . . .  8
         2.1.1.5.  Fragmentation needed and DF set (code 4) . . . . .  8
         2.1.1.6.  Source Route Failed (code 5) . . . . . . . . . . .  9
         2.1.1.7.  Destination network unknown (code 6)
                   (Deprecated) . . . . . . . . . . . . . . . . . . .  9
         2.1.1.8.  Destination host unknown (code 7)  . . . . . . . . 10
         2.1.1.9.  Source host isolated (code 8) (Deprecated) . . . . 11
         2.1.1.10. Communication with destination network
                   administratively prohibited (code 9) -
                   Deprecated . . . . . . . . . . . . . . . . . . . . 11
         2.1.1.11. Communication with destination host
                   administratively prohibited (code 10) -
                   Deprecated . . . . . . . . . . . . . . . . . . . . 12
         2.1.1.12. Network unreachable for type of service (code
                   11)  . . . . . . . . . . . . . . . . . . . . . . . 12
         2.1.1.13. Host unreachable for type of service (code 12) . . 13
         2.1.1.14. Communication Administratively Prohibited
                   (code 13)  . . . . . . . . . . . . . . . . . . . . 13
         2.1.1.15. Host Precedence Violation (code 14)  . . . . . . . 14
         2.1.1.16. Precedence cutoff in effect (code 15)  . . . . . . 14
       2.1.2.  Source Quench (Type 4, Code 0) . . . . . . . . . . . . 15
         2.1.2.1.  Message specification  . . . . . . . . . . . . . . 15
         2.1.2.2.  Uses . . . . . . . . . . . . . . . . . . . . . . . 15
         2.1.2.3.  Threats  . . . . . . . . . . . . . . . . . . . . . 16
         2.1.2.4.  Operational/interoperability impact if blocked . . 16
       2.1.3.  Redirect (Type 5)  . . . . . . . . . . . . . . . . . . 16
         2.1.3.1.  Redirect datagrams for the Network (code 0)  . . . 16
         2.1.3.2.  Redirect datagrams for the Host (code 1) . . . . . 16
         2.1.3.3.  Redirect datagrams for the Type of Service and
                   Network (code 2) . . . . . . . . . . . . . . . . . 17
         2.1.3.4.  Redirect datagrams for the Type of Service and
                   Host (code 3)  . . . . . . . . . . . . . . . . . . 17
       2.1.4.  Time exceeded (Type 11)  . . . . . . . . . . . . . . . 17
         2.1.4.1.  Time to live exceeded in transit (code 0)  . . . . 17
         2.1.4.2.  fragment reassembly time exceeded (code 1) . . . . 18
       2.1.5.  Parameter Problem (Type 12)  . . . . . . . . . . . . . 18
         2.1.5.1.  Pointer indicates the error (code 0) . . . . . . . 19
         2.1.5.2.  Required option is missing (code 1)  . . . . . . . 19
     2.2.  ICMPv4 Informational messages  . . . . . . . . . . . . . . 19



Gont & Gont              Expires October 1, 2008                [Page 2]


Internet-Draft               ICMP Filtering                   March 2008


       2.2.1.  Echo or Echo Reply Message . . . . . . . . . . . . . . 19
         2.2.1.1.  Echo message (type 8, code 0)  . . . . . . . . . . 19
         2.2.1.2.  Echo reply message (Type 0, code 0)  . . . . . . . 20
       2.2.2.  Router Solicitation or Router Advertisement message  . 21
         2.2.2.1.  Router Solicitation message (type 10, code 0)  . . 21
         2.2.2.2.  Router Advertisement message (type 9, code 0)  . . 22
       2.2.3.  Timestamp or Timestamp Reply Message . . . . . . . . . 22
         2.2.3.1.  Timestamp message (type 13, code 0)  . . . . . . . 22
         2.2.3.2.  Timestamp reply message (type 14, code 0)  . . . . 23
       2.2.4.  Information Request or Information Reply Message
               (Deprecated) . . . . . . . . . . . . . . . . . . . . . 23
         2.2.4.1.  Information request message (type 15, code 0)  . . 23
         2.2.4.2.  Information reply message (type 16, code 0)  . . . 24
       2.2.5.  Address Mask Request or Address Mask Reply . . . . . . 24
         2.2.5.1.  Address Mask Request (type 17, code 0) . . . . . . 24
         2.2.5.2.  Address Mask Reply (type 18, code 0) . . . . . . . 25
   3.  Internet Control Message Protocol version 6 (ICMPv6) . . . . . 25
     3.1.  ICMPv6 error messages  . . . . . . . . . . . . . . . . . . 25
       3.1.1.  Destination Unreachable (Type 1) . . . . . . . . . . . 25
         3.1.1.1.  No route to destination (code 0) . . . . . . . . . 25
         3.1.1.2.  Communication with destination
                   administratively prohibited (code 1) . . . . . . . 26
         3.1.1.3.  Beyond scope of source address (code 2)  . . . . . 26
         3.1.1.4.  Address unreachable (code 3) . . . . . . . . . . . 27
         3.1.1.5.  Port unreachable (code 4)  . . . . . . . . . . . . 27
         3.1.1.6.  Source address failed ingress/egress policy
                   (code 5) . . . . . . . . . . . . . . . . . . . . . 27
         3.1.1.7.  Reject route to destination (code 6) . . . . . . . 28
       3.1.2.  Packet Too Big Message (Type 2, code 0)  . . . . . . . 28
         3.1.2.1.  Message specification  . . . . . . . . . . . . . . 28
         3.1.2.2.  Uses . . . . . . . . . . . . . . . . . . . . . . . 28
         3.1.2.3.  Threats  . . . . . . . . . . . . . . . . . . . . . 28
         3.1.2.4.  Operational/interoperability impact if blocked . . 28
       3.1.3.  Time Exceeded Message (Type 3) . . . . . . . . . . . . 29
         3.1.3.1.  Hop limit exceeded in transit (code 0) . . . . . . 29
         3.1.3.2.  Fragment reassembly time exceeded (code 1) . . . . 29
       3.1.4.  Parameter Problem Message (Type 4) . . . . . . . . . . 29
         3.1.4.1.  Erroneous header field encountered (code 0)  . . . 29
         3.1.4.2.  Unrecognized Next Header type encountered
                   (code 1) . . . . . . . . . . . . . . . . . . . . . 30
         3.1.4.3.  Unrecognized IPv6 option encountered (code 2)  . . 30
       3.1.5.  Private experimentation (Type 100) . . . . . . . . . . 30
         3.1.5.1.  Message specification  . . . . . . . . . . . . . . 30
         3.1.5.2.  Uses . . . . . . . . . . . . . . . . . . . . . . . 31
         3.1.5.3.  Threats  . . . . . . . . . . . . . . . . . . . . . 31
         3.1.5.4.  Operational/interoperability impact if blocked . . 31
       3.1.6.  Private experimentation (Type 101) . . . . . . . . . . 31
         3.1.6.1.  Message specification  . . . . . . . . . . . . . . 31



Gont & Gont              Expires October 1, 2008                [Page 3]


Internet-Draft               ICMP Filtering                   March 2008


         3.1.6.2.  Uses . . . . . . . . . . . . . . . . . . . . . . . 31
         3.1.6.3.  Threats  . . . . . . . . . . . . . . . . . . . . . 31
         3.1.6.4.  Operational/interoperability impact if blocked . . 31
       3.1.7.  Reserved for expansion of ICMPv6 error messages
               (Type 127) . . . . . . . . . . . . . . . . . . . . . . 31
         3.1.7.1.  Message specification  . . . . . . . . . . . . . . 31
         3.1.7.2.  Uses . . . . . . . . . . . . . . . . . . . . . . . 31
         3.1.7.3.  Threats  . . . . . . . . . . . . . . . . . . . . . 31
         3.1.7.4.  Operational/interoperability impact if blocked . . 31
     3.2.  ICMPv6 Informational messages  . . . . . . . . . . . . . . 31
       3.2.1.  Echo Request or Echo Reply Message . . . . . . . . . . 31
         3.2.1.1.  Echo Request message (type 128, code 0)  . . . . . 31
         3.2.1.2.  Echo reply message (Type 129, code 0)  . . . . . . 32
       3.2.2.  Private experimentation (Type 200) . . . . . . . . . . 32
         3.2.2.1.  Message specification  . . . . . . . . . . . . . . 32
         3.2.2.2.  Uses . . . . . . . . . . . . . . . . . . . . . . . 32
         3.2.2.3.  Threats  . . . . . . . . . . . . . . . . . . . . . 32
         3.2.2.4.  Operational/interoperability impact if blocked . . 32
       3.2.3.  Private experimentation (Type 201) . . . . . . . . . . 32
         3.2.3.1.  Message specification  . . . . . . . . . . . . . . 32
         3.2.3.2.  Uses . . . . . . . . . . . . . . . . . . . . . . . 32
         3.2.3.3.  Threats  . . . . . . . . . . . . . . . . . . . . . 33
         3.2.3.4.  Operational/interoperability impact if blocked . . 33
       3.2.4.  Reserved for expansion of ICMPv6 informational
               messages (Type 255)  . . . . . . . . . . . . . . . . . 33
         3.2.4.1.  Message specification  . . . . . . . . . . . . . . 33
         3.2.4.2.  Uses . . . . . . . . . . . . . . . . . . . . . . . 33
         3.2.4.3.  Threats  . . . . . . . . . . . . . . . . . . . . . 33
         3.2.4.4.  Operational/interoperability impact if blocked . . 33
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 33
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 34
   Appendix A.  Change log (to be removed before publication of
                the document as an RFC) . . . . . . . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
   Intellectual Property and Copyright Statements . . . . . . . . . . 36













Gont & Gont              Expires October 1, 2008                [Page 4]


Internet-Draft               ICMP Filtering                   March 2008


1.  Introduction

   This document document provides advice on the filtering of ICMPv4 and
   ICMPv6 messages.  Additionaly, it discusses the operational and
   interoperability implications of such filtering.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Internet Control Message Protocol version 4 (ICMP)

2.1.  ICMPv4 error messages

   [RFC0792] is the base specification for the Internet Control Message
   Protocol (ICMP) to be used with the Internet Protocol version 4
   (IPv4).  It defines, among other things, a number of error messages
   that can be used by end-systems and intermediate systems to report
   errors to the sending system.  The Host Requirements RFC [RFC1122]
   classifies ICMP error messages into those that indicate "soft
   errors", and those that indicate "hard errors", thus roughly defining
   the semantics of them.

   Section 3.2.2.1 of [RFC1122] specifies the amount of information to
   be included in the payload of an ICMP error message, and how ICMP
   error messages should be demultiplexed to the corresponding transport
   protocol instance.  Additionally, it imposes details some scenarios
   in which ICMP errors should not be generated.

   Section 4.1.3.3 of [RFC1122] states that UDP MUST pass to the
   application layer all ICMP error messages that it receives from the
   IP layer.

   Section 4.2.3.9 of [RFC1122] states that TCP MUST act on an ICMP
   error message passed up from the IP layer, directing it to the
   connection that created the error.

   Section 4.3.2 of [RFC1812] contains a number of requirements for the
   generation and processing of ICMP error messages, including:
   initialization of the TTL of the error message, the amount of data
   from the offending packet to be included in the ICMP payload, setting
   the IP Source Address of ICMP error messages, setting of the TOS and
   Precedence, processing of IP Source Route option in offending
   packets, scenarios in which routers MUST NOT send ICMP error
   messages, and application of rate-limiting to ICMP error messages.

   The ICMP specification [RFC0792] also defines the ICMP Source Quench



Gont & Gont              Expires October 1, 2008                [Page 5]


Internet-Draft               ICMP Filtering                   March 2008


   message (type 4, code 0), which is meant to provide a mechanism for
   flow control and congestion control.

   [RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD),
   which makes use of ICMP error messages of type 3 (Destination
   Unreachable), code 4 (fragmentation needed and DF bit set) to allow
   systems to determine the MTU of an arbitrary internet path.

   Appendix D of [RFC4301] provides information about which ICMP error
   messages are produced by hosts, intermediate routers, or both.

2.1.1.  Destination Unreachable (Type 3)

   The ICMP Destination Unreachable message is sent by a router in
   response to a packet which it cannot forward because the destination
   (or next hop) is unreachable or a service is unavailable.  Examples
   of such cases include a message addressed to a host which is not
   there and therefore does not respond to ARP requests, and messages
   addressed to network prefixes for which the router has no valid
   route.  [RFC1812] states that a router MUST be able to generate ICMP
   Destination Unreachable messages and SHOULD choose a response code
   that most closely matches the reason the message is being generated.
   Section 3.2.2.1 of [RFC1122] states that a Destination Unreachable
   message that is received MUST be reported to the transport layer, and
   that the transport layer SHOULD use the information appropriately.

2.1.1.1.  Net Unreachable (code 0)

2.1.1.1.1.  Message specification

   Defined in [RFC0792].  Section 4.3.3.1 of [RFC1812] states that if a
   router cannot forward a packet because it has no routes at all
   (including no default route) to the destination specified in the
   packet, then the router MUST generate a Destination Unreachable, Code
   0 (Network Unreachable) ICMP message.  Section 3.2.2.1 of [RFC1122]
   states that this message may result from a routing transient, and
   MUST therefore be interpreted as only a hint, not proof, that the
   specified destination is unreachable.  For example, it MUST NOT be
   used as proof of a dead gateway.  Section 4.2.3.9 of [RFC1122] states
   that this message indicates a soft error, and therefore TCP MUST NOT
   abort the connection, and SHOULD make the information available to
   the application.

2.1.1.1.2.  Uses







Gont & Gont              Expires October 1, 2008                [Page 6]


Internet-Draft               ICMP Filtering                   March 2008


2.1.1.1.3.  Threats

2.1.1.1.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts
   that could have been avoided by those systems aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

2.1.1.2.  Host Unreachable (code 1)

2.1.1.2.1.  Message specification

   Defined in [RFC0792].  Section 3.2.2.1 of [RFC1122] states that his
   message may result from a routing transient, and MUST therefore be
   interpreted as only a hint, not proof, that the specified destination
   is unreachable.  For example, it MUST NOT be used as proof of a dead
   gateway.  Section 4.2.3.9 of [RFC1122] states that this message
   indicates a soft error, and therefore TCP MUST NOT abort the
   connection, and SHOULD make the information available to the
   application.

2.1.1.2.2.  Uses

2.1.1.2.3.  Threats

2.1.1.2.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts
   that could have been avoided by those systems aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

2.1.1.3.  Protocol Unreachable (code 2)

2.1.1.3.1.  Message specification

   Defined in [RFC0792].  [RFC1122] states that a host SHOULD send a
   protocol unreachable when the designated transport protocol is not
   supported.  Section 4.2.3.9 of [RFC1122] states that this message
   indicates a hard error condition, so TCP SHOULD abort the connection.

2.1.1.3.2.  Uses








Gont & Gont              Expires October 1, 2008                [Page 7]


Internet-Draft               ICMP Filtering                   March 2008


2.1.1.3.3.  Threats

2.1.1.3.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts
   that could have been avoided by those systems aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

2.1.1.4.  Port Unreachable (code 3)

2.1.1.4.1.  Message specification

   Defined in [RFC0792].  Section 3.2.2.1 of [RFC1122] states that a
   host SHOULD send an ICMP port unreachable when the designated
   transport protocol (e.g., UDP) is unable to demultiplex the datagram
   but has no protocol mechanism to inform the sender.  Additionally, it
   states that a transport protocol that has its own mechanism for
   notifying the sender that a port is unreachable MUST nevertheless
   accept an ICMP Port Unreachable for the same purpose.

   Section 4.2.3.9 of [RFC1122] states that this message indicates a
   hard error condition, so TCP SHOULD abort the connection.

2.1.1.4.2.  Uses

2.1.1.4.3.  Threats

2.1.1.4.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

2.1.1.5.  Fragmentation needed and DF set (code 4)

2.1.1.5.1.  Message specification

   Defined in [RFC0792]

2.1.1.5.2.  Uses

   Used for the Path-MTU Discovery mechanism described in [RFC1191].







Gont & Gont              Expires October 1, 2008                [Page 8]


Internet-Draft               ICMP Filtering                   March 2008


2.1.1.5.3.  Threats

   This error message can be used to perform Denial of Service (DoS)
   attacks against transport protocols.  [I-D.ietf-tcpm-icmp-attacks]
   describes the use of this error message to attack TCP connections.

2.1.1.5.4.  Operational/interoperability impact if blocked

   Filtering this error message breaks the Path-MTU Discovery mechansim
   described in [RFC1191].

2.1.1.6.  Source Route Failed (code 5)

2.1.1.6.1.  Message specification

   Defined in [RFC0792].  Section 3.2.2.1 of [RFC1122] states that his
   message may result from a routing transient, and MUST therefore be
   interpreted as only a hint, not proof, that the specified destination
   is unreachable.  For example, it MUST NOT be used as proof of a dead
   gateway.  Section 4.2.3.9 of [RFC1122] states that this message
   indicates a soft error, and therefore TCP MUST NOT abort the
   connection, and SHOULD make the information available to the
   application.

   Section 4.2.3.9 of [RFC1122] states that this message indicates a
   hard error condition, so TCP SHOULD abort the connection.

2.1.1.6.2.  Uses

   Signals errors araising from IPv4 source routes.

2.1.1.6.3.  Threats

   There shouldn't be any security threats araising from the use of this
   error message.

2.1.1.6.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

2.1.1.7.  Destination network unknown (code 6) (Deprecated)







Gont & Gont              Expires October 1, 2008                [Page 9]


Internet-Draft               ICMP Filtering                   March 2008


2.1.1.7.1.  Message specification

   Defined in [RFC1122].  [RFC1812] states that this code SHOULD NOT be
   generated since it would imply on the part of the router that the
   destination network does not exist (net unreachable code 0 SHOULD be
   used in place of code 6).

2.1.1.7.2.  Uses

   Signal unreachability condition to the sending system.

2.1.1.7.3.  Threats

   There shouldn't be any security threats araising from the use of this
   error message.

2.1.1.7.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

2.1.1.8.  Destination host unknown (code 7)

2.1.1.8.1.  Message specification

   Defined in [RFC1122], and is generated only when a router can
   determine (from link layer advice) that the destination host does not
   exist

2.1.1.8.2.  Uses

   Signal unreachability condition to the sending system.

2.1.1.8.3.  Threats

   There shouldn't be any security threats araising from the use of this
   error message.

2.1.1.8.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].





Gont & Gont              Expires October 1, 2008               [Page 10]


Internet-Draft               ICMP Filtering                   March 2008


2.1.1.9.  Source host isolated (code 8) (Deprecated)

2.1.1.9.1.  Message specification

   Defined in [RFC1122].  [RFC1812] states that routers SHOULD NOT
   generate this error message, and states that whichever of Codes 0
   (Network Unreachable) and 1 (Host Unreachable) is appropriate SHOULD
   be used instead.

2.1.1.9.2.  Uses

   Signal unreachability condition to the sending system.

2.1.1.9.3.  Threats

   There shouldn't be any security threats araising from the use of this
   error message.

2.1.1.9.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].  However, this error message is
   deprecated, and thus system should not depend on it for any purpose.

2.1.1.10.  Communication with destination network administratively
           prohibited (code 9) - Deprecated

2.1.1.10.1.  Message specification

   This error code is defined in [RFC1122], and was intended for use by
   end-to-end encryption devices used by U.S military agencies.
   [RFC1812] deprecates its use, stating that routers SHOULD use the
   Code 13 (Communication Administratively Prohibited) if they
   administratively filter packets.

2.1.1.10.2.  Uses

   Signal unreachability condition to the sending system.

2.1.1.10.3.  Threats

   May reveal filtering policies.







Gont & Gont              Expires October 1, 2008               [Page 11]


Internet-Draft               ICMP Filtering                   March 2008


2.1.1.10.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].  However, this error message is
   deprecated, and thus system should not depend on it for any purpose.

2.1.1.11.  Communication with destination host administratively
           prohibited (code 10) - Deprecated

2.1.1.11.1.  Message specification

   This error code is defined in [RFC1122], and was intended for use by
   end-to-end encryption devices used by U.S military agencies.
   [RFC1812] deprecates its use, stating that routers SHOULD use the
   Code 13 (Communication Administratively Prohibited) if they
   administratively filter packets.

2.1.1.11.2.  Uses

   Signal unreachability condition to the sending system.

2.1.1.11.3.  Threats

   May reveal filtering policies.

2.1.1.11.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].  However, this error message is
   deprecated, and thus system should not depend on it for any purpose.

2.1.1.12.  Network unreachable for type of service (code 11)

2.1.1.12.1.  Message specification

   Defined in [RFC1122].  Section 4.3.3.1 of [RFC1812] states that if a
   router cannot forward a packet because the TOS specified for the
   routes is neither the default TOS (0000) nor the TOS of the packet
   that the router is attempting to route, then the router MUST generate
   a Destination Unreachable, Code 11 (Network Unreachable for TOS) ICMP
   message.






Gont & Gont              Expires October 1, 2008               [Page 12]


Internet-Draft               ICMP Filtering                   March 2008


2.1.1.12.2.  Uses

   Signal unreachability condition to the sending system.

2.1.1.12.3.  Threats

   May reveal routing policies.

2.1.1.12.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

2.1.1.13.  Host unreachable for type of service (code 12)

2.1.1.13.1.  Message specification

   Defined in [RFC1122].  Section 4.3.3.1 of [RFC1812] states that this
   message is sent if a packet is to be forwarded to a host that is on a
   network that is directly connected to the router and the router
   cannot forward the packet because no route to the destination has a
   TOS that is either equal to the TOS requested in the packet or is the
   default TOS (0000).

2.1.1.13.2.  Uses

   Signal unreachability condition to the sending system.

2.1.1.13.3.  Threats

   May reveal routing policies.

2.1.1.13.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

2.1.1.14.  Communication Administratively Prohibited (code 13)

2.1.1.14.1.  Message specification

   Defined in [RFC1812], and is generated if a router cannot forward a
   packet due to administrative filtering.




Gont & Gont              Expires October 1, 2008               [Page 13]


Internet-Draft               ICMP Filtering                   March 2008


2.1.1.14.2.  Uses

   Signal unreachability condition (due to filtering policies) to the
   sending system.

2.1.1.14.3.  Threats

   Given that the semantics of this error message are not accurately
   specified, some systems might abort transport connections upon
   receipt of this error message.  [I-D.ietf-tcpm-icmp-attacks].

2.1.1.14.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

2.1.1.15.  Host Precedence Violation (code 14)

2.1.1.15.1.  Message specification

   Defined in [RFC1812], and is sent by the first hop router to a host
   to indicate that a requested precedence is not permitted for the
   particular combination of source/destination host or network, upper
   layer protocol, and source/destination port

2.1.1.15.2.  Uses

   Signal unreachability condition to the sending system.

2.1.1.15.3.  Threats

   May reveal routing policies.

2.1.1.15.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

2.1.1.16.  Precedence cutoff in effect (code 15)

2.1.1.16.1.  Message specification

   Defined in [RFC1812], and is sent when the network operators have
   imposed a minimum level of precedence required for operation, and a



Gont & Gont              Expires October 1, 2008               [Page 14]


Internet-Draft               ICMP Filtering                   March 2008


   datagram was sent with a precedence below this level.

2.1.1.16.2.  Uses

2.1.1.16.3.  Threats

2.1.1.16.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

2.1.2.  Source Quench (Type 4, Code 0)

2.1.2.1.  Message specification

   The Source Quench message is defined in [RFC0792].

   Section 3.2.2.3 of [RFC1122] states that host MAY send a Source
   Quench message if it is approaching, or has reached, the point at
   which it is forced to discard incoming datagrams due to a shortage of
   reassembly buffers or other resources.  It also states that if a
   Source Quench message is received, the IP layer MUST pass it to the
   tansport layer, which SHOULD implement a mechanism for responding to
   ICMP Source Quench messages.

   Section 4.2.3.9 of the Host Requirements RFC [RFC1122] states that
   TCP MUST react to ICMP Source Quench messages by slowing transmission
   on the connection, and further further adds that the RECOMMENDED
   procedure is to put the corresponding connection in the slow-start
   phase of TCP's congestion control algorithm [RFC2581].

   Section 4.3.3.3 of the Requirements for IP Version 4 Routers RFC
   [RFC1812] notes that research seems to suggest that ICMP Source
   Quench is an ineffective (and unfair) antidote for congestion, and
   states that routers SHOULD NOT send ICMP Source Quench messages in
   response to congestion.  A router that does originate Source Quench
   messages MUST be able to limit the rate at which they are generated.
   Finally, Section 4.3.3.3 of [RFC1812] states that a router MAY ignore
   any ICMP Source Quench messages it receives.

2.1.2.2.  Uses








Gont & Gont              Expires October 1, 2008               [Page 15]


Internet-Draft               ICMP Filtering                   March 2008


2.1.2.3.  Threats

2.1.2.4.  Operational/interoperability impact if blocked

2.1.3.  Redirect (Type 5)

   Section 3.2.2.2 of [RFC1122] states that SHOULD NOT send an ICMP
   Redirect message, and that a host receiving a Redirect message MUST
   update its routing information accordingly, and process the ICMP
   redirect according to the rules stated in Section 3.3.1.2 of
   [RFC1122].  ICMP redirects that specify a a gateway that is not on
   the same connected (sub-) net through which the Redirect arrived, or
   that are received from a source other than the first-hop gateway
   SHOULD be silently disacarded.

   Section 4.3.3.2 of [RFC1812] states that a router MAY ignore ICMP
   Redirects when choosing a path for a packet originated by the router
   if the router is running a routing protocol or if forwarding is
   enabled on the router and on the interface over which the packet is
   being sent.

2.1.3.1.  Redirect datagrams for the Network (code 0)

2.1.3.1.1.  Message specification

   Defined in [RFC0792].

2.1.3.1.2.  Uses

2.1.3.1.3.  Threats

2.1.3.1.4.  Operational/interoperability impact if blocked

2.1.3.2.  Redirect datagrams for the Host (code 1)

2.1.3.2.1.  Message specification

   Defined in [RFC0792].

2.1.3.2.2.  Uses

2.1.3.2.3.  Threats

2.1.3.2.4.  Operational/interoperability impact if blocked







Gont & Gont              Expires October 1, 2008               [Page 16]


Internet-Draft               ICMP Filtering                   March 2008


2.1.3.3.  Redirect datagrams for the Type of Service and Network (code
          2)

2.1.3.3.1.  Message specification

   Defined in [RFC0792].

2.1.3.3.2.  Uses

2.1.3.3.3.  Threats

2.1.3.3.4.  Operational/interoperability impact if blocked

2.1.3.4.  Redirect datagrams for the Type of Service and Host (code 3)

2.1.3.4.1.  Message specification

   Defined in [RFC0792].

2.1.3.4.2.  Uses

2.1.3.4.3.  Threats

2.1.3.4.4.  Operational/interoperability impact if blocked

2.1.4.  Time exceeded (Type 11)

   Section 3.2.2.4 of [RFC1122] states that an incoming Time Exceeded
   message MUST be passed to the transport layer.

   Section 4.3.3.4 of [RFC1812] states that when the router receives
   (i.e., is destined for the router) a Time Exceeded message, it MUST
   comply with [RFC1122].

2.1.4.1.  Time to live exceeded in transit (code 0)

2.1.4.1.1.  Message specification

   Defined in [RFC0792].

   [RFC1812] states that a router MUST generate a Time Exceeded message
   Code 0 (In Transit) when it discards a packet due to an expired TTL
   field.  Section 4.2.3.9 of [RFC1122] states that this message should
   be handled by TCP in the same way as Destination Unreachable codes 0,
   1, 5.






Gont & Gont              Expires October 1, 2008               [Page 17]


Internet-Draft               ICMP Filtering                   March 2008


2.1.4.1.2.  Uses

   Used for the traceroute troubleshooting tool.  Signals unreachability
   condition due to routing loops.

2.1.4.1.3.  Threats

   Can be used for network mapping.

2.1.4.1.4.  Operational/interoperability impact if blocked

   Breaks the traceroute tool.  May lead to long delays between
   connection establishment attempts or long response times that could
   have been avoided by aborting non-synchronized connections in
   response to ICMP soft errors [I-D.ietf-tcpm-tcp-soft-errors].

2.1.4.2.  fragment reassembly time exceeded (code 1)

2.1.4.2.1.  Message specification

   Defined in [RFC0792].  [RFC0792] states this message may be sent by a
   host reassembling a fragmented datagram if it cannot complete the
   reassembly due to missing fragments within its time limit.  Section
   4.2.3.9 of [RFC1122] states that this message should be handled by
   TCP in the same way as Destination Unreachable codes 0, 1, 5.

2.1.4.2.2.  Uses

   Signals fragment reassembly timeout.

2.1.4.2.3.  Threats

   May reveal the timeout value used by a system for fragment
   reassembly.

2.1.4.2.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

2.1.5.  Parameter Problem (Type 12)

   Section 3.2.2.5 of [RFC1122] states that a host SHOULD generate
   Parameter Problem messages.  An incoming Parameter Problem message
   MUST be passed to the transport layer, and it MAY be reported to the
   user.  Section 4.2.3.9 of [RFC1122] states that this message should



Gont & Gont              Expires October 1, 2008               [Page 18]


Internet-Draft               ICMP Filtering                   March 2008


   be handled by TCP in the same way as Destination Unreachable codes 0,
   1, 5.

   Section 4.3.3.5 of [RFC1812] states that a router MUST generate a
   Parameter Problem message for any error not specifically covered by
   another ICMP message.  The IP header field or IP option including the
   byte indicated by the pointer field MUST be included unchanged in the
   IP header returned with this ICMP message.  Section 4.3.2 of the same
   document defines an exception to this rule.

2.1.5.1.  Pointer indicates the error (code 0)

2.1.5.1.1.  Message specification

   Defined in [RFC0792].

2.1.5.1.2.  Uses

2.1.5.1.3.  Threats

2.1.5.1.4.  Operational/interoperability impact if blocked

2.1.5.2.  Required option is missing (code 1)

2.1.5.2.1.  Message specification

   Defined in Section 3.2.2.5 of [RFC1122].  It was meant to be used in
   the military community for a missing security option.

2.1.5.2.2.  Uses

2.1.5.2.3.  Threats

2.1.5.2.4.  Operational/interoperability impact if blocked

2.2.  ICMPv4 Informational messages

2.2.1.  Echo or Echo Reply Message

2.2.1.1.  Echo message (type 8, code 0)

2.2.1.1.1.  Message specification

   Defined in [RFC0792].

   Section 3.2.2.6 of [RFC1122] states that every host MUST implement an
   ICMP Echo server function that receives Echo Requests and sends
   corresponding Echo Replies.  A host SHOULD also implement an



Gont & Gont              Expires October 1, 2008               [Page 19]


Internet-Draft               ICMP Filtering                   March 2008


   application-layer interface for sending an Echo Request and receiving
   an Echo Reply, for diagnostic purposes.  Section 3.2.2.6 of [RFC1122]
   includes a number of requirements for the processing of ICMP Echo
   messages and the generation of the corresponding replies.

   Section 4.3.3.6 of [RFC1812] contains a number of requirements with
   respect to the generation and processing of ICMP Echo or Echo Reply
   messsages, including: maximum ICMP message size all routers are
   required to receive, a number of factors that may determine whether a
   router responds (or not) to an ICMP Echo message, the implementation
   of a user/application-layer interface, and the processing of Record
   Route, Timestamp and/or Source Route options that might be present in
   an ICMP Echo message.

2.2.1.1.2.  Uses

   Used by the ping troubleshooting tool.

2.2.1.1.3.  Threats

   Can be used for network mapping [icmp-scanning].  Has been exploited
   to perform Smurf attacks [smurf].

2.2.1.1.4.  Operational/interoperability impact if blocked

   Filtering this error message will break the ping tool.  The best
   current practice is to rate-limit this ICMP message.

2.2.1.2.  Echo reply message (Type 0, code 0)

2.2.1.2.1.  Message specification

   Defined in [RFC0792].

   Section 3.2.2.6 of [RFC1122] states that every host MUST implement an
   ICMP Echo server function that receives Echo Requests and sends
   corresponding Echo Replies.  A host SHOULD also implement an
   application-layer interface for sending an Echo Request and receiving
   an Echo Reply, for diagnostic purposes.  Section 3.2.2.6 of [RFC1122]
   includes a number of requirements for the processing of ICMP Echo
   messages and the generation of the corresponding replies.

   Section 4.3.3.6 of [RFC1812] contains a number of requirements with
   respect to the generation and processing of ICMP Echo or Echo Reply
   messsages, including: maximum ICMP message size all routers are
   required to receive, a number of factors that may determine whether a
   router responds (or not) to an ICMP Echo message, the implementation
   of a user/application-layer interface, and the processing of Record



Gont & Gont              Expires October 1, 2008               [Page 20]


Internet-Draft               ICMP Filtering                   March 2008


   Route, Timestamp and/or Source Route options that might be present in
   an ICMP Echo message.

2.2.1.2.2.  Uses

   Used by the ping troubleshooting tool.

2.2.1.2.3.  Threats

   Can be used for network mapping [icmp-scanning].  Has been exploited
   to perform Smurf attacks [smurf].

2.2.1.2.4.  Operational/interoperability impact if blocked

   Filtering this error message will break the ping tool.  The best
   current practice is to rate-limit this ICMP message.

2.2.2.  Router Solicitation or Router Advertisement message

2.2.2.1.  Router Solicitation message (type 10, code 0)

2.2.2.1.1.  Message specification

   Defined in [RFC1256]

   Section 4.3.3.10 of [RFC1812] states that an IP router MUST support
   the router part of the ICMP Router Discovery Protocol on all
   connected networks on which the router supports either IP multicast
   or IP broadcast addressing.  The implementation MUST include all the
   configuration variables specified for routers, with the specified
   defaults.

2.2.2.1.2.  Uses

   Used by some systems as form of stateless autoconfiguration, to
   solicit routers on a network segment.

2.2.2.1.3.  Threats

   Can be used for network mapping (e.g., learning about routers on a
   network segment.).

2.2.2.1.4.  Operational/interoperability impact if blocked

   This mesages should ot be routed.  Therefore, there is no
   operational/interoperability impact if blocked.





Gont & Gont              Expires October 1, 2008               [Page 21]


Internet-Draft               ICMP Filtering                   March 2008


2.2.2.2.  Router Advertisement message (type 9, code 0)

2.2.2.2.1.  Message specification

   Defined in [RFC1256]

   Section 4.3.3.10 of [RFC1812] states that an IP router MUST support
   the router part of the ICMP Router Discovery Protocol on all
   connected networks on which the router supports either IP multicast
   or IP broadcast addressing.  The implementation MUST include all the
   configuration variables specified for routers, with the specified
   defaults.

2.2.2.2.2.  Uses

   Used to advertise routers on a network segment.

2.2.2.2.3.  Threats

   Can be spoofed by an attacker to direct all traffic sent on a network
   segment to itself.

2.2.2.2.4.  Operational/interoperability impact if blocked

   This mesages should ot be routed.  Therefore, there is no
   operational/interoperability impact if blocked.

2.2.3.  Timestamp or Timestamp Reply Message

2.2.3.1.  Timestamp message (type 13, code 0)

2.2.3.1.1.  Message specification

   Defined in [RFC0792].

   Section 3.2.2.8 of [RFC1122] states that a host MAY implement
   Timestamp and Timestamp Reply.  For hosts that implement these
   messages, a number of requirements are stated.

2.2.3.1.2.  Uses

2.2.3.1.3.  Threats

   Can be used for network mapping, and device fingerprinting.







Gont & Gont              Expires October 1, 2008               [Page 22]


Internet-Draft               ICMP Filtering                   March 2008


2.2.3.1.4.  Operational/interoperability impact if blocked

   None.

2.2.3.2.  Timestamp reply message (type 14, code 0)

2.2.3.2.1.  Message specification

   Defined in [RFC0792].

2.2.3.2.2.  Uses

2.2.3.2.3.  Threats

   Can be used for network mapping, and device fingerprinting.

2.2.3.2.4.  Operational/interoperability impact if blocked

   None.

2.2.4.  Information Request or Information Reply Message (Deprecated)

   These messages are described in [RFC0792] as "a way for a host to
   find out the number of the network it is on".  Section 3.2.2.7 of
   [RFC1122] and Section 4.3.3.7 of [RFC1812] deprecate the use of these
   messages.

2.2.4.1.  Information request message (type 15, code 0)

2.2.4.1.1.  Message specification

   Defined in [RFC0792].

   These messages are described in [RFC0792] as "a way for a host to
   find out the number of the network it is on".  Section 3.2.2.7 of
   [RFC1122] and Section 4.3.3.7 of [RFC1812] deprecate the use of these
   messages.

2.2.4.1.2.  Uses

2.2.4.1.3.  Threats

2.2.4.1.4.  Operational/interoperability impact if blocked








Gont & Gont              Expires October 1, 2008               [Page 23]


Internet-Draft               ICMP Filtering                   March 2008


2.2.4.2.  Information reply message (type 16, code 0)

2.2.4.2.1.  Message specification

   Defined in [RFC0792].

   These messages are described in [RFC0792] as "a way for a host to
   find out the number of the network it is on".  Section 3.2.2.7 of
   [RFC1122] and Section 4.3.3.7 of [RFC1812] deprecate the use of these
   messages.

2.2.4.2.2.  Uses

2.2.4.2.3.  Threats

2.2.4.2.4.  Operational/interoperability impact if blocked

2.2.5.  Address Mask Request or Address Mask Reply

2.2.5.1.  Address Mask Request (type 17, code 0)

2.2.5.1.1.  Message specification

   Defined in RFC0950.  Section 3.2.2.9 of [RFC1122] includes a number
   of requirements regarding the generation and processing of this
   message.

   Section 3.2.2.9 of [RFC1122] states that a host MAY implement sending
   ICMP Address Mask Request(s) and receiving ICMP Address Mask
   Reply(s).  Section 4.3.3.9 of [RFC1812] states that a router MUST
   implement support for receiving ICMP Address Mask Request messages
   and responding with ICMP Address Mask Reply messages.

2.2.5.1.2.  Uses

   Was originally defined as a means for system stateless
   autoconfiguration.

2.2.5.1.3.  Threats

   Can be used for network mapping, and OS fingerprinting.

2.2.5.1.4.  Operational/interoperability impact if blocked

   None.






Gont & Gont              Expires October 1, 2008               [Page 24]


Internet-Draft               ICMP Filtering                   March 2008


2.2.5.2.  Address Mask Reply (type 18, code 0)

2.2.5.2.1.  Message specification

   Defined in RFC0950.  Section 3.2.2.9 of [RFC1122] includes a number
   of requirements regarding the generation and processing of this
   message.

   Section 3.2.2.9 of [RFC1122] states that a host MAY implement sending
   ICMP Address Mask Request(s) and receiving ICMP Address Mask
   Reply(s).  Section 4.3.3.9 of [RFC1812] states that a router MUST
   implement support for receiving ICMP Address Mask Request messages
   and responding with ICMP Address Mask Reply messages.

2.2.5.2.2.  Uses

   Was originally defined as a means for system stateless
   autoconfiguration.

2.2.5.2.3.  Threats

   Canbe used for network mapping, and OS fingerprinting.

2.2.5.2.4.  Operational/interoperability impact if blocked

   None.


3.  Internet Control Message Protocol version 6 (ICMPv6)

3.1.  ICMPv6 error messages

   The ICMPv6 specification leaves it up to the implementation the
   reaction to ICMP error messages.  Therefore, the ICMP attacks
   described in [I-D.ietf-tcpm-icmp-attacks] might or might not be
   effective.

3.1.1.  Destination Unreachable (Type 1)

3.1.1.1.  No route to destination (code 0)

3.1.1.1.1.  Message specification

   Defined in [RFC4443].







Gont & Gont              Expires October 1, 2008               [Page 25]


Internet-Draft               ICMP Filtering                   March 2008


3.1.1.1.2.  Uses

3.1.1.1.3.  Threats

3.1.1.1.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

3.1.1.2.  Communication with destination administratively prohibited
          (code 1)

3.1.1.2.1.  Message specification

   Defined in [RFC4443].

3.1.1.2.2.  Uses

3.1.1.2.3.  Threats

3.1.1.2.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

3.1.1.3.  Beyond scope of source address (code 2)

3.1.1.3.1.  Message specification

   Defined in [RFC4443].

3.1.1.3.2.  Uses

3.1.1.3.3.  Threats

3.1.1.3.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].






Gont & Gont              Expires October 1, 2008               [Page 26]


Internet-Draft               ICMP Filtering                   March 2008


3.1.1.4.  Address unreachable (code 3)

3.1.1.4.1.  Message specification

   Defined in [RFC4443].

3.1.1.4.2.  Uses

3.1.1.4.3.  Threats

3.1.1.4.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

3.1.1.5.  Port unreachable (code 4)

3.1.1.5.1.  Message specification

   Defined in [RFC4443].

3.1.1.5.2.  Uses

3.1.1.5.3.  Threats

   This error message might used to perform Denial of Service (DoS)
   attacks against transport protocols.  [I-D.ietf-tcpm-icmp-attacks]
   describes the use of this error message to attack TCP connections.

3.1.1.5.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

3.1.1.6.  Source address failed ingress/egress policy (code 5)

3.1.1.6.1.  Message specification

   Defined in [RFC4443].

3.1.1.6.2.  Uses






Gont & Gont              Expires October 1, 2008               [Page 27]


Internet-Draft               ICMP Filtering                   March 2008


3.1.1.6.3.  Threats

3.1.1.6.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

3.1.1.7.  Reject route to destination (code 6)

3.1.1.7.1.  Message specification

   Defined in [RFC4443].

3.1.1.7.2.  Uses

3.1.1.7.3.  Threats

3.1.1.7.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

3.1.2.  Packet Too Big Message (Type 2, code 0)

3.1.2.1.  Message specification

   Defined in [RFC4443].

3.1.2.2.  Uses

   Used for the Path-MTU discovery mechanism for IPv6 defined in
   [RFC1981].

3.1.2.3.  Threats

   This error message can be used to perform Denial of Service (DoS)
   attacks against transport protocols.  [I-D.ietf-tcpm-icmp-attacks]
   describes the use of this error message to attack TCP connections.

3.1.2.4.  Operational/interoperability impact if blocked

   Filtering this error message will break the Path-MTU Discovery
   mechanism defined in [RFC1981].




Gont & Gont              Expires October 1, 2008               [Page 28]


Internet-Draft               ICMP Filtering                   March 2008


3.1.3.  Time Exceeded Message (Type 3)

3.1.3.1.  Hop limit exceeded in transit (code 0)

3.1.3.1.1.  Message specification

   Defined in [RFC4443].

3.1.3.1.2.  Uses

3.1.3.1.3.  Threats

3.1.3.1.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

3.1.3.2.  Fragment reassembly time exceeded (code 1)

3.1.3.2.1.  Message specification

   Defined in [RFC4443].

3.1.3.2.2.  Uses

   Used to signal a timeout in fragment reassembly.

3.1.3.2.3.  Threats

   May reveal the timeout value used by a system for fragment
   reassembly.

3.1.3.2.4.  Operational/interoperability impact if blocked

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors
   [I-D.ietf-tcpm-tcp-soft-errors].

3.1.4.  Parameter Problem Message (Type 4)

3.1.4.1.  Erroneous header field encountered (code 0)







Gont & Gont              Expires October 1, 2008               [Page 29]


Internet-Draft               ICMP Filtering                   March 2008


3.1.4.1.1.  Message specification

   Defined in [RFC4443].

3.1.4.1.2.  Uses

3.1.4.1.3.  Threats

   This error message might used to perform Denial of Service (DoS)
   attacks against transport protocols.  [I-D.ietf-tcpm-icmp-attacks]
   describes the use of this error message to attack TCP connections.

3.1.4.1.4.  Operational/interoperability impact if blocked

3.1.4.2.  Unrecognized Next Header type encountered (code 1)

3.1.4.2.1.  Message specification

   Defined in [RFC4443].

3.1.4.2.2.  Uses

3.1.4.2.3.  Threats

   This error message might used to perform Denial of Service (DoS)
   attacks against transport protocols.  [I-D.ietf-tcpm-icmp-attacks]
   describes the use of this error message to attack TCP connections.

3.1.4.2.4.  Operational/interoperability impact if blocked

3.1.4.3.  Unrecognized IPv6 option encountered (code 2)

3.1.4.3.1.  Message specification

   Defined in [RFC4443].

3.1.4.3.2.  Uses

3.1.4.3.3.  Threats

3.1.4.3.4.  Operational/interoperability impact if blocked

3.1.5.  Private experimentation (Type 100)

3.1.5.1.  Message specification

   Defined in [RFC4443].




Gont & Gont              Expires October 1, 2008               [Page 30]


Internet-Draft               ICMP Filtering                   March 2008


3.1.5.2.  Uses

3.1.5.3.  Threats

3.1.5.4.  Operational/interoperability impact if blocked

3.1.6.  Private experimentation (Type 101)

3.1.6.1.  Message specification

   Defined in [RFC4443].

3.1.6.2.  Uses

3.1.6.3.  Threats

3.1.6.4.  Operational/interoperability impact if blocked

3.1.7.  Reserved for expansion of ICMPv6 error messages (Type 127)

3.1.7.1.  Message specification

   Defined in [RFC4443].

3.1.7.2.  Uses

3.1.7.3.  Threats

3.1.7.4.  Operational/interoperability impact if blocked

3.2.  ICMPv6 Informational messages

3.2.1.  Echo Request or Echo Reply Message

3.2.1.1.  Echo Request message (type 128, code 0)

3.2.1.1.1.  Message specification

   Defined in [RFC4443].

3.2.1.1.2.  Uses

   Used by the ping tool to test reachability.

3.2.1.1.3.  Threats

   Can be used for network mapping [icmp-scanning] and for performing
   Smurf DoS attacks [smurf].



Gont & Gont              Expires October 1, 2008               [Page 31]


Internet-Draft               ICMP Filtering                   March 2008


3.2.1.1.4.  Operational/interoperability impact if blocked

   Filtering this error message will break the ping tool.  The best
   current practice is to rate-limit this ICMP message.

3.2.1.2.  Echo reply message (Type 129, code 0)

3.2.1.2.1.  Message specification

   Defined in [RFC4443].

3.2.1.2.2.  Uses

   Used by the ping tool to test reachability.

3.2.1.2.3.  Threats

   Can be used for network mapping [icmp-scanning] and for performing
   Smurf DoS attacks [smurf].

3.2.1.2.4.  Operational/interoperability impact if blocked

   Filtering this error message will break the ping tool.  The best
   current practice is to rate-limit this ICMP message.

3.2.2.  Private experimentation (Type 200)

3.2.2.1.  Message specification

   Defined in [RFC4443].

3.2.2.2.  Uses

3.2.2.3.  Threats

3.2.2.4.  Operational/interoperability impact if blocked

3.2.3.  Private experimentation (Type 201)

3.2.3.1.  Message specification

   Defined in [RFC4443].

3.2.3.2.  Uses







Gont & Gont              Expires October 1, 2008               [Page 32]


Internet-Draft               ICMP Filtering                   March 2008


3.2.3.3.  Threats

3.2.3.4.  Operational/interoperability impact if blocked

3.2.4.  Reserved for expansion of ICMPv6 informational messages (Type
        255)

3.2.4.1.  Message specification

   Defined in [RFC4443].

3.2.4.2.  Uses

3.2.4.3.  Threats

3.2.4.4.  Operational/interoperability impact if blocked


4.  Security Considerations

   This document does not introduce any new security implications.  It
   attempts to help mitigate security threats that rely on ICMP through
   packet filtering and rate-limiting.


5.  Acknowledgements

   This survey of ICMP specifications is based on a yet-to-be-published
   internet-draft on ICMP by Fernando Gont and Carlos Pignataro.  This
   document borrows its structure from the "ICMP filtering" wiki started
   by George Jones.

   Fernando would like to thank Paula Piedra for her love and support.


6.  References

6.1.  Normative References

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.




Gont & Gont              Expires October 1, 2008               [Page 33]


Internet-Draft               ICMP Filtering                   March 2008


   [RFC1256]  Deering, S., "ICMP Router Discovery Messages", RFC 1256,
              September 1991.

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.

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

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2581]  Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
              Control", RFC 2581, April 1999.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

6.2.  Informative References

   [I-D.ietf-tcpm-icmp-attacks]
              Gont, F., "ICMP attacks against TCP",
              draft-ietf-tcpm-icmp-attacks-03 (work in progress),
              March 2008.

   [I-D.ietf-tcpm-tcp-soft-errors]
              Gont, F., "TCP's Reaction to Soft Errors",
              draft-ietf-tcpm-tcp-soft-errors-07 (work in progress),
              December 2007.

   [icmp-scanning]
              Arkin, 0., "ICMP Usage in Scanning: The Complete Know-
              How",  http://www.sys-security.com/archive/papers/
              ICMP_Scanning_v3.0.pdf, 2001.

   [smurf]    CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of-
              Service Attacks",
               http://www.cert.org/advisories/CA-1998-01.html, 1998.


Appendix A.  Change log (to be removed before publication of the
             document as an RFC)

   blah



Gont & Gont              Expires October 1, 2008               [Page 34]


Internet-Draft               ICMP Filtering                   March 2008


Authors' Addresses

   Fernando Gont
   Universidad Tecnologica Nacional / Facultad Regional Haedo
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

   Phone: +54 11 4650 8472
   Email: fernando@gont.com.ar
   URI:   http://www.gont.com.ar


   Guillermo Gont
   Universidad Tecnologica Nacional / Facultad Regional Haedo
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

   Phone: +54 11 4650 8472
   Email: guillermo@gont.com.ar






























Gont & Gont              Expires October 1, 2008               [Page 35]


Internet-Draft               ICMP Filtering                   March 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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


Intellectual Property

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

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

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











Gont & Gont              Expires October 1, 2008               [Page 36]


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