Operational Security Capabilities for F. Gont IP Network Infrastructure (opsec) UTN/FRH Internet-Draft G. Gont Intended status: Informational SI6 Networks Expires: January 4, 2014 C. Pignataro Cisco July 3, 2013 Recommendations for filtering ICMP messages draft-ietf-opsec-icmp-filtering-04 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. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 4, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Gont, et al. Expires January 4, 2014 [Page 1]
Internet-Draft ICMP Filtering July 2013 described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Internet Control Message Protocol version 4 (ICMP) . . . . . . 6 2.1. ICMPv4 Error Messages . . . . . . . . . . . . . . . . . . 8 2.1.1. Destination Unreachable (Type 3) . . . . . . . . . . . 9 2.1.1.1. Net Unreachable (Code 0) . . . . . . . . . . . . . 9 2.1.1.2. Host Unreachable (Code 1) . . . . . . . . . . . . 10 2.1.1.3. Protocol Unreachable (Code 2) . . . . . . . . . . 11 2.1.1.4. Port Unreachable (Code 3) . . . . . . . . . . . . 12 2.1.1.5. Fragmentation Needed and DF Set (Code 4) . . . . . 13 2.1.1.6. Source Route Failed (Code 5) . . . . . . . . . . . 13 2.1.1.7. Destination Network Unknown (Code 6) (Deprecated) . . . . . . . . . . . . . . . . . . . 14 2.1.1.8. Destination Host Unknown (Code 7) . . . . . . . . 15 2.1.1.9. Source Host Isolated (Code 8) (Deprecated) . . . . 16 2.1.1.10. Communication with Destination Network Administratively Prohibited (Code 9) (Deprecated) . . . . . . . . . . . . . . . . . . . 16 2.1.1.11. Communication with Destination Host Administratively Prohibited (Code 10) (Deprecated) . . . . . . . . . . . . . . . . . . . 17 2.1.1.12. Network Unreachable for Type of Service (Code 11) . . . . . . . . . . . . . . . . . . . . . . . 18 2.1.1.13. Host Unreachable for Type of Service (Code 12) . . 19 2.1.1.14. Communication Administratively Prohibited (Code 13) . . . . . . . . . . . . . . . . . . . . 20 2.1.1.15. Host Precedence Violation (Code 14) . . . . . . . 21 2.1.1.16. Precedence Cutoff in Effect (Code 15) . . . . . . 21 2.1.2. Source Quench (Type 4, Code 0) . . . . . . . . . . . . 22 2.1.3. Redirect (Type 5) . . . . . . . . . . . . . . . . . . 23 2.1.3.1. Redirect Datagrams for the Network (Code 0) . . . 23 2.1.3.2. Redirect Datagrams for the Host (Code 1) . . . . . 24 Gont, et al. Expires January 4, 2014 [Page 2]
Internet-Draft ICMP Filtering July 2013 2.1.3.3. Redirect datagrams for the Type of Service and Network (Code 2) . . . . . . . . . . . . . . . . . 24 2.1.3.4. Redirect Datagrams for the Type of Service and Host (Code 3) . . . . . . . . . . . . . . . . . . 25 2.1.4. Time Exceeded (Type 11) . . . . . . . . . . . . . . . 25 2.1.4.1. Time to Live Exceeded in Transit (Code 0) . . . . 26 2.1.4.2. Fragment Reassembly Time Exceeded (Code 1) . . . . 26 2.1.5. Parameter Problem (Type 12) . . . . . . . . . . . . . 27 2.1.5.1. Pointer Indicates the Error (Code 0) . . . . . . . 27 2.1.5.2. Required Option is Missing (Code 1) . . . . . . . 28 2.2. ICMPv4 Informational Messages . . . . . . . . . . . . . . 28 2.2.1. Echo or Echo Reply Message . . . . . . . . . . . . . . 28 2.2.1.1. Echo Message (Type 8, Code 0) . . . . . . . . . . 28 2.2.1.2. Echo Reply Message (Type 0, Code 0) . . . . . . . 29 2.2.2. Router Solicitation or Router Advertisement message . 30 2.2.2.1. Router Solicitation Message (Type 10, Code 0) . . 30 2.2.2.2. Router Advertisement Message (Type 9, Code 0) . . 31 2.2.3. Timestamp or Timestamp Reply Message . . . . . . . . . 31 2.2.3.1. Timestamp Message (Type 13, Code 0) . . . . . . . 31 2.2.3.2. Timestamp Reply Message (Type 14, Code 0) . . . . 32 2.2.4. Information Request or Information Reply Message (Deprecated) . . . . . . . . . . . . . . . . . . . . . 32 2.2.4.1. Information Request Message (Type 15, Code 0) . . 32 2.2.4.2. Information Reply Message (Type 16, Code 0) . . . 33 2.2.5. Address Mask Request or Address Mask Reply . . . . . . 33 2.2.5.1. Address Mask Request (Type 17, Code 0) . . . . . . 34 2.2.5.2. Address Mask Reply (Type 18, Code 0) . . . . . . . 34 3. Internet Control Message Protocol version 6 (ICMPv6) . . . . . 35 3.1. ICMPv6 Error Messages . . . . . . . . . . . . . . . . . . 36 3.1.1. Destination Unreachable (Type 1) . . . . . . . . . . . 36 3.1.1.1. No route to destination (Code 0) . . . . . . . . . 36 3.1.1.2. Communication with destination administratively prohibited (Code 1) . . . . . . . 37 3.1.1.3. Beyond scope of source address (Code 2) . . . . . 38 3.1.1.4. Address unreachable (Code 3) . . . . . . . . . . . 38 3.1.1.5. Port unreachable (Code 4) . . . . . . . . . . . . 39 3.1.1.6. Source address failed ingress/egress policy (Code 5) . . . . . . . . . . . . . . . . . . . . . 39 3.1.1.7. Reject route to destination (Code 6) . . . . . . . 40 3.1.2. Packet Too Big Message (Type 2, Code 0) . . . . . . . 40 3.1.3. Time Exceeded Message (Type 3) . . . . . . . . . . . . 41 3.1.3.1. Hop limit exceeded in transit (Code 0) . . . . . . 41 3.1.3.2. Fragment reassembly time exceeded (Code 1) . . . . 42 3.1.4. Parameter Problem Message (Type 4) . . . . . . . . . . 42 3.1.4.1. Erroneous header field encountered (Code 0) . . . 42 3.1.4.2. Unrecognized Next Header Type encountered (Code 1) . . . . . . . . . . . . . . . . . . . . . 43 3.1.4.3. Unrecognized IPv6 option encountered (Code 2) . . 44 Gont, et al. Expires January 4, 2014 [Page 3]
Internet-Draft ICMP Filtering July 2013 3.1.5. Private experimentation (Type 100) . . . . . . . . . . 44 3.1.6. Private experimentation (Type 101) . . . . . . . . . . 45 3.1.7. Reserved for expansion of ICMPv6 error messages (Type 127) . . . . . . . . . . . . . . . . . . . . . . 45 3.2. ICMPv6 Informational messages . . . . . . . . . . . . . . 46 3.2.1. Echo Request or Echo Reply Message . . . . . . . . . . 46 3.2.1.1. Echo Request message (Type 128, Code 0) . . . . . 46 3.2.1.2. Echo reply message (Type 129, Code 0) . . . . . . 46 3.2.2. Multicast Listener Discovery (MLD) . . . . . . . . . . 46 3.2.2.1. Multicast Listener Query (Type 130) . . . . . . . 47 3.2.2.2. Multicast Listener Report (Type 131) . . . . . . . 47 3.2.2.3. Multicast Listener Done (Type 132) . . . . . . . . 47 3.2.2.4. Version 2 Multicast Listener Report (Type 143) . . 47 3.2.3. Neighbor Discovery (ND) . . . . . . . . . . . . . . . 48 3.2.3.1. Router Solicitation (Type 133) . . . . . . . . . . 48 3.2.3.2. Router Advertisement (Type 134) . . . . . . . . . 48 3.2.3.3. Neighbor Solicitation (Type 135) . . . . . . . . . 48 3.2.3.4. Neighbor Advertisement (Type 136) . . . . . . . . 48 3.2.3.5. Redirect Message (Type 137) . . . . . . . . . . . 49 3.2.4. Router Renumbering (Type 138) . . . . . . . . . . . . 49 3.2.5. IPv6 Node Information Queries . . . . . . . . . . . . 49 3.2.5.1. ICMP Node Information Query (Type 139) . . . . . . 49 3.2.5.2. ICMP Node Information Response (Type 140) . . . . 50 3.2.6. IPv6 ND Inverse Discovery . . . . . . . . . . . . . . 50 3.2.6.1. Inverse Neighbor Discovery Solicitation Message (Type 141) . . . . . . . . . . . . . . . . 50 3.2.6.2. Inverse Neighbor Discovery Advertisement Message (Type 142) . . . . . . . . . . . . . . . . 50 3.2.7. Mobility . . . . . . . . . . . . . . . . . . . . . . . 50 3.2.7.1. Home Agent Address Discovery Request Message (Type 144) . . . . . . . . . . . . . . . . . . . . 50 3.2.7.2. Home Agent Address Discovery Reply Message (Type 145) . . . . . . . . . . . . . . . . . . . . 51 3.2.7.3. Mobile Prefix Solicitation (Type 146) . . . . . . 51 3.2.7.4. Mobile Prefix Advertisement (Type 147) . . . . . . 51 3.2.8. SEcure Neighbor Discovery (SEND) . . . . . . . . . . . 52 3.2.8.1. Certification Path Solicitation Message (Type 148) . . . . . . . . . . . . . . . . . . . . . . . 52 3.2.8.2. Certification Path Advertisement Message (Type 149) . . . . . . . . . . . . . . . . . . . . . . . 52 3.2.9. ICMP messages utilized by experimental mobility protocols such as Seamoby (Type 150) . . . . . . . . . 52 3.2.10. Multicast Router Discovery . . . . . . . . . . . . . . 52 3.2.10.1. Multicast Router Advertisement (Type 151) . . . . 52 3.2.10.2. Multicast Router Solicitation (Type 152) . . . . . 53 3.2.10.3. Multicast Router Termination (Type 153) . . . . . 53 3.2.11. FMIPv6 Messages (Type 154) . . . . . . . . . . . . . . 53 3.2.12. RPL Control Message (Type 155) . . . . . . . . . . . . 54 Gont, et al. Expires January 4, 2014 [Page 4]
Internet-Draft ICMP Filtering July 2013 3.2.13. Private experimentation (Type 200) . . . . . . . . . . 54 3.2.14. Private experimentation (Type 201) . . . . . . . . . . 54 3.2.15. Reserved for expansion of ICMPv6 informational messages (Type 255) . . . . . . . . . . . . . . . . . 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 55 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 7.1. Normative References . . . . . . . . . . . . . . . . . . . 56 7.2. Informative References . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 Gont, et al. Expires January 4, 2014 [Page 5]
Internet-Draft ICMP Filtering July 2013 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) Table 1 summarizes the recommendations with respect to what a device SHOULD do when generating, forwarding, or receiving ICMPv6 messages. Gont, et al. Expires January 4, 2014 [Page 6]
Internet-Draft ICMP Filtering July 2013 +-------------------------------+----------+-----------+------------+ | ICMPv4 Message | Sourced | Through | Destined | | | from | Device | to Device | | | Device | | | +-------------------------------+----------+-----------+------------+ | ICMPv4-unreach-net | Rate-L | Rate-L | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-unreach-host | Rate-L | Rate-L | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-unreach-proto | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-unreach-port | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-unreach-frag-needed | Send | Permit | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-unreach-src-route | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-unreach-net-unknown | Deny | Deny | Deny | | (Depr) | | | | +-------------------------------+----------+-----------+------------+ | ICMPv4-unreach-host-unknown | Rate-L | Deny | Ignore | +-------------------------------+----------+-----------+------------+ | ICMPv4-unreach-host-isolated | Deny | Deny | Deny | | (Depr) | | | | +-------------------------------+----------+-----------+------------+ | ICMPv4-unreach-net-tos | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-unreach-host-tos | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-unreach-admin | Rate-L | Rate-L | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-unreach-prec-violation | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-unreach-prec-cutoff | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-quench | Deny | Deny | Deny | +-------------------------------+----------+-----------+------------+ | ICMPv4-redirect-net | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-redirect-host | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-redirect-tos-net | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-redirect-tos-host | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-timed-ttl | Rate-L | Permit | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-timed-reass | Rate-L | Permit | Rate-L | Gont, et al. Expires January 4, 2014 [Page 7]
Internet-Draft ICMP Filtering July 2013 | ICMPv4-parameter-pointer | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-option-missing | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-req-echo-message | Rate-L | Permit | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-req-echo-reply | Rate-L | Permit | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-req-router-sol | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-req-router-adv | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-req-timestamp-message | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-req-timestamp-reply | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-info-message (Depr) | Deny | Deny | Deny | +-------------------------------+----------+-----------+------------+ | ICMPv4-info-reply (Depr) | Deny | Deny | Deny | +-------------------------------+----------+-----------+------------+ | ICMPv4-mask-request | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ | ICMPv4-mask-reply | Rate-L | Deny | Rate-L | +-------------------------------+----------+-----------+------------+ Legend: "Depr" = Deprecated; "Rate-L" = Rate-Limit Table 1: Summary Recommendations for ICMPv4 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 Gont, et al. Expires January 4, 2014 [Page 8]
Internet-Draft ICMP Filtering July 2013 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] originally defined the ICMP Source Quench message (Type 4, Code 0), which was meant to provide a mechanism for flow control and congestion control. ICMP Source Quench is being formally deprecated by [RFC6633]. [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) Gont, et al. Expires January 4, 2014 [Page 9]
Internet-Draft ICMP Filtering July 2013 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 [RFC5461]. 2.1.1.1.2. 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.3. Threats An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. This attack be mitigated by rate-limiting the rate of IMCP messages generated. For rate-limiting ICMPv4 messages see Section 4.3.2.8 of [RFC1812]. 2.1.1.1.4. Operational and 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 [RFC5461]. 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 Gont, et al. Expires January 4, 2014 [Page 10]
Internet-Draft ICMP Filtering July 2013 connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [RFC5461]. 2.1.1.2.2. 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.3. Threats An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. This can be mitigated by rate-limiting the rate of IMCP messages generated. For rate-limiting ICMPv4 messages see Section 4.3.2.8 of [RFC1812]. 2.1.1.2.4. Operational and 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 [RFC5461]. 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]. [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. Gont, et al. Expires January 4, 2014 [Page 11]
Internet-Draft ICMP Filtering July 2013 2.1.1.3.3. Threats Can be exploited to perform connection-reset attacks [RFC5927]. Such attacks need to be mitigated at hosts, as discussed in [RFC5927]. An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. These DoS attacks can be mitigated by rate-limiting the rate of IMCP messages generated. For rate-limiting ICMPv4 messages see Section 4.3.2.8 of [RFC1812]. 2.1.1.3.4. Operational and 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 [RFC5461]. 2.1.1.4.2. 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. Gont, et al. Expires January 4, 2014 [Page 12]
Internet-Draft ICMP Filtering July 2013 2.1.1.4.3. Threats Can be exploited to perform connection-reset attacks [RFC5927]. Such attacks need to be mitigated at hosts, as discussed in [RFC5927]. An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. These DoS attacks can be mitigated by rate-limiting the rate of IMCP messages generated. For rate-limiting ICMPv4 messages see Section 4.3.2.8 of [RFC1812]. 2.1.1.4.4. Operational and 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 [RFC5461]. 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]. 2.1.1.5.2. Message Specification Defined in [RFC0792] 2.1.1.5.3. Threats This error message can be used to perform Denial of Service (DoS) attacks against transport protocols. [RFC5927] describes the use of this error message to attack TCP connections. 2.1.1.5.4. Operational and 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. Uses Signals errors araising from IPv4 source routes. Gont, et al. Expires January 4, 2014 [Page 13]
Internet-Draft ICMP Filtering July 2013 2.1.1.6.2. 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.3. Threats An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. This can be mitigated by rate-limiting the rate of IMCP messages generated. For rate-limiting ICMPv4 messages see Section 4.3.2.8 of [RFC1812]. 2.1.1.6.4. Operational and 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 [RFC5461]. 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 [RFC5461]. 2.1.1.7.2. 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). Gont, et al. Expires January 4, 2014 [Page 14]
Internet-Draft ICMP Filtering July 2013 2.1.1.7.3. Threats An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. This can be mitigated by not-generating and dropping (rather than forwarding) these messages (since they have been deprecated). 2.1.1.7.4. Operational and 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 [RFC5461]. 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 [RFC5461]. 2.1.1.8.2. 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.3. Threats An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. This can be mitigated by rate-limiting the rate of IMCP messages generated. For rate-limiting ICMPv4 messages see Section 4.3.2.8 of [RFC1812]. Gont, et al. Expires January 4, 2014 [Page 15]
Internet-Draft ICMP Filtering July 2013 2.1.1.8.4. Operational and 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 [RFC5461]. 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 [RFC5461]. 2.1.1.9.2. 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.3. Threats An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. This can be mitigated by rate-limiting the rate of IMCP messages generated. For rate-limiting ICMPv4 messages see Section 4.3.2.8 of [RFC1812]. 2.1.1.9.4. Operational and Interoperability Impact if Blocked Might 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 [RFC5461]. However, this error message is deprecated, and thus systems should not depend on it for any purpose. 2.1.1.10. Communication with Destination Network Administratively Prohibited (Code 9) (Deprecated) Gont, et al. Expires January 4, 2014 [Page 16]
Internet-Draft ICMP Filtering July 2013 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 [RFC5461]. 2.1.1.10.2. 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.3. Threats May reveal filtering policies. In orther to mitigate this issue, a node could deny the generation of these error messages. However, we note that this would also have a negative impact on network troubleshooting. An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. These DoS attacks can be mitigated by rate-limiting the rate of IMCP messages generated. For rate-limiting ICMPv4 messages see Section 4.3.2.8 of [RFC1812]. 2.1.1.10.4. Operational and 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 [RFC5461]. 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 [RFC5461]. Gont, et al. Expires January 4, 2014 [Page 17]
Internet-Draft ICMP Filtering July 2013 2.1.1.11.2. 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.3. Threats May reveal filtering policies. In orther to mitigate this issue, a node could deny the generation of these error messages. However, we note that this would also have a negative impact on network troubleshooting. An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. This can be mitigated by rate-limiting the rate of ICMP messages generated. For rate-limiting ICMPv4 messages see Section 4.3.2.8 of [RFC1812]. 2.1.1.11.4. Operational and 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 [RFC5461]. 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 [RFC5461]. Gont, et al. Expires January 4, 2014 [Page 18]
Internet-Draft ICMP Filtering July 2013 2.1.1.12.2. 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. 2.1.1.12.3. Threats May reveal routing policies. An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. This can be mitigated by rate-limiting the rate of ICMP messages generated. For rate-limiting ICMPv4 messages see Section 4.3.2.8 of [RFC1812]. 2.1.1.12.4. Operational and 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 [RFC5461]. 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 [RFC5461]. 2.1.1.13.1.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). Gont, et al. Expires January 4, 2014 [Page 19]
Internet-Draft ICMP Filtering July 2013 2.1.1.13.2. Threats May reveal routing policies. An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. This can be mitigated by rate-limiting the rate of ICMP messages generated. For rate-limiting ICMPv4 messages see Section 4.3.2.8 of [RFC1812]. 2.1.1.13.3. Operational and 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 [RFC5461]. 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 [RFC5461]. 2.1.1.14.2. Message Specification Defined in [RFC1812], and is generated if a router cannot forward a packet due to administrative filtering. 2.1.1.14.3. Threats May reveal filtering policies. Given that the semantics of this error message are not accurately specified, some systems might abort transport connections upon receipt of this error message. [RFC5927]. An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. This can be mitigated by rate-limiting the rate of ICMP messages generated. For rate-limiting ICMPv4 messages see Section Gont, et al. Expires January 4, 2014 [Page 20]
Internet-Draft ICMP Filtering July 2013 4.3.2.8 of [RFC1812]. 2.1.1.14.4. Operational and 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 [RFC5461]. 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 [RFC5461]. 2.1.1.15.2. 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.3. Threats May reveal routing policies. An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. This can be mitigated by rate-limiting the rate of ICMP messages generated. For rate-limiting ICMPv4 messages see Section 4.3.2.8 of [RFC1812]. 2.1.1.15.4. Operational and 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 [RFC5461]. 2.1.1.16. Precedence Cutoff in Effect (Code 15) Gont, et al. Expires January 4, 2014 [Page 21]
Internet-Draft ICMP Filtering July 2013 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 [RFC5461]. 2.1.1.16.2. Message Specification Defined in [RFC1812], 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 An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. This can be mitigated by rate-limiting the rate of ICMP messages generated. For rate-limiting ICMPv4 messages see Section 4.3.2.8 of [RFC1812]. 2.1.1.16.4. Operational and 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 [RFC5461]. 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 most end-system implementations, because of its security implications (see [RFC5927]. It is being formally deprecated by [RFC6633]. 2.1.2.2. Message Specification The Source Quench message was originally specified in [RFC0792]. It is being formally deprecated by [RFC6633]. 2.1.2.3. Threats Can be exploited for performing throughput-reduction attacks [RFC5927]. Gont, et al. Expires January 4, 2014 [Page 22]
Internet-Draft ICMP Filtering July 2013 2.1.2.4. Operational and Interoperability Impact if Blocked None. 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. Uses Used by routers to communicate end-systems a better first-hop router for a particular network. Currently ignored by a large number of stacks. 2.1.3.1.2. Message Specification Defined in [RFC0792]. 2.1.3.1.3. Threats Can be abused by an attacker to redirect all or some traffic to himself and/or to perform a DoS attack. This issue could be mitigated by disabling reaction to ICMP Redirect messages at hosts and/or dropping these messages at the network. 2.1.3.1.4. Operational and 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 Gont, et al. Expires January 4, 2014 [Page 23]
Internet-Draft ICMP Filtering July 2013 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]. 2.1.3.2.3. Threats Can be abused by an attacker to redirect all or some traffic to himself and/or to perform a DoS attack. This issue could be mitigated by disabling reaction to ICMP Redirect messages at hosts and/or dropping these messages at the network. 2.1.3.2.4. Operational and 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]. Gont, et al. Expires January 4, 2014 [Page 24]
Internet-Draft ICMP Filtering July 2013 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. This issue could be mitigated by disabling reaction to ICMP Redirect messages at hosts and/or dropping these messages at the network. 2.1.3.3.4. Operational and 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]. 2.1.3.4.3. Threats Can be abused by an attacker to redirect all or some traffic to himself and/or to perform a DoS attack. 2.1.3.4.4. Operational and 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] states that an incoming Time Exceeded message MUST be passed to the transport layer. Gont, et al. Expires January 4, 2014 [Page 25]
Internet-Draft ICMP Filtering July 2013 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. 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 [RFC5461]. 2.1.4.1.2. 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. 2.1.4.1.3. Threats Can be used for network mapping. 2.1.4.1.4. Operational and 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 [RFC5461]. 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 [RFC5461]. 2.1.4.2.2. 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 Gont, et al. Expires January 4, 2014 [Page 26]
Internet-Draft ICMP Filtering July 2013 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 and 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 [RFC5461]. 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 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. Uses A number of systems abort connections in non-synchronized states in response to this message, to avoid long delays in connection establishment attempts [RFC5461]. 2.1.5.1.2. Message Specification Defined in [RFC0792]. 2.1.5.1.3. Threats May be used to fingerprint the operating system of the host sending this error message. Gont, et al. Expires January 4, 2014 [Page 27]
Internet-Draft ICMP Filtering July 2013 2.1.5.1.4. Operational and 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 [RFC5461]. 2.1.5.2. Required Option is Missing (Code 1) 2.1.5.2.1. Uses This ICMP Parameter Problem message Code is sent whenever a received IP packet should have contained a particular IP Option but the actual received IP packet did not contain that IP option. At present, a common situation in which this is ICMP Parameter Problem message Type is likely to arise is in certain high-security IP deployments where one or more IP Security options (e.g. RFC-1108, CIPSO) are deployed, and a packet is missing one of those security options. Other similar situations might also exist now, or in future. 2.1.5.2.2. Message Specification Defined in Section 3.2.2.5 of [RFC1122]. 2.1.5.2.3. Threats None. 2.1.5.2.4. Operational and 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 [RFC5461]. Additionally, blocking this ICMP message would make network trouble- shooting difficult or impossible in networks where IP Security Options (e.g. CIPSO, IPSO) are deployed. So blocking these ICMP messages could lead to a kind of denial-of-service attack on such deployments. 2.2. ICMPv4 Informational Messages 2.2.1. Echo or Echo Reply Message 2.2.1.1. Echo Message (Type 8, Code 0) Gont, et al. Expires January 4, 2014 [Page 28]
Internet-Draft ICMP Filtering July 2013 2.2.1.1.1. Uses Used by the ping troubleshooting tool. 2.2.1.1.2. 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 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]. This vector could be partially mitigated by applying rate-limit to this traffic. Has been exploited to perform Smurf attacks [smurf]. A router could mitigate this by dropping ICMP echor request messages directed to any of its directly-connected subnets. 2.2.1.1.4. Operational and 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. Gont, et al. Expires January 4, 2014 [Page 29]
Internet-Draft ICMP Filtering July 2013 2.2.1.2.2. 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 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]. Has been exploited to perform Smurf attacks [smurf]. 2.2.1.2.4. Operational and 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] 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 Gont, et al. Expires January 4, 2014 [Page 30]
Internet-Draft ICMP Filtering July 2013 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 and Interoperability Impact if Blocked This mesages should not 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] 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.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 and 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 (?). Gont, et al. Expires January 4, 2014 [Page 31]
Internet-Draft ICMP Filtering July 2013 2.2.3.1.2. 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.3. Threats Can be used for network mapping, and device fingerprinting. 2.2.3.1.4. Operational and 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]. 2.2.3.2.3. Threats Can be used for network mapping and device fingerprinting. 2.2.3.2.4. Operational and Interoperability Impact if Blocked Systems will not be able to use ICMP timestamps as a fall-bak mechanism when NTP fails. 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. Uses These messages originally provided a basic and simple mechanism for dynamic host configuration. However, they have been deprecated. Gont, et al. Expires January 4, 2014 [Page 32]
Internet-Draft ICMP Filtering July 2013 2.2.4.1.2. 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.3. Threats Allows for OS (Operating Sytem) and device fingerprintng. Since this messages have been deprecated, the best possible mitigation is to not generate and to drop any received Information Request messages. 2.2.4.1.4. Operational and 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]. 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.3. Threats Allow for OS and device fingerprintng. 2.2.4.2.4. Operational and Interoperability Impact if Blocked None. 2.2.5. Address Mask Request or Address Mask Reply Gont, et al. Expires January 4, 2014 [Page 33]
Internet-Draft ICMP Filtering July 2013 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] 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.3. Threats Can be used for network mapping, and OS fingerprinting. 2.2.5.1.4. Operational and 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] 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. Gont, et al. Expires January 4, 2014 [Page 34]
Internet-Draft ICMP Filtering July 2013 2.2.5.2.3. Threats Can be used for network mapping, and OS fingerprinting. 2.2.5.2.4. Operational and Interoperability Impact if Blocked None. 3. Internet Control Message Protocol version 6 (ICMPv6) Table 2 summarizes the recommendations with respect to what a device SHOULD do when generating, forwarding, or receiving ICMPv6. +---------------------------------+-----------+---------+-----------+ | ICMPv6 Message | Sourced | Through | Destined | | | from | Device | to Device | | | Device | | | +---------------------------------+-----------+---------+-----------+ | ICMPv6-unreach | N/A | N/A | N/A | +---------------------------------+-----------+---------+-----------+ | ICMPv6-unreach-no-route | Rate-L | Permit | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-unreach-admin-prohibited | Rate-L | Permit | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-unreach-beyond-scope | Rate-L | Deny | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-unreach-addr | Rate-L | Permit | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-unreach-port | Rate-L | Permit | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-unreach-source-addr | Rate-L | Deny | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-unreach-reject-route | Rate-L | Permit | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-too-big | Send | Permit | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-timed | N/A | N/A | N/A | +---------------------------------+-----------+---------+-----------+ | ICMPv6-timed-hop-limit | Send | Permit | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-timed-reass | Send | Permit | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-parameter | Rate-L | Permit | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-parameter-err-header | Rate-L | Deny | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-parameter-unrec-header | Rate-L | Deny | Rate-L | Gont, et al. Expires January 4, 2014 [Page 35]
Internet-Draft ICMP Filtering July 2013 | ICMPv6-parameter-unrec-option | Rate-L | Permit | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-err-private-exp-100 | Send | Deny | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-err-private-exp-101 | Send | Deny | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-err-expansion | Send | Permit | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-echo-message | Send | Permit | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-echo-reply | Send | Permit | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-info-private-exp-200 | Send | Deny | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-info-private-exp-201 | Send | Deny | Rate-L | +---------------------------------+-----------+---------+-----------+ | ICMPv6-info-expansion | Send | Permit | Rate-L | +---------------------------------+-----------+---------+-----------+ Legend: "Rate-L" = Rate-Limit Table 2: Summary Recommendations for 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 [RFC5927] 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 [RFC5461]. 3.1.1.1.2. Message Specification Defined in [RFC4443]. Gont, et al. Expires January 4, 2014 [Page 36]
Internet-Draft ICMP Filtering July 2013 3.1.1.1.3. Threats An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMPv6 messages. This can be mitigated by rate-limiting the rate of ICMPv6 messages generated. For rate-limiting ICMPv6 messages see Section 2.4, paragraph (f), of [RFC4443]. 3.1.1.1.4. Operational and 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 [RFC5461]. 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 [RFC5461]. 3.1.1.2.2. Message Specification Defined in [RFC4443]. 3.1.1.2.3. Threats May reveal filtering policies. An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMPv6 messages. This can be mitigated by rate-limiting the rate of ICMPv6 messages generated. For rate-limiting ICMPv6 messages see Section 2.4, paragraph (f), of [RFC4443]. 3.1.1.2.4. Operational and 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 [RFC5461]. Gont, et al. Expires January 4, 2014 [Page 37]
Internet-Draft ICMP Filtering July 2013 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 [RFC5461]. 3.1.1.3.2. Message Specification Defined in [RFC4443]. 3.1.1.3.3. Threats 3.1.1.3.4. Operational and 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 [RFC5461]. 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 [RFC5461]. 3.1.1.4.2. Message Specification Defined in [RFC4443]. 3.1.1.4.3. Threats An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMPv6 Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMPv6 messages. This can be mitigated by rate-limiting the rate of ICMPv6 messages generated. For rate-limiting ICMPv6 messages see Section 2.4, paragraph (f), of [RFC4443]. 3.1.1.4.4. Operational and 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 [RFC5461]. Gont, et al. Expires January 4, 2014 [Page 38]
Internet-Draft ICMP Filtering July 2013 3.1.1.5. Port unreachable (Code 4) 3.1.1.5.1. Uses Used to identicate that there is no listening process on the target transport protocol port. 3.1.1.5.2. Message Specification Defined in [RFC4443]. 3.1.1.5.3. Threats This error message might used to perform Denial of Service (DoS) attacks against transport protocols. [RFC5927] describes the use of this error message to attack TCP connections. An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMPv6 Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMPv6 messages. This can be mitigated by rate-limiting the rate of ICMPv6 messages generated. For rate-limiting ICMPv6 messages see Section 2.4, paragraph (f), of [RFC4443]. 3.1.1.5.4. Operational and 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 [RFC5461]. 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 [RFC5461]. 3.1.1.6.2. Message Specification Defined in [RFC4443]. 3.1.1.6.3. Threats May reveal filtering policies. Gont, et al. Expires January 4, 2014 [Page 39]
Internet-Draft ICMP Filtering July 2013 An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMPv6 messages. This can be mitigated by rate-limiting the rate of ICMPv6 messages generated. For rate-limiting ICMPv6 messages see Section 2.4, paragraph (f), of [RFC4443]. 3.1.1.6.4. Operational and 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 [RFC5461]. 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 [RFC5461]. 3.1.1.7.2. Message Specification Defined in [RFC4443]. 3.1.1.7.3. Threats An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMPv6 messages. This can be mitigated by rate-limiting the rate of ICMPv6 messages generated. For rate-limiting ICMPv6 messages see Section 2.4, paragraph (f), of [RFC4443]. 3.1.1.7.4. Operational and 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 [RFC5461]. 3.1.2. Packet Too Big Message (Type 2, Code 0) Gont, et al. Expires January 4, 2014 [Page 40]
Internet-Draft ICMP Filtering July 2013 3.1.2.1. Uses Used for the Path-MTU discovery mechanism for IPv6 defined in [RFC1981]. 3.1.2.2. Message Specification Defined in [RFC4443]. 3.1.2.3. Threats This error message can be used to perform Denial of Service (DoS) attacks against transport protocols. [RFC5927] describes the use of this error message to attack TCP connections. 3.1.2.4. Operational and Interoperability Impact if Blocked Filtering this error message will break the Path-MTU Discovery mechanism defined in [RFC1981], which could lead to a Denial of Service (unless the sending node implements some for of Path-MTU blackhole detection). 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 [RFC5461]. 3.1.3.1.2. Message Specification Defined in [RFC4443]. 3.1.3.1.3. Threats May be used for network mapping. 3.1.3.1.4. Operational and 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 [RFC5461]. Gont, et al. Expires January 4, 2014 [Page 41]
Internet-Draft ICMP Filtering July 2013 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 [RFC5461]. 3.1.3.2.2. Message Specification Defined in [RFC4443]. 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 and 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 [RFC5461]. 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 [RFC5461]. 3.1.4.1.2. Message Specification Defined in [RFC4443]. 3.1.4.1.3. Threats This error message might used to perform Denial of Service (DoS) attacks against transport protocols. [RFC5927] describes the use of this error message to attack TCP connections. An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Gont, et al. Expires January 4, 2014 [Page 42]
Internet-Draft ICMP Filtering July 2013 Parameter Problem messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMPv6 messages. This can be mitigated by rate-limiting the rate of ICMPv6 messages generated. For rate-limiting ICMPv6 messages see Section 2.4, paragraph (f), of [RFC4443]. 3.1.4.1.4. Operational and 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 [RFC5461]. 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 [RFC5461]. 3.1.4.2.2. Message Specification Defined in [RFC4443]. 3.1.4.2.3. Threats This error message might used to perform Denial of Service (DoS) attacks against transport protocols. [RFC5927] describes the use of this error message to attack TCP connections. An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Parameter Problem messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMPv6 messages. This can be mitigated by rate-limiting the rate of ICMPv6 messages generated. For rate-limiting ICMPv6 messages see Section 2.4, paragraph (f), of [RFC4443]. 3.1.4.2.4. Operational and 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 [RFC5461]. Gont, et al. Expires January 4, 2014 [Page 43]
Internet-Draft ICMP Filtering July 2013 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 [RFC5461]. 3.1.4.3.2. Message Specification Defined in [RFC4443]. 3.1.4.3.3. Threats An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Parameter Problem messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMPv6 messages. This can be mitigated by rate-limiting the rate of ICMPv6 messages generated. For rate-limiting ICMPv6 messages see Section 2.4, paragraph (f), of [RFC4443]. 3.1.4.3.4. Operational and 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 [RFC5461]. 3.1.5. Private experimentation (Type 100) 3.1.5.1. Uses Used for performing controlled experiments with ICMPv6 messages before a specific ICMPv6 Type is formally assigned by IANA. 3.1.5.2. Message Specification Defined in [RFC4443]. 3.1.5.3. Threats The security implications of this message Type will depend on the specific experiment the message is being used for and whether the node this message is destined to implements the aforementioned "experiment". Gont, et al. Expires January 4, 2014 [Page 44]
Internet-Draft ICMP Filtering July 2013 3.1.5.4. Operational and Interoperability Impact if Blocked None (this message Type is meant for experimentation rather than "production"). 3.1.6. Private experimentation (Type 101) 3.1.6.1. Uses Used for performing controlled experiments with ICMPv6 messages before a specific ICMPv6 Type is formally assigned by IANA. 3.1.6.2. Message Specification Defined in [RFC4443]. 3.1.6.3. Threats The security implications of this message Type will depend on the specific experiment the message is being used for and whether the node this message is destined to implements the aforementioned "experiment". 3.1.6.4. Operational and Interoperability Impact if Blocked None (this message Type is meant for controlled experimentation rather than "production"). 3.1.7. Reserved for expansion of ICMPv6 error messages (Type 127) 3.1.7.1. Uses Type value 127 is reserved for future expansion of the type value range if there is a shortage in the future. 3.1.7.2. Message Specification Defined in [RFC4443]. 3.1.7.3. Threats None. 3.1.7.4. Operational and Interoperability Impact if Blocked It would prevent expansion of the Type value range, and hence prevent extension of the ICMPv6 protocol. Gont, et al. Expires January 4, 2014 [Page 45]
Internet-Draft ICMP Filtering July 2013 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]. 3.2.1.1.3. Threats Can be used for network mapping [icmp-scanning] and for performing Smurf DoS attacks [smurf]. 3.2.1.1.4. Operational and 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]. 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 and 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. Multicast Listener Discovery (MLD) Gont, et al. Expires January 4, 2014 [Page 46]
Internet-Draft ICMP Filtering July 2013 3.2.2.1. Multicast Listener Query (Type 130) 3.2.2.1.1. Uses 3.2.2.1.2. Message Specification Defined in [RFC2710]. 3.2.2.1.3. Threats 3.2.2.1.4. Operational and Interoperability Impact if Blocked 3.2.2.2. Multicast Listener Report (Type 131) 3.2.2.2.1. Uses 3.2.2.2.2. Message Specification Defined in [RFC2710]. 3.2.2.2.3. Threats 3.2.2.2.4. Operational and Interoperability Impact if Blocked 3.2.2.3. Multicast Listener Done (Type 132) 3.2.2.3.1. Uses 3.2.2.3.2. Message Specification Defined in [RFC2710]. 3.2.2.3.3. Threats 3.2.2.3.4. Operational and Interoperability Impact if Blocked 3.2.2.4. Version 2 Multicast Listener Report (Type 143) 3.2.2.4.1. Uses 3.2.2.4.2. Message Specification Defined in [RFC3810]. 3.2.2.4.3. Threats Gont, et al. Expires January 4, 2014 [Page 47]
Internet-Draft ICMP Filtering July 2013 3.2.2.4.4. Operational and Interoperability Impact if Blocked 3.2.3. Neighbor Discovery (ND) 3.2.3.1. Router Solicitation (Type 133) 3.2.3.1.1. Uses 3.2.3.1.2. Message Specification Defined in [RFC4861]. 3.2.3.1.3. Threats 3.2.3.1.4. Operational and Interoperability Impact if Blocked 3.2.3.2. Router Advertisement (Type 134) 3.2.3.2.1. Uses 3.2.3.2.2. Message Specification Defined in [RFC4861]. 3.2.3.2.3. Threats 3.2.3.2.4. Operational and Interoperability Impact if Blocked 3.2.3.3. Neighbor Solicitation (Type 135) 3.2.3.3.1. Uses 3.2.3.3.2. Message Specification Defined in [RFC4861]. 3.2.3.3.3. Threats 3.2.3.3.4. Operational and Interoperability Impact if Blocked 3.2.3.4. Neighbor Advertisement (Type 136) 3.2.3.4.1. Uses Gont, et al. Expires January 4, 2014 [Page 48]
Internet-Draft ICMP Filtering July 2013 3.2.3.4.2. Message Specification Defined in [RFC4861]. 3.2.3.4.3. Threats 3.2.3.4.4. Operational and Interoperability Impact if Blocked 3.2.3.5. Redirect Message (Type 137) 3.2.3.5.1. Uses 3.2.3.5.2. Message Specification Defined in [RFC4861]. 3.2.3.5.3. Threats 3.2.3.5.4. Operational and Interoperability Impact if Blocked 3.2.4. Router Renumbering (Type 138) 3.2.4.1. Uses 3.2.4.2. Message Specification Defined. 3.2.4.3. Threats 3.2.4.4. Operational and Interoperability Impact if Blocked 3.2.5. IPv6 Node Information Queries 3.2.5.1. ICMP Node Information Query (Type 139) 3.2.5.1.1. Uses 3.2.5.1.2. Message Specification Defined in [RFC4620]. 3.2.5.1.3. Threats Gont, et al. Expires January 4, 2014 [Page 49]
Internet-Draft ICMP Filtering July 2013 3.2.5.1.4. Operational and Interoperability Impact if Blocked 3.2.5.2. ICMP Node Information Response (Type 140) 3.2.5.2.1. Uses 3.2.5.2.2. Message Specification Defined in [RFC4620]. 3.2.5.2.3. Threats 3.2.5.2.4. Operational and Interoperability Impact if Blocked 3.2.6. IPv6 ND Inverse Discovery 3.2.6.1. Inverse Neighbor Discovery Solicitation Message (Type 141) 3.2.6.1.1. Uses 3.2.6.1.2. Message Specification Defined in [RFC3122]. 3.2.6.1.3. Threats 3.2.6.1.4. Operational and Interoperability Impact if Blocked 3.2.6.2. Inverse Neighbor Discovery Advertisement Message (Type 142) 3.2.6.2.1. Uses 3.2.6.2.2. Message Specification Defined in [RFC3122]. 3.2.6.2.3. Threats 3.2.6.2.4. Operational and Interoperability Impact if Blocked 3.2.7. Mobility 3.2.7.1. Home Agent Address Discovery Request Message (Type 144) 3.2.7.1.1. Uses Gont, et al. Expires January 4, 2014 [Page 50]
Internet-Draft ICMP Filtering July 2013 3.2.7.1.2. Message Specification Defined in [RFC6275]. 3.2.7.1.3. Threats 3.2.7.1.4. Operational and Interoperability Impact if Blocked 3.2.7.2. Home Agent Address Discovery Reply Message (Type 145) 3.2.7.2.1. Uses 3.2.7.2.2. Message Specification Defined in [RFC6275]. 3.2.7.2.3. Threats 3.2.7.2.4. Operational and Interoperability Impact if Blocked 3.2.7.3. Mobile Prefix Solicitation (Type 146) 3.2.7.3.1. Uses 3.2.7.3.2. Message Specification Defined in [RFC6275]. 3.2.7.3.3. Threats 3.2.7.3.4. Operational and Interoperability Impact if Blocked 3.2.7.4. Mobile Prefix Advertisement (Type 147) 3.2.7.4.1. Uses 3.2.7.4.2. Message Specification Defined in [RFC6275]. 3.2.7.4.3. Threats 3.2.7.4.4. Operational and Interoperability Impact if Blocked Gont, et al. Expires January 4, 2014 [Page 51]
Internet-Draft ICMP Filtering July 2013 3.2.8. SEcure Neighbor Discovery (SEND) 3.2.8.1. Certification Path Solicitation Message (Type 148) 3.2.8.1.1. Uses 3.2.8.1.2. Message Specification Defined in [RFC3971]. 3.2.8.1.3. Threats 3.2.8.1.4. Operational and Interoperability Impact if Blocked 3.2.8.2. Certification Path Advertisement Message (Type 149) 3.2.8.2.1. Uses 3.2.8.2.2. Message Specification Defined in [RFC3971]. 3.2.8.2.3. Threats 3.2.8.2.4. Operational and Interoperability Impact if Blocked 3.2.9. ICMP messages utilized by experimental mobility protocols such as Seamoby (Type 150) 3.2.9.1. Uses 3.2.9.2. Message Specification Defined in [RFC4065]. 3.2.9.3. Threats 3.2.9.4. Operational and Interoperability Impact if Blocked 3.2.10. Multicast Router Discovery 3.2.10.1. Multicast Router Advertisement (Type 151) 3.2.10.1.1. Uses Gont, et al. Expires January 4, 2014 [Page 52]
Internet-Draft ICMP Filtering July 2013 3.2.10.1.2. Message Specification Defined in [RFC4286]. 3.2.10.1.3. Threats 3.2.10.1.4. Operational and Interoperability Impact if Blocked 3.2.10.2. Multicast Router Solicitation (Type 152) 3.2.10.2.1. Uses 3.2.10.2.2. Message Specification Defined in [RFC4286]. 3.2.10.2.3. Threats 3.2.10.2.4. Operational and Interoperability Impact if Blocked 3.2.10.3. Multicast Router Termination (Type 153) 3.2.10.3.1. Uses 3.2.10.3.2. Message Specification Defined in [RFC4286]. 3.2.10.3.3. Threats 3.2.10.3.4. Operational and Interoperability Impact if Blocked 3.2.11. FMIPv6 Messages (Type 154) 3.2.11.1. Uses 3.2.11.2. Message Specification Defined in [RFC5568]. 3.2.11.3. Threats 3.2.11.4. Operational and Interoperability Impact if Blocked Gont, et al. Expires January 4, 2014 [Page 53]
Internet-Draft ICMP Filtering July 2013 3.2.12. RPL Control Message (Type 155) 3.2.12.1. Uses 3.2.12.2. Message Specification Defined in [RFC6550]. 3.2.12.3. Threats 3.2.12.4. Operational and Interoperability Impact if Blocked 3.2.13. Private experimentation (Type 200) 3.2.13.1. Uses Used for performing controlled experiments with ICMPv6 messages before a specific ICMPv6 Type is formally assigned by IANA. 3.2.13.2. Message Specification Defined in [RFC4443]. 3.2.13.3. Threats The security implications of this message Type will depend on the specific experiment the message is being used for and whether the node this message is destined to implements the aforementioned "experiment". 3.2.13.4. Operational and Interoperability Impact if Blocked None (this message Type is meant for controlled experimentation rather than "production"). 3.2.14. Private experimentation (Type 201) 3.2.14.1. Uses Used for performing controlled experiments with ICMPv6 messages before a specific ICMPv6 Type is formally assigned by IANA. 3.2.14.2. Message Specification Defined in [RFC4443]. Gont, et al. Expires January 4, 2014 [Page 54]
Internet-Draft ICMP Filtering July 2013 3.2.14.3. Threats The security implications of this message Type will depend on the specific experiment the message is being used for and whether the node this message is destined to implements the aforementioned "experiment". 3.2.14.4. Operational and Interoperability Impact if Blocked None (this message Type is meant for controlled experimentation rather than "production"). 3.2.15. Reserved for expansion of ICMPv6 informational messages (Type 255) 3.2.15.1. Uses Type value 255 is reserved for future expansion of the type value range if there is a shortage in the future. 3.2.15.2. Message Specification Defined in [RFC4443]. 3.2.15.3. Threats None. 3.2.15.4. Operational and Interoperability Impact if Blocked It would prevent expansion of the Type value range, and hence prevent extension of the ICMPv6 protocol. 4. IANA Considerations This document has no IANA actions. 5. Security Considerations This document does not introduce any new security implications. It attempts to help mitigate security threats that rely on ICMP or ICMPv6 messages, through packet filtering and rate-limiting. Gont, et al. Expires January 4, 2014 [Page 55]
Internet-Draft ICMP Filtering July 2013 6. Acknowledgements The authors would like to thank (in alphabetical order) Steinthor Bjarnason, Alfred Hoenes, and Panos Kampanakis, for their 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. 7. References 7.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. [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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, June 2001. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Gont, et al. Expires January 4, 2014 [Page 56]
Internet-Draft ICMP Filtering July 2013 Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005. [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [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. [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information Queries", RFC 4620, August 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. 7.2. Informative References [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009. [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", RFC 6633, May 2012. [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. Gont, et al. Expires January 4, 2014 [Page 57]
Internet-Draft ICMP Filtering July 2013 [smurf] CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of- Service Attacks", http://www.cert.org/advisories/CA-1998-01.html, 1998. Authors' Addresses Fernando Gont Universidad Tecnologica Nacional / Facultad Regional Haedo Pueyrredon 76, 3A Ramos Mejia, Provincia de Buenos Aires 1704 Argentina Phone: +54 11 4650 8472 Email: fernando@gont.com.ar URI: http://www.gont.com.ar Guillermo Gont SI6 Networks Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: ggont@si6networks.com URI: http://www.si6networks.com Carlos Pignataro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US Email: cpignata@cisco.com Gont, et al. Expires January 4, 2014 [Page 58]