Recommendations for filtering ICMP messages
draft-ietf-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 March 5, 2009.

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.

Table of Contents

1.  Introduction
2.  Internet Control Message Protocol version 4 (ICMP)
    2.1.  ICMPv4 error messages
        2.1.1.  Destination Unreachable (Type 3)
            2.1.1.1.  Net Unreachable (code 0)
            2.1.1.2.  Host Unreachable (code 1)
            2.1.1.3.  Protocol Unreachable (code 2)
            2.1.1.4.  Port Unreachable (code 3)
            2.1.1.5.  Fragmentation needed and DF set (code 4)
            2.1.1.6.  Source Route Failed (code 5)
            2.1.1.7.  Destination network unknown (code 6) (Deprecated)
            2.1.1.8.  Destination host unknown (code 7)
            2.1.1.9.  Source host isolated (code 8) (Deprecated)
            2.1.1.10.  Communication with destination network administratively prohibited (code 9) - Deprecated
            2.1.1.11.  Communication with destination host administratively prohibited (code 10) - Deprecated
            2.1.1.12.  Network unreachable for type of service (code 11)
            2.1.1.13.  Host unreachable for type of service (code 12)
            2.1.1.14.  Communication Administratively Prohibited (code 13)
            2.1.1.15.  Host Precedence Violation (code 14)
            2.1.1.16.  Precedence cutoff in effect (code 15)
        2.1.2.  Source Quench (Type 4, Code 0)
            2.1.2.1.  Uses
            2.1.2.2.  Message specification
            2.1.2.3.  Threats
            2.1.2.4.  Operational/interoperability impact if blocked
        2.1.3.  Redirect (Type 5)
            2.1.3.1.  Redirect datagrams for the Network (code 0)
            2.1.3.2.  Redirect datagrams for the Host (code 1)
            2.1.3.3.  Redirect datagrams for the Type of Service and Network (code 2)
            2.1.3.4.  Redirect datagrams for the Type of Service and Host (code 3)
        2.1.4.  Time exceeded (Type 11)
            2.1.4.1.  Time to live exceeded in transit (code 0)
            2.1.4.2.  fragment reassembly time exceeded (code 1)
        2.1.5.  Parameter Problem (Type 12)
            2.1.5.1.  Pointer indicates the error (code 0)
            2.1.5.2.  Required option is missing (code 1)
    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.2.  Echo reply message (Type 0, code 0)
        2.2.2.  Router Solicitation or Router Advertisement message
            2.2.2.1.  Router Solicitation message (type 10, code 0)
            2.2.2.2.  Router Advertisement message (type 9, code 0)
        2.2.3.  Timestamp or Timestamp Reply Message
            2.2.3.1.  Timestamp message (type 13, code 0)
            2.2.3.2.  Timestamp reply message (type 14, code 0)
        2.2.4.  Information Request or Information Reply Message (Deprecated)
            2.2.4.1.  Information request message (type 15, code 0)
            2.2.4.2.  Information reply message (type 16, code 0)
        2.2.5.  Address Mask Request or Address Mask Reply
            2.2.5.1.  Address Mask Request (type 17, code 0)
            2.2.5.2.  Address Mask Reply (type 18, code 0)
3.  Internet Control Message Protocol version 6 (ICMPv6)
    3.1.  ICMPv6 error messages
        3.1.1.  Destination Unreachable (Type 1)
            3.1.1.1.  No route to destination (code 0)
            3.1.1.2.  Communication with destination administratively prohibited (code 1)
            3.1.1.3.  Beyond scope of source address (code 2)
            3.1.1.4.  Address unreachable (code 3)
            3.1.1.5.  Port unreachable (code 4)
            3.1.1.6.  Source address failed ingress/egress policy (code 5)
            3.1.1.7.  Reject route to destination (code 6)
        3.1.2.  Packet Too Big Message (Type 2, code 0)
            3.1.2.1.  Uses
            3.1.2.2.  Message specification
            3.1.2.3.  Threats
            3.1.2.4.  Operational/interoperability impact if blocked
        3.1.3.  Time Exceeded Message (Type 3)
            3.1.3.1.  Hop limit exceeded in transit (code 0)
            3.1.3.2.  Fragment reassembly time exceeded (code 1)
        3.1.4.  Parameter Problem Message (Type 4)
            3.1.4.1.  Erroneous header field encountered (code 0)
            3.1.4.2.  Unrecognized Next Header type encountered (code 1)
            3.1.4.3.  Unrecognized IPv6 option encountered (code 2)
        3.1.5.  Private experimentation (Type 100)
            3.1.5.1.  Uses
            3.1.5.2.  Message specification
            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.  Uses
            3.1.6.2.  Message specification
            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.  Uses
            3.1.7.2.  Message specification
            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.2.  Echo reply message (Type 129, code 0)
        3.2.2.  Private experimentation (Type 200)
            3.2.2.1.  Uses
            3.2.2.2.  Message specification
            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.  Uses
            3.2.3.2.  Message specification
            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.  Uses
            3.2.4.2.  Message specification
            3.2.4.3.  Threats
            3.2.4.4.  Operational/interoperability impact if blocked
4.  Security Considerations
5.  Acknowledgements
6.  References
    6.1.  Normative References
    6.2.  Informative References
Appendix A.  Change log (to be removed before publication of the document as an RFC)
    A.1.  Changes from draft-gont-opsec-icmp-filtering-00
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Internet Control Message Protocol version 4 (ICMP)

2.1.  ICMPv4 error messages

[RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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] (Postel, J., “Internet Control Message Protocol,” September 1981.) also defines the ICMP Source Quench 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] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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.  Uses

Used to indicate that a router cannot forward a packet because it has no routes at all (including no default route) to the destination specified in the packet. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.1.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.). Section 4.3.3.1 of [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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.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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.2.  Host Unreachable (code 1)

2.1.1.2.1.  Uses

Used to indicate that a router cannot forward a to the intended destination because it is unreachable. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.2.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.). Section 3.2.2.1 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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.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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.3.  Protocol Unreachable (code 2)

2.1.1.3.1.  Uses

Used by hosts to indicate that the designated transport protocol is not supported.

2.1.1.3.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.). [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) states that a host SHOULD send a protocol unreachable when the designated transport protocol is not supported. Section 4.2.3.9 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) states that this message indicates a hard error condition, so TCP SHOULD abort the connection.

2.1.1.3.3.  Threats

Can be exploited to perform connection-reset attacks [I‑D.ietf‑tcpm‑icmp‑attacks] (Gont, F., “ICMP attacks against TCP,” March 2008.).

2.1.1.3.4.  Operational/interoperability impact if blocked

None.

2.1.1.4.  Port Unreachable (code 3)

2.1.1.4.1.  Uses

Used by end-systems to signal the source system that it could not demultiplex the received packet (i.e., there was no listening process on the destination port). Used by UDP-based trace route to locate the final destination (UDP probes are sent to an UDP port that is believed to be unused). Some firewalls respond with this error message when a received packet is discarded due to a violation of the firewall security policy. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.4.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.). Section 3.2.2.1 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) states that this message indicates a hard error condition, so TCP SHOULD abort the connection.

2.1.1.4.3.  Threats

Can be abused to perform connection-reset attacks [I‑D.ietf‑tcpm‑icmp‑attacks] (Gont, F., “ICMP attacks against TCP,” March 2008.).

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.5.  Fragmentation needed and DF set (code 4)

2.1.1.5.1.  Uses

Used for the Path-MTU Discovery mechanism described in [RFC1191] (Mogul, J. and S. Deering, “Path MTU discovery,” November 1990.).

2.1.1.5.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.)

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] (Gont, F., “ICMP attacks against TCP,” March 2008.) 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] (Mogul, J. and S. Deering, “Path MTU discovery,” November 1990.).

2.1.1.6.  Source Route Failed (code 5)

2.1.1.6.1.  Uses

Signals errors araising from IPv4 source routes.

2.1.1.6.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.). Section 3.2.2.1 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) states that this message indicates a hard error condition, so TCP SHOULD abort the connection.

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

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

2.1.1.7.1.  Uses

Signal unreachability condition to the sending system. Currently deprecated. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.7.2.  Message specification

Defined in [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.). [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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.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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.8.  Destination host unknown (code 7)

2.1.1.8.1.  Uses

Signal unreachability condition to the sending system. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.8.2.  Message specification

Defined in [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.), and is generated only when a router can determine (from link layer advice) that the destination host does not exist

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, F., “TCP's Reaction to Soft Errors,” April 2008.).

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

2.1.1.9.1.  Uses

Signal unreachability condition to the sending system, but is currently deprecated. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.9.2.  Message specification

Defined in [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.). [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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.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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.). 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.  Uses

Signal unreachability condition to the sending system. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.10.2.  Message specification

This error code is defined in [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.), and was intended for use by end-to-end encryption devices used by U.S military agencies. [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) deprecates its use, stating that routers SHOULD use the Code 13 (Communication Administratively Prohibited) if they administratively filter packets.

2.1.1.10.3.  Threats

May reveal filtering policies.

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.). 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.  Uses

Signal unreachability condition to the sending system, but is currently deprecated. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.11.2.  Message specification

This error code is defined in [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.), and was intended for use by end-to-end encryption devices used by U.S military agencies. [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) deprecates its use, stating that routers SHOULD use the Code 13 (Communication Administratively Prohibited) if they administratively filter packets.

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.). 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.  Uses

Signal unreachability condition to the sending system when TOS-based routing is implemented, 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. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.12.2.  Message specification

Defined in [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.). Section 4.3.3.1 of [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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.

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

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

2.1.1.13.1.  Uses

Signal unreachability condition to the sending system, when TOS-based routing is implemented, 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. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.13.1.1.  Message specification

Defined in [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.). Section 4.3.3.1 of [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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.  Threats

May reveal routing policies.

2.1.1.13.3.  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, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.14.  Communication Administratively Prohibited (code 13)

2.1.1.14.1.  Uses

Signal unreachability condition (due to filtering policies) to the sending system. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.14.2.  Message specification

Defined in [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.), and is generated if a router cannot forward a packet due to administrative filtering.

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] (Gont, F., “ICMP attacks against TCP,” March 2008.).

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.15.  Host Precedence Violation (code 14)

2.1.1.15.1.  Uses

Signal unreachability condition to the sending system. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.15.2.  Message specification

Defined in [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.), 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.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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.16.  Precedence cutoff in effect (code 15)

2.1.1.16.1.  Uses

A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.1.16.2.  Message specification

Defined in [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.), and is sent when the network operators have imposed a minimum level of precedence required for operation, and a datagram was sent with a precedence below this level.

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.2.  Source Quench (Type 4, Code 0)

2.1.2.1.  Uses

Originally meant to aid in congestion-control and flow-control. Currently ignored by moost end-system implementations, because of its security implications (see [I‑D.ietf‑tcpm‑icmp‑attacks] (Gont, F., “ICMP attacks against TCP,” March 2008.).

2.1.2.2.  Message specification

The Source Quench message is defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.).

Section 3.2.2.3 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Allman, M., Paxson, V., and W. Stevens, “TCP Congestion Control,” April 1999.).

Section 4.3.3.3 of the Requirements for IP Version 4 Routers RFC [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) states that a router MAY ignore any ICMP Source Quench messages it receives.

2.1.2.3.  Threats

2.1.2.4.  Operational/interoperability impact if blocked

None.

2.1.3.  Redirect (Type 5)

Section 3.2.2.2 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.). 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] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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.  Uses

Used by routers to communicate end-systems a better first-hop router for a particular network. Currently ignored my a large number of stacks.

2.1.3.1.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.).

2.1.3.1.3.  Threats

Can be abused by an attacker to direct all or some traffic to himself and/or to perform a DoS attack.

2.1.3.1.4.  Operational/interoperability impact if blocked

If the ICMP redirect was originated in some network segment other than the one it should be forwarded on, there is no operational impact, as the message is bogus or part of an attack. If an ICMP Redirect that was locally generated is blocked, the end-system will not be informed of the better first-hop for reaching the target network, and thus this would result in less-optimum routes being used to get the target network.

2.1.3.2.  Redirect datagrams for the Host (code 1)

2.1.3.2.1.  Uses

Used by routers to communicate end-systems a better first-hop for a particular host. Currently ignored my a large number of stacks.

2.1.3.2.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.).

2.1.3.2.3.  Threats

Can be abused by an attacker to direct all or some traffic to himself and/or to perform a DoS attack.

2.1.3.2.4.  Operational/interoperability impact if blocked

If the ICMP redirect was originated in some network segment other than the one it should be forwarded on, there is no operational impact, as the message is bogus or part of an attack. If an ICMP Redirect that was locally generated is blocked, the end-system will not be informed of the better first-hop for reaching the target network, and thus this would result in less-optimum routes being used to get the target network.

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

2.1.3.3.1.  Uses

Used by routers to communicate end-systems a better first-hop router for a particular network. Currently ignored my a large number of stacks.

2.1.3.3.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.).

2.1.3.3.3.  Threats

Can be abused by an attacker to direct all or some traffic to himself and/or to perform a DoS attack.

2.1.3.3.4.  Operational/interoperability impact if blocked

If the ICMP redirect was originated in some network segment other than the one it should be forwarded on, there is no operational impact, as the message is bogus or part of an attack. If an ICMP Redirect that was locally generated is blocked, the end-system will not be informed of the better first-hop for reaching the target network, and thus this would result in less-optimum routes being used to get the target network.

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

2.1.3.4.1.  Uses

Used by routers to communicate end-systems a better first-hop for a particular host. Currently ignored my a large number of stacks.

2.1.3.4.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.).

2.1.3.4.3.  Threats

Can be abused by an attacker to direct all or some traffic to himself and/or to perform a DoS attack.

2.1.3.4.4.  Operational/interoperability impact if blocked

If the ICMP redirect was originated in some network segment other than the one it should be forwarded on, there is no operational impact, as the message is bogus or part of an attack. If an ICMP Redirect that was locally generated is blocked, the end-system will not be informed of the better first-hop for reaching the target network, and thus this would result in less-optimum routes being used to get the target network.

2.1.4.  Time exceeded (Type 11)

Section 3.2.2.4 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) states that an incoming Time Exceeded message MUST be passed to the transport layer.

Section 4.3.3.4 of [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) states that when the router receives (i.e., is destined for the router) a Time Exceeded message, it MUST comply with [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.).

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

2.1.4.1.1.  Uses

Used for the traceroute troubleshooting tool. Signals unreachability condition due to routing loops. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.4.1.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.).

[RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) states that this message should be handled by TCP in the same way as Destination Unreachable codes 0, 1, 5.

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.4.2.  fragment reassembly time exceeded (code 1)

2.1.4.2.1.  Uses

Signals fragment reassembly timeout. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.4.2.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.). [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) states that this message should be handled by TCP in the same way as Destination Unreachable codes 0, 1, 5.

2.1.4.2.3.  Threats

May reveal the timeout value used by a system for fragment reassembly, and thus aid in evading NIDSs and fingerprinting the operating system in use by the sender of this error message.

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.5.  Parameter Problem (Type 12)

Section 3.2.2.5 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) states that this message should be handled by TCP in the same way as Destination Unreachable codes 0, 1, 5.

Section 4.3.3.5 of [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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.  Uses

A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.5.1.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.).

2.1.5.1.3.  Threats

May be used to fingerprint the operating system of the host sending this error message.

2.1.5.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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

2.1.5.2.  Required option is missing (code 1)

2.1.5.2.1.  Uses

Used in the military community for a missing security option.

2.1.5.2.2.  Message specification

Defined in Section 3.2.2.5 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.). It was meant to be used in the military community for a missing security option.

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

Used by the ping troubleshooting tool.

2.2.1.1.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.).

Section 3.2.2.6 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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.3.  Threats

Can be used for network mapping [icmp‑scanning] (Arkin, 0., “ICMP Usage in Scanning: The Complete Know-How,” 2001.). Has been exploited to perform Smurf attacks [smurf] (CERT, “CERT Advisory CA-1998-01: Smurf IP Denial-of-Service Attacks,” 1998.).

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

Used by the ping troubleshooting tool.

2.2.1.2.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.).

Section 3.2.2.6 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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.2.3.  Threats

Can be used for network mapping [icmp‑scanning] (Arkin, 0., “ICMP Usage in Scanning: The Complete Know-How,” 2001.). Has been exploited to perform Smurf attacks [smurf] (CERT, “CERT Advisory CA-1998-01: Smurf IP Denial-of-Service Attacks,” 1998.).

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

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

2.2.2.1.2.  Message specification

Defined in [RFC1256] (Deering, S., “ICMP Router Discovery Messages,” September 1991.)

Section 4.3.3.10 of [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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.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.

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

2.2.2.2.1.  Uses

Used to advertise routers on a network segment.

2.2.2.2.2.  Message specification

Defined in [RFC1256] (Deering, S., “ICMP Router Discovery Messages,” September 1991.)

Section 4.3.3.10 of [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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.3.  Threats

Can be spoofed by an attacker to direct all traffic sent on a network segment to itself and/or to perform a DoS attack.

2.2.2.2.4.  Operational/interoperability impact if blocked

This mesages should not 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.  Uses

May be used as a fall-back mechanism when NTP fails (?).

2.2.3.1.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.).

Section 3.2.2.8 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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.3.  Threats

Can be used for network mapping, and device fingerprinting.

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

May be used as a fall-back mechanism when NTP fails (?).

2.2.3.2.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.).

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. Systems depending on ICMP timestamps for time synchronization will lose their synchronization.

2.2.4.  Information Request or Information Reply Message (Deprecated)

These messages are described in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.) as "a way for a host to find out the number of the network it is on". Section 3.2.2.7 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) and Section 4.3.3.7 of [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) deprecate the use of these messages.

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

2.2.4.1.1.  Uses

These messages originally provided a basic and simple mechanism for dynamic host configuration. However, they have been deprecated.

2.2.4.1.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.).

These messages are described in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.) as "a way for a host to find out the number of the network it is on". Section 3.2.2.7 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) and Section 4.3.3.7 of [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) deprecate the use of these messages.

2.2.4.1.3.  Threats

Allow for OS and device fingerprintng.

2.2.4.1.4.  Operational/interoperability impact if blocked

None.

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

2.2.4.2.1.  Uses

These messages originally provided a basic and simple mechanism for dynamic host configuration. However, they have been deprecated.

2.2.4.2.2.  Message specification

Defined in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.).

These messages are described in [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.) as "a way for a host to find out the number of the network it is on". Section 3.2.2.7 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) and Section 4.3.3.7 of [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) deprecate the use of these messages.

2.2.4.2.3.  Threats

Allow for OS and device fingerprintng.

2.2.4.2.4.  Operational/interoperability impact if blocked

None.

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

Was originally defined as a means for system stateless autoconfiguration (to look-up the address mask).

2.2.5.1.2.  Message specification

Defined in RFC0950. Section 3.2.2.9 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) includes a number of requirements regarding the generation and processing of this message.

Section 3.2.2.9 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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.3.  Threats

Can be used for network mapping, and OS fingerprinting.

2.2.5.1.4.  Operational/interoperability impact if blocked

None.

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

2.2.5.2.1.  Uses

Was originally defined as a means for system stateless autoconfiguration (to allow systems to dynamically obtain the address mask). While they have not been deprecated, they are not used in practice.

2.2.5.2.2.  Message specification

Defined in RFC0950. Section 3.2.2.9 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) includes a number of requirements regarding the generation and processing of this message.

Section 3.2.2.9 of [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) 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] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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.3.  Threats

Can be 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] (Gont, F., “ICMP attacks against TCP,” March 2008.) 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.  Uses

Used to indicate that the ofending packet cannot be delivered because there is no route towords the destination address. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.1.1.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.1.2.  Communication with destination administratively prohibited (code 1)

3.1.1.2.1.  Uses

A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.1.2.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.1.3.  Beyond scope of source address (code 2)

3.1.1.3.1.  Uses

A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.1.3.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.1.4.  Address unreachable (code 3)

3.1.1.4.1.  Uses

A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.1.4.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.1.5.  Port unreachable (code 4)

3.1.1.5.1.  Uses

3.1.1.5.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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] (Gont, F., “ICMP attacks against TCP,” March 2008.) 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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

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

3.1.1.6.1.  Uses

A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.1.6.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.1.7.  Reject route to destination (code 6)

3.1.1.7.1.  Uses

A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.1.7.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

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

3.1.2.1.  Uses

Used for the Path-MTU discovery mechanism for IPv6 defined in [RFC1981] (McCann, J., Deering, S., and J. Mogul, “Path MTU Discovery for IP version 6,” August 1996.).

3.1.2.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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] (Gont, F., “ICMP attacks against TCP,” March 2008.) 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] (McCann, J., Deering, S., and J. Mogul, “Path MTU Discovery for IP version 6,” August 1996.).

3.1.3.  Time Exceeded Message (Type 3)

3.1.3.1.  Hop limit exceeded in transit (code 0)

3.1.3.1.1.  Uses

A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.3.1.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.3.2.  Fragment reassembly time exceeded (code 1)

3.1.3.2.1.  Uses

Used to signal a timeout in fragment reassembly. A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.3.2.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

3.1.3.2.3.  Threats

May reveal the timeout value used by a system for fragment reassembly, and thus help to perform remote OS fingerprinting. Additionally, revealing the fragment reassembly timeout value may help an attacker to evade a NIDS.

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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.4.  Parameter Problem Message (Type 4)

3.1.4.1.  Erroneous header field encountered (code 0)

3.1.4.1.1.  Uses

A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.4.1.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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] (Gont, F., “ICMP attacks against TCP,” March 2008.) describes the use of this error message to attack TCP connections.

3.1.4.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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.4.2.  Unrecognized Next Header type encountered (code 1)

3.1.4.2.1.  Uses

A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.4.2.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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] (Gont, F., “ICMP attacks against TCP,” March 2008.) describes the use of this error message to attack TCP connections.

3.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] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.4.3.  Unrecognized IPv6 option encountered (code 2)

3.1.4.3.1.  Uses

A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [I‑D.ietf‑tcpm‑tcp‑soft‑errors] (Gont, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.4.3.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

3.1.4.3.3.  Threats

3.1.4.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, F., “TCP's Reaction to Soft Errors,” April 2008.).

3.1.5.  Private experimentation (Type 100)

3.1.5.1.  Uses

3.1.5.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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

3.1.6.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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

3.1.7.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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

Used by the ping tool to test reachability.

3.2.1.1.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

3.2.1.1.3.  Threats

Can be used for network mapping [icmp‑scanning] (Arkin, 0., “ICMP Usage in Scanning: The Complete Know-How,” 2001.) and for performing Smurf DoS attacks [smurf] (CERT, “CERT Advisory CA-1998-01: Smurf IP Denial-of-Service Attacks,” 1998.).

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

Used by the ping tool to test reachability.

3.2.1.2.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

3.2.1.2.3.  Threats

Can be used for network mapping [icmp‑scanning] (Arkin, 0., “ICMP Usage in Scanning: The Complete Know-How,” 2001.) and for performing Smurf DoS attacks [smurf] (CERT, “CERT Advisory CA-1998-01: Smurf IP Denial-of-Service Attacks,” 1998.).

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

3.2.2.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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

3.2.3.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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

3.2.4.2.  Message specification

Defined in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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

The authors would like to thank Alfred Hoenes for his valuable feedback on earlier versions of this document.

The 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

6.2. Informative References

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

A.1.  Changes from draft-gont-opsec-icmp-filtering-00

• Resubmitted the Internet Draft as "draft-ietf"
• Swapped order of the "Uses" and "Message specification" sections for each of the ICMP messages, as suggested by Alfred Hoenes.
• Populated a number of sections of the draft.

Authors' Addresses

Full Copyright Statement

Copyright © 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.