idnits 2.17.1 draft-gont-opsec-icmp-filtering-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1613. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 30, 2008) is 5870 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4301' is mentioned on line 233, but not defined == Unused Reference: 'RFC2026' is defined on line 1515, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-03 == Outdated reference: A later version (-09) exists of draft-ietf-tcpm-tcp-soft-errors-07 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operational Security Capabilities F. Gont 3 for IP Network Infrastructure G. Gont 4 (opsec) UTN/FRH 5 Internet-Draft March 30, 2008 6 Intended status: Informational 7 Expires: October 1, 2008 9 Recommendations for filtering ICMP messages 10 draft-gont-opsec-icmp-filtering-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 1, 2008. 37 Abstract 39 This document document provides advice on the filtering of ICMPv4 and 40 ICMPv6 messages. Additionaly, it discusses the operational and 41 interoperability implications of such filtering. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 46 2. Internet Control Message Protocol version 4 (ICMP) . . . . . . 5 47 2.1. ICMPv4 error messages . . . . . . . . . . . . . . . . . . 5 48 2.1.1. Destination Unreachable (Type 3) . . . . . . . . . . . 6 49 2.1.1.1. Net Unreachable (code 0) . . . . . . . . . . . . . 6 50 2.1.1.2. Host Unreachable (code 1) . . . . . . . . . . . . 7 51 2.1.1.3. Protocol Unreachable (code 2) . . . . . . . . . . 7 52 2.1.1.4. Port Unreachable (code 3) . . . . . . . . . . . . 8 53 2.1.1.5. Fragmentation needed and DF set (code 4) . . . . . 8 54 2.1.1.6. Source Route Failed (code 5) . . . . . . . . . . . 9 55 2.1.1.7. Destination network unknown (code 6) 56 (Deprecated) . . . . . . . . . . . . . . . . . . . 9 57 2.1.1.8. Destination host unknown (code 7) . . . . . . . . 10 58 2.1.1.9. Source host isolated (code 8) (Deprecated) . . . . 11 59 2.1.1.10. Communication with destination network 60 administratively prohibited (code 9) - 61 Deprecated . . . . . . . . . . . . . . . . . . . . 11 62 2.1.1.11. Communication with destination host 63 administratively prohibited (code 10) - 64 Deprecated . . . . . . . . . . . . . . . . . . . . 12 65 2.1.1.12. Network unreachable for type of service (code 66 11) . . . . . . . . . . . . . . . . . . . . . . . 12 67 2.1.1.13. Host unreachable for type of service (code 12) . . 13 68 2.1.1.14. Communication Administratively Prohibited 69 (code 13) . . . . . . . . . . . . . . . . . . . . 13 70 2.1.1.15. Host Precedence Violation (code 14) . . . . . . . 14 71 2.1.1.16. Precedence cutoff in effect (code 15) . . . . . . 14 72 2.1.2. Source Quench (Type 4, Code 0) . . . . . . . . . . . . 15 73 2.1.2.1. Message specification . . . . . . . . . . . . . . 15 74 2.1.2.2. Uses . . . . . . . . . . . . . . . . . . . . . . . 15 75 2.1.2.3. Threats . . . . . . . . . . . . . . . . . . . . . 16 76 2.1.2.4. Operational/interoperability impact if blocked . . 16 77 2.1.3. Redirect (Type 5) . . . . . . . . . . . . . . . . . . 16 78 2.1.3.1. Redirect datagrams for the Network (code 0) . . . 16 79 2.1.3.2. Redirect datagrams for the Host (code 1) . . . . . 16 80 2.1.3.3. Redirect datagrams for the Type of Service and 81 Network (code 2) . . . . . . . . . . . . . . . . . 17 82 2.1.3.4. Redirect datagrams for the Type of Service and 83 Host (code 3) . . . . . . . . . . . . . . . . . . 17 84 2.1.4. Time exceeded (Type 11) . . . . . . . . . . . . . . . 17 85 2.1.4.1. Time to live exceeded in transit (code 0) . . . . 17 86 2.1.4.2. fragment reassembly time exceeded (code 1) . . . . 18 87 2.1.5. Parameter Problem (Type 12) . . . . . . . . . . . . . 18 88 2.1.5.1. Pointer indicates the error (code 0) . . . . . . . 19 89 2.1.5.2. Required option is missing (code 1) . . . . . . . 19 90 2.2. ICMPv4 Informational messages . . . . . . . . . . . . . . 19 91 2.2.1. Echo or Echo Reply Message . . . . . . . . . . . . . . 19 92 2.2.1.1. Echo message (type 8, code 0) . . . . . . . . . . 19 93 2.2.1.2. Echo reply message (Type 0, code 0) . . . . . . . 20 94 2.2.2. Router Solicitation or Router Advertisement message . 21 95 2.2.2.1. Router Solicitation message (type 10, code 0) . . 21 96 2.2.2.2. Router Advertisement message (type 9, code 0) . . 22 97 2.2.3. Timestamp or Timestamp Reply Message . . . . . . . . . 22 98 2.2.3.1. Timestamp message (type 13, code 0) . . . . . . . 22 99 2.2.3.2. Timestamp reply message (type 14, code 0) . . . . 23 100 2.2.4. Information Request or Information Reply Message 101 (Deprecated) . . . . . . . . . . . . . . . . . . . . . 23 102 2.2.4.1. Information request message (type 15, code 0) . . 23 103 2.2.4.2. Information reply message (type 16, code 0) . . . 24 104 2.2.5. Address Mask Request or Address Mask Reply . . . . . . 24 105 2.2.5.1. Address Mask Request (type 17, code 0) . . . . . . 24 106 2.2.5.2. Address Mask Reply (type 18, code 0) . . . . . . . 25 107 3. Internet Control Message Protocol version 6 (ICMPv6) . . . . . 25 108 3.1. ICMPv6 error messages . . . . . . . . . . . . . . . . . . 25 109 3.1.1. Destination Unreachable (Type 1) . . . . . . . . . . . 25 110 3.1.1.1. No route to destination (code 0) . . . . . . . . . 25 111 3.1.1.2. Communication with destination 112 administratively prohibited (code 1) . . . . . . . 26 113 3.1.1.3. Beyond scope of source address (code 2) . . . . . 26 114 3.1.1.4. Address unreachable (code 3) . . . . . . . . . . . 27 115 3.1.1.5. Port unreachable (code 4) . . . . . . . . . . . . 27 116 3.1.1.6. Source address failed ingress/egress policy 117 (code 5) . . . . . . . . . . . . . . . . . . . . . 27 118 3.1.1.7. Reject route to destination (code 6) . . . . . . . 28 119 3.1.2. Packet Too Big Message (Type 2, code 0) . . . . . . . 28 120 3.1.2.1. Message specification . . . . . . . . . . . . . . 28 121 3.1.2.2. Uses . . . . . . . . . . . . . . . . . . . . . . . 28 122 3.1.2.3. Threats . . . . . . . . . . . . . . . . . . . . . 28 123 3.1.2.4. Operational/interoperability impact if blocked . . 28 124 3.1.3. Time Exceeded Message (Type 3) . . . . . . . . . . . . 29 125 3.1.3.1. Hop limit exceeded in transit (code 0) . . . . . . 29 126 3.1.3.2. Fragment reassembly time exceeded (code 1) . . . . 29 127 3.1.4. Parameter Problem Message (Type 4) . . . . . . . . . . 29 128 3.1.4.1. Erroneous header field encountered (code 0) . . . 29 129 3.1.4.2. Unrecognized Next Header type encountered 130 (code 1) . . . . . . . . . . . . . . . . . . . . . 30 131 3.1.4.3. Unrecognized IPv6 option encountered (code 2) . . 30 132 3.1.5. Private experimentation (Type 100) . . . . . . . . . . 30 133 3.1.5.1. Message specification . . . . . . . . . . . . . . 30 134 3.1.5.2. Uses . . . . . . . . . . . . . . . . . . . . . . . 31 135 3.1.5.3. Threats . . . . . . . . . . . . . . . . . . . . . 31 136 3.1.5.4. Operational/interoperability impact if blocked . . 31 137 3.1.6. Private experimentation (Type 101) . . . . . . . . . . 31 138 3.1.6.1. Message specification . . . . . . . . . . . . . . 31 139 3.1.6.2. Uses . . . . . . . . . . . . . . . . . . . . . . . 31 140 3.1.6.3. Threats . . . . . . . . . . . . . . . . . . . . . 31 141 3.1.6.4. Operational/interoperability impact if blocked . . 31 142 3.1.7. Reserved for expansion of ICMPv6 error messages 143 (Type 127) . . . . . . . . . . . . . . . . . . . . . . 31 144 3.1.7.1. Message specification . . . . . . . . . . . . . . 31 145 3.1.7.2. Uses . . . . . . . . . . . . . . . . . . . . . . . 31 146 3.1.7.3. Threats . . . . . . . . . . . . . . . . . . . . . 31 147 3.1.7.4. Operational/interoperability impact if blocked . . 31 148 3.2. ICMPv6 Informational messages . . . . . . . . . . . . . . 31 149 3.2.1. Echo Request or Echo Reply Message . . . . . . . . . . 31 150 3.2.1.1. Echo Request message (type 128, code 0) . . . . . 31 151 3.2.1.2. Echo reply message (Type 129, code 0) . . . . . . 32 152 3.2.2. Private experimentation (Type 200) . . . . . . . . . . 32 153 3.2.2.1. Message specification . . . . . . . . . . . . . . 32 154 3.2.2.2. Uses . . . . . . . . . . . . . . . . . . . . . . . 32 155 3.2.2.3. Threats . . . . . . . . . . . . . . . . . . . . . 32 156 3.2.2.4. Operational/interoperability impact if blocked . . 32 157 3.2.3. Private experimentation (Type 201) . . . . . . . . . . 32 158 3.2.3.1. Message specification . . . . . . . . . . . . . . 32 159 3.2.3.2. Uses . . . . . . . . . . . . . . . . . . . . . . . 32 160 3.2.3.3. Threats . . . . . . . . . . . . . . . . . . . . . 33 161 3.2.3.4. Operational/interoperability impact if blocked . . 33 162 3.2.4. Reserved for expansion of ICMPv6 informational 163 messages (Type 255) . . . . . . . . . . . . . . . . . 33 164 3.2.4.1. Message specification . . . . . . . . . . . . . . 33 165 3.2.4.2. Uses . . . . . . . . . . . . . . . . . . . . . . . 33 166 3.2.4.3. Threats . . . . . . . . . . . . . . . . . . . . . 33 167 3.2.4.4. Operational/interoperability impact if blocked . . 33 168 4. Security Considerations . . . . . . . . . . . . . . . . . . . 33 169 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 170 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 171 6.1. Normative References . . . . . . . . . . . . . . . . . . . 33 172 6.2. Informative References . . . . . . . . . . . . . . . . . . 34 173 Appendix A. Change log (to be removed before publication of 174 the document as an RFC) . . . . . . . . . . . . . . . 34 175 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 176 Intellectual Property and Copyright Statements . . . . . . . . . . 36 178 1. Introduction 180 This document document provides advice on the filtering of ICMPv4 and 181 ICMPv6 messages. Additionaly, it discusses the operational and 182 interoperability implications of such filtering. 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [RFC2119]. 188 2. Internet Control Message Protocol version 4 (ICMP) 190 2.1. ICMPv4 error messages 192 [RFC0792] is the base specification for the Internet Control Message 193 Protocol (ICMP) to be used with the Internet Protocol version 4 194 (IPv4). It defines, among other things, a number of error messages 195 that can be used by end-systems and intermediate systems to report 196 errors to the sending system. The Host Requirements RFC [RFC1122] 197 classifies ICMP error messages into those that indicate "soft 198 errors", and those that indicate "hard errors", thus roughly defining 199 the semantics of them. 201 Section 3.2.2.1 of [RFC1122] specifies the amount of information to 202 be included in the payload of an ICMP error message, and how ICMP 203 error messages should be demultiplexed to the corresponding transport 204 protocol instance. Additionally, it imposes details some scenarios 205 in which ICMP errors should not be generated. 207 Section 4.1.3.3 of [RFC1122] states that UDP MUST pass to the 208 application layer all ICMP error messages that it receives from the 209 IP layer. 211 Section 4.2.3.9 of [RFC1122] states that TCP MUST act on an ICMP 212 error message passed up from the IP layer, directing it to the 213 connection that created the error. 215 Section 4.3.2 of [RFC1812] contains a number of requirements for the 216 generation and processing of ICMP error messages, including: 217 initialization of the TTL of the error message, the amount of data 218 from the offending packet to be included in the ICMP payload, setting 219 the IP Source Address of ICMP error messages, setting of the TOS and 220 Precedence, processing of IP Source Route option in offending 221 packets, scenarios in which routers MUST NOT send ICMP error 222 messages, and application of rate-limiting to ICMP error messages. 224 The ICMP specification [RFC0792] also defines the ICMP Source Quench 225 message (type 4, code 0), which is meant to provide a mechanism for 226 flow control and congestion control. 228 [RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD), 229 which makes use of ICMP error messages of type 3 (Destination 230 Unreachable), code 4 (fragmentation needed and DF bit set) to allow 231 systems to determine the MTU of an arbitrary internet path. 233 Appendix D of [RFC4301] provides information about which ICMP error 234 messages are produced by hosts, intermediate routers, or both. 236 2.1.1. Destination Unreachable (Type 3) 238 The ICMP Destination Unreachable message is sent by a router in 239 response to a packet which it cannot forward because the destination 240 (or next hop) is unreachable or a service is unavailable. Examples 241 of such cases include a message addressed to a host which is not 242 there and therefore does not respond to ARP requests, and messages 243 addressed to network prefixes for which the router has no valid 244 route. [RFC1812] states that a router MUST be able to generate ICMP 245 Destination Unreachable messages and SHOULD choose a response code 246 that most closely matches the reason the message is being generated. 247 Section 3.2.2.1 of [RFC1122] states that a Destination Unreachable 248 message that is received MUST be reported to the transport layer, and 249 that the transport layer SHOULD use the information appropriately. 251 2.1.1.1. Net Unreachable (code 0) 253 2.1.1.1.1. Message specification 255 Defined in [RFC0792]. Section 4.3.3.1 of [RFC1812] states that if a 256 router cannot forward a packet because it has no routes at all 257 (including no default route) to the destination specified in the 258 packet, then the router MUST generate a Destination Unreachable, Code 259 0 (Network Unreachable) ICMP message. Section 3.2.2.1 of [RFC1122] 260 states that this message may result from a routing transient, and 261 MUST therefore be interpreted as only a hint, not proof, that the 262 specified destination is unreachable. For example, it MUST NOT be 263 used as proof of a dead gateway. Section 4.2.3.9 of [RFC1122] states 264 that this message indicates a soft error, and therefore TCP MUST NOT 265 abort the connection, and SHOULD make the information available to 266 the application. 268 2.1.1.1.2. Uses 269 2.1.1.1.3. Threats 271 2.1.1.1.4. Operational/interoperability impact if blocked 273 May lead to long delays between connection establishment attempts 274 that could have been avoided by those systems aborting non- 275 synchronized connections in response to ICMP soft errors 276 [I-D.ietf-tcpm-tcp-soft-errors]. 278 2.1.1.2. Host Unreachable (code 1) 280 2.1.1.2.1. Message specification 282 Defined in [RFC0792]. Section 3.2.2.1 of [RFC1122] states that his 283 message may result from a routing transient, and MUST therefore be 284 interpreted as only a hint, not proof, that the specified destination 285 is unreachable. For example, it MUST NOT be used as proof of a dead 286 gateway. Section 4.2.3.9 of [RFC1122] states that this message 287 indicates a soft error, and therefore TCP MUST NOT abort the 288 connection, and SHOULD make the information available to the 289 application. 291 2.1.1.2.2. Uses 293 2.1.1.2.3. Threats 295 2.1.1.2.4. Operational/interoperability impact if blocked 297 May lead to long delays between connection establishment attempts 298 that could have been avoided by those systems aborting non- 299 synchronized connections in response to ICMP soft errors 300 [I-D.ietf-tcpm-tcp-soft-errors]. 302 2.1.1.3. Protocol Unreachable (code 2) 304 2.1.1.3.1. Message specification 306 Defined in [RFC0792]. [RFC1122] states that a host SHOULD send a 307 protocol unreachable when the designated transport protocol is not 308 supported. Section 4.2.3.9 of [RFC1122] states that this message 309 indicates a hard error condition, so TCP SHOULD abort the connection. 311 2.1.1.3.2. Uses 312 2.1.1.3.3. Threats 314 2.1.1.3.4. Operational/interoperability impact if blocked 316 May lead to long delays between connection establishment attempts 317 that could have been avoided by those systems aborting non- 318 synchronized connections in response to ICMP soft errors 319 [I-D.ietf-tcpm-tcp-soft-errors]. 321 2.1.1.4. Port Unreachable (code 3) 323 2.1.1.4.1. Message specification 325 Defined in [RFC0792]. Section 3.2.2.1 of [RFC1122] states that a 326 host SHOULD send an ICMP port unreachable when the designated 327 transport protocol (e.g., UDP) is unable to demultiplex the datagram 328 but has no protocol mechanism to inform the sender. Additionally, it 329 states that a transport protocol that has its own mechanism for 330 notifying the sender that a port is unreachable MUST nevertheless 331 accept an ICMP Port Unreachable for the same purpose. 333 Section 4.2.3.9 of [RFC1122] states that this message indicates a 334 hard error condition, so TCP SHOULD abort the connection. 336 2.1.1.4.2. Uses 338 2.1.1.4.3. Threats 340 2.1.1.4.4. Operational/interoperability impact if blocked 342 May lead to long delays between connection establishment attempts or 343 long response times that could have been avoided by aborting non- 344 synchronized connections in response to ICMP soft errors 345 [I-D.ietf-tcpm-tcp-soft-errors]. 347 2.1.1.5. Fragmentation needed and DF set (code 4) 349 2.1.1.5.1. Message specification 351 Defined in [RFC0792] 353 2.1.1.5.2. Uses 355 Used for the Path-MTU Discovery mechanism described in [RFC1191]. 357 2.1.1.5.3. Threats 359 This error message can be used to perform Denial of Service (DoS) 360 attacks against transport protocols. [I-D.ietf-tcpm-icmp-attacks] 361 describes the use of this error message to attack TCP connections. 363 2.1.1.5.4. Operational/interoperability impact if blocked 365 Filtering this error message breaks the Path-MTU Discovery mechansim 366 described in [RFC1191]. 368 2.1.1.6. Source Route Failed (code 5) 370 2.1.1.6.1. Message specification 372 Defined in [RFC0792]. Section 3.2.2.1 of [RFC1122] states that his 373 message may result from a routing transient, and MUST therefore be 374 interpreted as only a hint, not proof, that the specified destination 375 is unreachable. For example, it MUST NOT be used as proof of a dead 376 gateway. Section 4.2.3.9 of [RFC1122] states that this message 377 indicates a soft error, and therefore TCP MUST NOT abort the 378 connection, and SHOULD make the information available to the 379 application. 381 Section 4.2.3.9 of [RFC1122] states that this message indicates a 382 hard error condition, so TCP SHOULD abort the connection. 384 2.1.1.6.2. Uses 386 Signals errors araising from IPv4 source routes. 388 2.1.1.6.3. Threats 390 There shouldn't be any security threats araising from the use of this 391 error message. 393 2.1.1.6.4. Operational/interoperability impact if blocked 395 May lead to long delays between connection establishment attempts or 396 long response times that could have been avoided by aborting non- 397 synchronized connections in response to ICMP soft errors 398 [I-D.ietf-tcpm-tcp-soft-errors]. 400 2.1.1.7. Destination network unknown (code 6) (Deprecated) 401 2.1.1.7.1. Message specification 403 Defined in [RFC1122]. [RFC1812] states that this code SHOULD NOT be 404 generated since it would imply on the part of the router that the 405 destination network does not exist (net unreachable code 0 SHOULD be 406 used in place of code 6). 408 2.1.1.7.2. Uses 410 Signal unreachability condition to the sending system. 412 2.1.1.7.3. Threats 414 There shouldn't be any security threats araising from the use of this 415 error message. 417 2.1.1.7.4. Operational/interoperability impact if blocked 419 May lead to long delays between connection establishment attempts or 420 long response times that could have been avoided by aborting non- 421 synchronized connections in response to ICMP soft errors 422 [I-D.ietf-tcpm-tcp-soft-errors]. 424 2.1.1.8. Destination host unknown (code 7) 426 2.1.1.8.1. Message specification 428 Defined in [RFC1122], and is generated only when a router can 429 determine (from link layer advice) that the destination host does not 430 exist 432 2.1.1.8.2. Uses 434 Signal unreachability condition to the sending system. 436 2.1.1.8.3. Threats 438 There shouldn't be any security threats araising from the use of this 439 error message. 441 2.1.1.8.4. Operational/interoperability impact if blocked 443 May lead to long delays between connection establishment attempts or 444 long response times that could have been avoided by aborting non- 445 synchronized connections in response to ICMP soft errors 446 [I-D.ietf-tcpm-tcp-soft-errors]. 448 2.1.1.9. Source host isolated (code 8) (Deprecated) 450 2.1.1.9.1. Message specification 452 Defined in [RFC1122]. [RFC1812] states that routers SHOULD NOT 453 generate this error message, and states that whichever of Codes 0 454 (Network Unreachable) and 1 (Host Unreachable) is appropriate SHOULD 455 be used instead. 457 2.1.1.9.2. Uses 459 Signal unreachability condition to the sending system. 461 2.1.1.9.3. Threats 463 There shouldn't be any security threats araising from the use of this 464 error message. 466 2.1.1.9.4. Operational/interoperability impact if blocked 468 May lead to long delays between connection establishment attempts or 469 long response times that could have been avoided by aborting non- 470 synchronized connections in response to ICMP soft errors 471 [I-D.ietf-tcpm-tcp-soft-errors]. However, this error message is 472 deprecated, and thus system should not depend on it for any purpose. 474 2.1.1.10. Communication with destination network administratively 475 prohibited (code 9) - Deprecated 477 2.1.1.10.1. Message specification 479 This error code is defined in [RFC1122], and was intended for use by 480 end-to-end encryption devices used by U.S military agencies. 481 [RFC1812] deprecates its use, stating that routers SHOULD use the 482 Code 13 (Communication Administratively Prohibited) if they 483 administratively filter packets. 485 2.1.1.10.2. Uses 487 Signal unreachability condition to the sending system. 489 2.1.1.10.3. Threats 491 May reveal filtering policies. 493 2.1.1.10.4. Operational/interoperability impact if blocked 495 May lead to long delays between connection establishment attempts or 496 long response times that could have been avoided by aborting non- 497 synchronized connections in response to ICMP soft errors 498 [I-D.ietf-tcpm-tcp-soft-errors]. However, this error message is 499 deprecated, and thus system should not depend on it for any purpose. 501 2.1.1.11. Communication with destination host administratively 502 prohibited (code 10) - Deprecated 504 2.1.1.11.1. Message specification 506 This error code is defined in [RFC1122], and was intended for use by 507 end-to-end encryption devices used by U.S military agencies. 508 [RFC1812] deprecates its use, stating that routers SHOULD use the 509 Code 13 (Communication Administratively Prohibited) if they 510 administratively filter packets. 512 2.1.1.11.2. Uses 514 Signal unreachability condition to the sending system. 516 2.1.1.11.3. Threats 518 May reveal filtering policies. 520 2.1.1.11.4. Operational/interoperability impact if blocked 522 May lead to long delays between connection establishment attempts or 523 long response times that could have been avoided by aborting non- 524 synchronized connections in response to ICMP soft errors 525 [I-D.ietf-tcpm-tcp-soft-errors]. However, this error message is 526 deprecated, and thus system should not depend on it for any purpose. 528 2.1.1.12. Network unreachable for type of service (code 11) 530 2.1.1.12.1. Message specification 532 Defined in [RFC1122]. Section 4.3.3.1 of [RFC1812] states that if a 533 router cannot forward a packet because the TOS specified for the 534 routes is neither the default TOS (0000) nor the TOS of the packet 535 that the router is attempting to route, then the router MUST generate 536 a Destination Unreachable, Code 11 (Network Unreachable for TOS) ICMP 537 message. 539 2.1.1.12.2. Uses 541 Signal unreachability condition to the sending system. 543 2.1.1.12.3. Threats 545 May reveal routing policies. 547 2.1.1.12.4. Operational/interoperability impact if blocked 549 May lead to long delays between connection establishment attempts or 550 long response times that could have been avoided by aborting non- 551 synchronized connections in response to ICMP soft errors 552 [I-D.ietf-tcpm-tcp-soft-errors]. 554 2.1.1.13. Host unreachable for type of service (code 12) 556 2.1.1.13.1. Message specification 558 Defined in [RFC1122]. Section 4.3.3.1 of [RFC1812] states that this 559 message is sent if a packet is to be forwarded to a host that is on a 560 network that is directly connected to the router and the router 561 cannot forward the packet because no route to the destination has a 562 TOS that is either equal to the TOS requested in the packet or is the 563 default TOS (0000). 565 2.1.1.13.2. Uses 567 Signal unreachability condition to the sending system. 569 2.1.1.13.3. Threats 571 May reveal routing policies. 573 2.1.1.13.4. Operational/interoperability impact if blocked 575 May lead to long delays between connection establishment attempts or 576 long response times that could have been avoided by aborting non- 577 synchronized connections in response to ICMP soft errors 578 [I-D.ietf-tcpm-tcp-soft-errors]. 580 2.1.1.14. Communication Administratively Prohibited (code 13) 582 2.1.1.14.1. Message specification 584 Defined in [RFC1812], and is generated if a router cannot forward a 585 packet due to administrative filtering. 587 2.1.1.14.2. Uses 589 Signal unreachability condition (due to filtering policies) to the 590 sending system. 592 2.1.1.14.3. Threats 594 Given that the semantics of this error message are not accurately 595 specified, some systems might abort transport connections upon 596 receipt of this error message. [I-D.ietf-tcpm-icmp-attacks]. 598 2.1.1.14.4. Operational/interoperability impact if blocked 600 May lead to long delays between connection establishment attempts or 601 long response times that could have been avoided by aborting non- 602 synchronized connections in response to ICMP soft errors 603 [I-D.ietf-tcpm-tcp-soft-errors]. 605 2.1.1.15. Host Precedence Violation (code 14) 607 2.1.1.15.1. Message specification 609 Defined in [RFC1812], and is sent by the first hop router to a host 610 to indicate that a requested precedence is not permitted for the 611 particular combination of source/destination host or network, upper 612 layer protocol, and source/destination port 614 2.1.1.15.2. Uses 616 Signal unreachability condition to the sending system. 618 2.1.1.15.3. Threats 620 May reveal routing policies. 622 2.1.1.15.4. Operational/interoperability impact if blocked 624 May lead to long delays between connection establishment attempts or 625 long response times that could have been avoided by aborting non- 626 synchronized connections in response to ICMP soft errors 627 [I-D.ietf-tcpm-tcp-soft-errors]. 629 2.1.1.16. Precedence cutoff in effect (code 15) 631 2.1.1.16.1. Message specification 633 Defined in [RFC1812], and is sent when the network operators have 634 imposed a minimum level of precedence required for operation, and a 635 datagram was sent with a precedence below this level. 637 2.1.1.16.2. Uses 639 2.1.1.16.3. Threats 641 2.1.1.16.4. Operational/interoperability impact if blocked 643 May lead to long delays between connection establishment attempts or 644 long response times that could have been avoided by aborting non- 645 synchronized connections in response to ICMP soft errors 646 [I-D.ietf-tcpm-tcp-soft-errors]. 648 2.1.2. Source Quench (Type 4, Code 0) 650 2.1.2.1. Message specification 652 The Source Quench message is defined in [RFC0792]. 654 Section 3.2.2.3 of [RFC1122] states that host MAY send a Source 655 Quench message if it is approaching, or has reached, the point at 656 which it is forced to discard incoming datagrams due to a shortage of 657 reassembly buffers or other resources. It also states that if a 658 Source Quench message is received, the IP layer MUST pass it to the 659 tansport layer, which SHOULD implement a mechanism for responding to 660 ICMP Source Quench messages. 662 Section 4.2.3.9 of the Host Requirements RFC [RFC1122] states that 663 TCP MUST react to ICMP Source Quench messages by slowing transmission 664 on the connection, and further further adds that the RECOMMENDED 665 procedure is to put the corresponding connection in the slow-start 666 phase of TCP's congestion control algorithm [RFC2581]. 668 Section 4.3.3.3 of the Requirements for IP Version 4 Routers RFC 669 [RFC1812] notes that research seems to suggest that ICMP Source 670 Quench is an ineffective (and unfair) antidote for congestion, and 671 states that routers SHOULD NOT send ICMP Source Quench messages in 672 response to congestion. A router that does originate Source Quench 673 messages MUST be able to limit the rate at which they are generated. 674 Finally, Section 4.3.3.3 of [RFC1812] states that a router MAY ignore 675 any ICMP Source Quench messages it receives. 677 2.1.2.2. Uses 678 2.1.2.3. Threats 680 2.1.2.4. Operational/interoperability impact if blocked 682 2.1.3. Redirect (Type 5) 684 Section 3.2.2.2 of [RFC1122] states that SHOULD NOT send an ICMP 685 Redirect message, and that a host receiving a Redirect message MUST 686 update its routing information accordingly, and process the ICMP 687 redirect according to the rules stated in Section 3.3.1.2 of 688 [RFC1122]. ICMP redirects that specify a a gateway that is not on 689 the same connected (sub-) net through which the Redirect arrived, or 690 that are received from a source other than the first-hop gateway 691 SHOULD be silently disacarded. 693 Section 4.3.3.2 of [RFC1812] states that a router MAY ignore ICMP 694 Redirects when choosing a path for a packet originated by the router 695 if the router is running a routing protocol or if forwarding is 696 enabled on the router and on the interface over which the packet is 697 being sent. 699 2.1.3.1. Redirect datagrams for the Network (code 0) 701 2.1.3.1.1. Message specification 703 Defined in [RFC0792]. 705 2.1.3.1.2. Uses 707 2.1.3.1.3. Threats 709 2.1.3.1.4. Operational/interoperability impact if blocked 711 2.1.3.2. Redirect datagrams for the Host (code 1) 713 2.1.3.2.1. Message specification 715 Defined in [RFC0792]. 717 2.1.3.2.2. Uses 719 2.1.3.2.3. Threats 721 2.1.3.2.4. Operational/interoperability impact if blocked 722 2.1.3.3. Redirect datagrams for the Type of Service and Network (code 723 2) 725 2.1.3.3.1. Message specification 727 Defined in [RFC0792]. 729 2.1.3.3.2. Uses 731 2.1.3.3.3. Threats 733 2.1.3.3.4. Operational/interoperability impact if blocked 735 2.1.3.4. Redirect datagrams for the Type of Service and Host (code 3) 737 2.1.3.4.1. Message specification 739 Defined in [RFC0792]. 741 2.1.3.4.2. Uses 743 2.1.3.4.3. Threats 745 2.1.3.4.4. Operational/interoperability impact if blocked 747 2.1.4. Time exceeded (Type 11) 749 Section 3.2.2.4 of [RFC1122] states that an incoming Time Exceeded 750 message MUST be passed to the transport layer. 752 Section 4.3.3.4 of [RFC1812] states that when the router receives 753 (i.e., is destined for the router) a Time Exceeded message, it MUST 754 comply with [RFC1122]. 756 2.1.4.1. Time to live exceeded in transit (code 0) 758 2.1.4.1.1. Message specification 760 Defined in [RFC0792]. 762 [RFC1812] states that a router MUST generate a Time Exceeded message 763 Code 0 (In Transit) when it discards a packet due to an expired TTL 764 field. Section 4.2.3.9 of [RFC1122] states that this message should 765 be handled by TCP in the same way as Destination Unreachable codes 0, 766 1, 5. 768 2.1.4.1.2. Uses 770 Used for the traceroute troubleshooting tool. Signals unreachability 771 condition due to routing loops. 773 2.1.4.1.3. Threats 775 Can be used for network mapping. 777 2.1.4.1.4. Operational/interoperability impact if blocked 779 Breaks the traceroute tool. May lead to long delays between 780 connection establishment attempts or long response times that could 781 have been avoided by aborting non-synchronized connections in 782 response to ICMP soft errors [I-D.ietf-tcpm-tcp-soft-errors]. 784 2.1.4.2. fragment reassembly time exceeded (code 1) 786 2.1.4.2.1. Message specification 788 Defined in [RFC0792]. [RFC0792] states this message may be sent by a 789 host reassembling a fragmented datagram if it cannot complete the 790 reassembly due to missing fragments within its time limit. Section 791 4.2.3.9 of [RFC1122] states that this message should be handled by 792 TCP in the same way as Destination Unreachable codes 0, 1, 5. 794 2.1.4.2.2. Uses 796 Signals fragment reassembly timeout. 798 2.1.4.2.3. Threats 800 May reveal the timeout value used by a system for fragment 801 reassembly. 803 2.1.4.2.4. Operational/interoperability impact if blocked 805 May lead to long delays between connection establishment attempts or 806 long response times that could have been avoided by aborting non- 807 synchronized connections in response to ICMP soft errors 808 [I-D.ietf-tcpm-tcp-soft-errors]. 810 2.1.5. Parameter Problem (Type 12) 812 Section 3.2.2.5 of [RFC1122] states that a host SHOULD generate 813 Parameter Problem messages. An incoming Parameter Problem message 814 MUST be passed to the transport layer, and it MAY be reported to the 815 user. Section 4.2.3.9 of [RFC1122] states that this message should 816 be handled by TCP in the same way as Destination Unreachable codes 0, 817 1, 5. 819 Section 4.3.3.5 of [RFC1812] states that a router MUST generate a 820 Parameter Problem message for any error not specifically covered by 821 another ICMP message. The IP header field or IP option including the 822 byte indicated by the pointer field MUST be included unchanged in the 823 IP header returned with this ICMP message. Section 4.3.2 of the same 824 document defines an exception to this rule. 826 2.1.5.1. Pointer indicates the error (code 0) 828 2.1.5.1.1. Message specification 830 Defined in [RFC0792]. 832 2.1.5.1.2. Uses 834 2.1.5.1.3. Threats 836 2.1.5.1.4. Operational/interoperability impact if blocked 838 2.1.5.2. Required option is missing (code 1) 840 2.1.5.2.1. Message specification 842 Defined in Section 3.2.2.5 of [RFC1122]. It was meant to be used in 843 the military community for a missing security option. 845 2.1.5.2.2. Uses 847 2.1.5.2.3. Threats 849 2.1.5.2.4. Operational/interoperability impact if blocked 851 2.2. ICMPv4 Informational messages 853 2.2.1. Echo or Echo Reply Message 855 2.2.1.1. Echo message (type 8, code 0) 857 2.2.1.1.1. Message specification 859 Defined in [RFC0792]. 861 Section 3.2.2.6 of [RFC1122] states that every host MUST implement an 862 ICMP Echo server function that receives Echo Requests and sends 863 corresponding Echo Replies. A host SHOULD also implement an 864 application-layer interface for sending an Echo Request and receiving 865 an Echo Reply, for diagnostic purposes. Section 3.2.2.6 of [RFC1122] 866 includes a number of requirements for the processing of ICMP Echo 867 messages and the generation of the corresponding replies. 869 Section 4.3.3.6 of [RFC1812] contains a number of requirements with 870 respect to the generation and processing of ICMP Echo or Echo Reply 871 messsages, including: maximum ICMP message size all routers are 872 required to receive, a number of factors that may determine whether a 873 router responds (or not) to an ICMP Echo message, the implementation 874 of a user/application-layer interface, and the processing of Record 875 Route, Timestamp and/or Source Route options that might be present in 876 an ICMP Echo message. 878 2.2.1.1.2. Uses 880 Used by the ping troubleshooting tool. 882 2.2.1.1.3. Threats 884 Can be used for network mapping [icmp-scanning]. Has been exploited 885 to perform Smurf attacks [smurf]. 887 2.2.1.1.4. Operational/interoperability impact if blocked 889 Filtering this error message will break the ping tool. The best 890 current practice is to rate-limit this ICMP message. 892 2.2.1.2. Echo reply message (Type 0, code 0) 894 2.2.1.2.1. Message specification 896 Defined in [RFC0792]. 898 Section 3.2.2.6 of [RFC1122] states that every host MUST implement an 899 ICMP Echo server function that receives Echo Requests and sends 900 corresponding Echo Replies. A host SHOULD also implement an 901 application-layer interface for sending an Echo Request and receiving 902 an Echo Reply, for diagnostic purposes. Section 3.2.2.6 of [RFC1122] 903 includes a number of requirements for the processing of ICMP Echo 904 messages and the generation of the corresponding replies. 906 Section 4.3.3.6 of [RFC1812] contains a number of requirements with 907 respect to the generation and processing of ICMP Echo or Echo Reply 908 messsages, including: maximum ICMP message size all routers are 909 required to receive, a number of factors that may determine whether a 910 router responds (or not) to an ICMP Echo message, the implementation 911 of a user/application-layer interface, and the processing of Record 912 Route, Timestamp and/or Source Route options that might be present in 913 an ICMP Echo message. 915 2.2.1.2.2. Uses 917 Used by the ping troubleshooting tool. 919 2.2.1.2.3. Threats 921 Can be used for network mapping [icmp-scanning]. Has been exploited 922 to perform Smurf attacks [smurf]. 924 2.2.1.2.4. Operational/interoperability impact if blocked 926 Filtering this error message will break the ping tool. The best 927 current practice is to rate-limit this ICMP message. 929 2.2.2. Router Solicitation or Router Advertisement message 931 2.2.2.1. Router Solicitation message (type 10, code 0) 933 2.2.2.1.1. Message specification 935 Defined in [RFC1256] 937 Section 4.3.3.10 of [RFC1812] states that an IP router MUST support 938 the router part of the ICMP Router Discovery Protocol on all 939 connected networks on which the router supports either IP multicast 940 or IP broadcast addressing. The implementation MUST include all the 941 configuration variables specified for routers, with the specified 942 defaults. 944 2.2.2.1.2. Uses 946 Used by some systems as form of stateless autoconfiguration, to 947 solicit routers on a network segment. 949 2.2.2.1.3. Threats 951 Can be used for network mapping (e.g., learning about routers on a 952 network segment.). 954 2.2.2.1.4. Operational/interoperability impact if blocked 956 This mesages should ot be routed. Therefore, there is no 957 operational/interoperability impact if blocked. 959 2.2.2.2. Router Advertisement message (type 9, code 0) 961 2.2.2.2.1. Message specification 963 Defined in [RFC1256] 965 Section 4.3.3.10 of [RFC1812] states that an IP router MUST support 966 the router part of the ICMP Router Discovery Protocol on all 967 connected networks on which the router supports either IP multicast 968 or IP broadcast addressing. The implementation MUST include all the 969 configuration variables specified for routers, with the specified 970 defaults. 972 2.2.2.2.2. Uses 974 Used to advertise routers on a network segment. 976 2.2.2.2.3. Threats 978 Can be spoofed by an attacker to direct all traffic sent on a network 979 segment to itself. 981 2.2.2.2.4. Operational/interoperability impact if blocked 983 This mesages should ot be routed. Therefore, there is no 984 operational/interoperability impact if blocked. 986 2.2.3. Timestamp or Timestamp Reply Message 988 2.2.3.1. Timestamp message (type 13, code 0) 990 2.2.3.1.1. Message specification 992 Defined in [RFC0792]. 994 Section 3.2.2.8 of [RFC1122] states that a host MAY implement 995 Timestamp and Timestamp Reply. For hosts that implement these 996 messages, a number of requirements are stated. 998 2.2.3.1.2. Uses 1000 2.2.3.1.3. Threats 1002 Can be used for network mapping, and device fingerprinting. 1004 2.2.3.1.4. Operational/interoperability impact if blocked 1006 None. 1008 2.2.3.2. Timestamp reply message (type 14, code 0) 1010 2.2.3.2.1. Message specification 1012 Defined in [RFC0792]. 1014 2.2.3.2.2. Uses 1016 2.2.3.2.3. Threats 1018 Can be used for network mapping, and device fingerprinting. 1020 2.2.3.2.4. Operational/interoperability impact if blocked 1022 None. 1024 2.2.4. Information Request or Information Reply Message (Deprecated) 1026 These messages are described in [RFC0792] as "a way for a host to 1027 find out the number of the network it is on". Section 3.2.2.7 of 1028 [RFC1122] and Section 4.3.3.7 of [RFC1812] deprecate the use of these 1029 messages. 1031 2.2.4.1. Information request message (type 15, code 0) 1033 2.2.4.1.1. Message specification 1035 Defined in [RFC0792]. 1037 These messages are described in [RFC0792] as "a way for a host to 1038 find out the number of the network it is on". Section 3.2.2.7 of 1039 [RFC1122] and Section 4.3.3.7 of [RFC1812] deprecate the use of these 1040 messages. 1042 2.2.4.1.2. Uses 1044 2.2.4.1.3. Threats 1046 2.2.4.1.4. Operational/interoperability impact if blocked 1047 2.2.4.2. Information reply message (type 16, code 0) 1049 2.2.4.2.1. Message specification 1051 Defined in [RFC0792]. 1053 These messages are described in [RFC0792] as "a way for a host to 1054 find out the number of the network it is on". Section 3.2.2.7 of 1055 [RFC1122] and Section 4.3.3.7 of [RFC1812] deprecate the use of these 1056 messages. 1058 2.2.4.2.2. Uses 1060 2.2.4.2.3. Threats 1062 2.2.4.2.4. Operational/interoperability impact if blocked 1064 2.2.5. Address Mask Request or Address Mask Reply 1066 2.2.5.1. Address Mask Request (type 17, code 0) 1068 2.2.5.1.1. Message specification 1070 Defined in RFC0950. Section 3.2.2.9 of [RFC1122] includes a number 1071 of requirements regarding the generation and processing of this 1072 message. 1074 Section 3.2.2.9 of [RFC1122] states that a host MAY implement sending 1075 ICMP Address Mask Request(s) and receiving ICMP Address Mask 1076 Reply(s). Section 4.3.3.9 of [RFC1812] states that a router MUST 1077 implement support for receiving ICMP Address Mask Request messages 1078 and responding with ICMP Address Mask Reply messages. 1080 2.2.5.1.2. Uses 1082 Was originally defined as a means for system stateless 1083 autoconfiguration. 1085 2.2.5.1.3. Threats 1087 Can be used for network mapping, and OS fingerprinting. 1089 2.2.5.1.4. Operational/interoperability impact if blocked 1091 None. 1093 2.2.5.2. Address Mask Reply (type 18, code 0) 1095 2.2.5.2.1. Message specification 1097 Defined in RFC0950. Section 3.2.2.9 of [RFC1122] includes a number 1098 of requirements regarding the generation and processing of this 1099 message. 1101 Section 3.2.2.9 of [RFC1122] states that a host MAY implement sending 1102 ICMP Address Mask Request(s) and receiving ICMP Address Mask 1103 Reply(s). Section 4.3.3.9 of [RFC1812] states that a router MUST 1104 implement support for receiving ICMP Address Mask Request messages 1105 and responding with ICMP Address Mask Reply messages. 1107 2.2.5.2.2. Uses 1109 Was originally defined as a means for system stateless 1110 autoconfiguration. 1112 2.2.5.2.3. Threats 1114 Canbe used for network mapping, and OS fingerprinting. 1116 2.2.5.2.4. Operational/interoperability impact if blocked 1118 None. 1120 3. Internet Control Message Protocol version 6 (ICMPv6) 1122 3.1. ICMPv6 error messages 1124 The ICMPv6 specification leaves it up to the implementation the 1125 reaction to ICMP error messages. Therefore, the ICMP attacks 1126 described in [I-D.ietf-tcpm-icmp-attacks] might or might not be 1127 effective. 1129 3.1.1. Destination Unreachable (Type 1) 1131 3.1.1.1. No route to destination (code 0) 1133 3.1.1.1.1. Message specification 1135 Defined in [RFC4443]. 1137 3.1.1.1.2. Uses 1139 3.1.1.1.3. Threats 1141 3.1.1.1.4. Operational/interoperability impact if blocked 1143 May lead to long delays between connection establishment attempts or 1144 long response times that could have been avoided by aborting non- 1145 synchronized connections in response to ICMP soft errors 1146 [I-D.ietf-tcpm-tcp-soft-errors]. 1148 3.1.1.2. Communication with destination administratively prohibited 1149 (code 1) 1151 3.1.1.2.1. Message specification 1153 Defined in [RFC4443]. 1155 3.1.1.2.2. Uses 1157 3.1.1.2.3. Threats 1159 3.1.1.2.4. Operational/interoperability impact if blocked 1161 May lead to long delays between connection establishment attempts or 1162 long response times that could have been avoided by aborting non- 1163 synchronized connections in response to ICMP soft errors 1164 [I-D.ietf-tcpm-tcp-soft-errors]. 1166 3.1.1.3. Beyond scope of source address (code 2) 1168 3.1.1.3.1. Message specification 1170 Defined in [RFC4443]. 1172 3.1.1.3.2. Uses 1174 3.1.1.3.3. Threats 1176 3.1.1.3.4. Operational/interoperability impact if blocked 1178 May lead to long delays between connection establishment attempts or 1179 long response times that could have been avoided by aborting non- 1180 synchronized connections in response to ICMP soft errors 1181 [I-D.ietf-tcpm-tcp-soft-errors]. 1183 3.1.1.4. Address unreachable (code 3) 1185 3.1.1.4.1. Message specification 1187 Defined in [RFC4443]. 1189 3.1.1.4.2. Uses 1191 3.1.1.4.3. Threats 1193 3.1.1.4.4. Operational/interoperability impact if blocked 1195 May lead to long delays between connection establishment attempts or 1196 long response times that could have been avoided by aborting non- 1197 synchronized connections in response to ICMP soft errors 1198 [I-D.ietf-tcpm-tcp-soft-errors]. 1200 3.1.1.5. Port unreachable (code 4) 1202 3.1.1.5.1. Message specification 1204 Defined in [RFC4443]. 1206 3.1.1.5.2. Uses 1208 3.1.1.5.3. Threats 1210 This error message might used to perform Denial of Service (DoS) 1211 attacks against transport protocols. [I-D.ietf-tcpm-icmp-attacks] 1212 describes the use of this error message to attack TCP connections. 1214 3.1.1.5.4. Operational/interoperability impact if blocked 1216 May lead to long delays between connection establishment attempts or 1217 long response times that could have been avoided by aborting non- 1218 synchronized connections in response to ICMP soft errors 1219 [I-D.ietf-tcpm-tcp-soft-errors]. 1221 3.1.1.6. Source address failed ingress/egress policy (code 5) 1223 3.1.1.6.1. Message specification 1225 Defined in [RFC4443]. 1227 3.1.1.6.2. Uses 1228 3.1.1.6.3. Threats 1230 3.1.1.6.4. Operational/interoperability impact if blocked 1232 May lead to long delays between connection establishment attempts or 1233 long response times that could have been avoided by aborting non- 1234 synchronized connections in response to ICMP soft errors 1235 [I-D.ietf-tcpm-tcp-soft-errors]. 1237 3.1.1.7. Reject route to destination (code 6) 1239 3.1.1.7.1. Message specification 1241 Defined in [RFC4443]. 1243 3.1.1.7.2. Uses 1245 3.1.1.7.3. Threats 1247 3.1.1.7.4. Operational/interoperability impact if blocked 1249 May lead to long delays between connection establishment attempts or 1250 long response times that could have been avoided by aborting non- 1251 synchronized connections in response to ICMP soft errors 1252 [I-D.ietf-tcpm-tcp-soft-errors]. 1254 3.1.2. Packet Too Big Message (Type 2, code 0) 1256 3.1.2.1. Message specification 1258 Defined in [RFC4443]. 1260 3.1.2.2. Uses 1262 Used for the Path-MTU discovery mechanism for IPv6 defined in 1263 [RFC1981]. 1265 3.1.2.3. Threats 1267 This error message can be used to perform Denial of Service (DoS) 1268 attacks against transport protocols. [I-D.ietf-tcpm-icmp-attacks] 1269 describes the use of this error message to attack TCP connections. 1271 3.1.2.4. Operational/interoperability impact if blocked 1273 Filtering this error message will break the Path-MTU Discovery 1274 mechanism defined in [RFC1981]. 1276 3.1.3. Time Exceeded Message (Type 3) 1278 3.1.3.1. Hop limit exceeded in transit (code 0) 1280 3.1.3.1.1. Message specification 1282 Defined in [RFC4443]. 1284 3.1.3.1.2. Uses 1286 3.1.3.1.3. Threats 1288 3.1.3.1.4. Operational/interoperability impact if blocked 1290 May lead to long delays between connection establishment attempts or 1291 long response times that could have been avoided by aborting non- 1292 synchronized connections in response to ICMP soft errors 1293 [I-D.ietf-tcpm-tcp-soft-errors]. 1295 3.1.3.2. Fragment reassembly time exceeded (code 1) 1297 3.1.3.2.1. Message specification 1299 Defined in [RFC4443]. 1301 3.1.3.2.2. Uses 1303 Used to signal a timeout in fragment reassembly. 1305 3.1.3.2.3. Threats 1307 May reveal the timeout value used by a system for fragment 1308 reassembly. 1310 3.1.3.2.4. Operational/interoperability impact if blocked 1312 May lead to long delays between connection establishment attempts or 1313 long response times that could have been avoided by aborting non- 1314 synchronized connections in response to ICMP soft errors 1315 [I-D.ietf-tcpm-tcp-soft-errors]. 1317 3.1.4. Parameter Problem Message (Type 4) 1319 3.1.4.1. Erroneous header field encountered (code 0) 1320 3.1.4.1.1. Message specification 1322 Defined in [RFC4443]. 1324 3.1.4.1.2. Uses 1326 3.1.4.1.3. Threats 1328 This error message might used to perform Denial of Service (DoS) 1329 attacks against transport protocols. [I-D.ietf-tcpm-icmp-attacks] 1330 describes the use of this error message to attack TCP connections. 1332 3.1.4.1.4. Operational/interoperability impact if blocked 1334 3.1.4.2. Unrecognized Next Header type encountered (code 1) 1336 3.1.4.2.1. Message specification 1338 Defined in [RFC4443]. 1340 3.1.4.2.2. Uses 1342 3.1.4.2.3. Threats 1344 This error message might used to perform Denial of Service (DoS) 1345 attacks against transport protocols. [I-D.ietf-tcpm-icmp-attacks] 1346 describes the use of this error message to attack TCP connections. 1348 3.1.4.2.4. Operational/interoperability impact if blocked 1350 3.1.4.3. Unrecognized IPv6 option encountered (code 2) 1352 3.1.4.3.1. Message specification 1354 Defined in [RFC4443]. 1356 3.1.4.3.2. Uses 1358 3.1.4.3.3. Threats 1360 3.1.4.3.4. Operational/interoperability impact if blocked 1362 3.1.5. Private experimentation (Type 100) 1364 3.1.5.1. Message specification 1366 Defined in [RFC4443]. 1368 3.1.5.2. Uses 1370 3.1.5.3. Threats 1372 3.1.5.4. Operational/interoperability impact if blocked 1374 3.1.6. Private experimentation (Type 101) 1376 3.1.6.1. Message specification 1378 Defined in [RFC4443]. 1380 3.1.6.2. Uses 1382 3.1.6.3. Threats 1384 3.1.6.4. Operational/interoperability impact if blocked 1386 3.1.7. Reserved for expansion of ICMPv6 error messages (Type 127) 1388 3.1.7.1. Message specification 1390 Defined in [RFC4443]. 1392 3.1.7.2. Uses 1394 3.1.7.3. Threats 1396 3.1.7.4. Operational/interoperability impact if blocked 1398 3.2. ICMPv6 Informational messages 1400 3.2.1. Echo Request or Echo Reply Message 1402 3.2.1.1. Echo Request message (type 128, code 0) 1404 3.2.1.1.1. Message specification 1406 Defined in [RFC4443]. 1408 3.2.1.1.2. Uses 1410 Used by the ping tool to test reachability. 1412 3.2.1.1.3. Threats 1414 Can be used for network mapping [icmp-scanning] and for performing 1415 Smurf DoS attacks [smurf]. 1417 3.2.1.1.4. Operational/interoperability impact if blocked 1419 Filtering this error message will break the ping tool. The best 1420 current practice is to rate-limit this ICMP message. 1422 3.2.1.2. Echo reply message (Type 129, code 0) 1424 3.2.1.2.1. Message specification 1426 Defined in [RFC4443]. 1428 3.2.1.2.2. Uses 1430 Used by the ping tool to test reachability. 1432 3.2.1.2.3. Threats 1434 Can be used for network mapping [icmp-scanning] and for performing 1435 Smurf DoS attacks [smurf]. 1437 3.2.1.2.4. Operational/interoperability impact if blocked 1439 Filtering this error message will break the ping tool. The best 1440 current practice is to rate-limit this ICMP message. 1442 3.2.2. Private experimentation (Type 200) 1444 3.2.2.1. Message specification 1446 Defined in [RFC4443]. 1448 3.2.2.2. Uses 1450 3.2.2.3. Threats 1452 3.2.2.4. Operational/interoperability impact if blocked 1454 3.2.3. Private experimentation (Type 201) 1456 3.2.3.1. Message specification 1458 Defined in [RFC4443]. 1460 3.2.3.2. Uses 1461 3.2.3.3. Threats 1463 3.2.3.4. Operational/interoperability impact if blocked 1465 3.2.4. Reserved for expansion of ICMPv6 informational messages (Type 1466 255) 1468 3.2.4.1. Message specification 1470 Defined in [RFC4443]. 1472 3.2.4.2. Uses 1474 3.2.4.3. Threats 1476 3.2.4.4. Operational/interoperability impact if blocked 1478 4. Security Considerations 1480 This document does not introduce any new security implications. It 1481 attempts to help mitigate security threats that rely on ICMP through 1482 packet filtering and rate-limiting. 1484 5. Acknowledgements 1486 This survey of ICMP specifications is based on a yet-to-be-published 1487 internet-draft on ICMP by Fernando Gont and Carlos Pignataro. This 1488 document borrows its structure from the "ICMP filtering" wiki started 1489 by George Jones. 1491 Fernando would like to thank Paula Piedra for her love and support. 1493 6. References 1495 6.1. Normative References 1497 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1498 RFC 792, September 1981. 1500 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1501 Communication Layers", STD 3, RFC 1122, October 1989. 1503 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1504 November 1990. 1506 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1507 September 1991. 1509 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1510 RFC 1812, June 1995. 1512 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1513 for IP version 6", RFC 1981, August 1996. 1515 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1516 3", BCP 9, RFC 2026, October 1996. 1518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1519 Requirement Levels", BCP 14, RFC 2119, March 1997. 1521 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 1522 Control", RFC 2581, April 1999. 1524 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1525 Message Protocol (ICMPv6) for the Internet Protocol 1526 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1528 6.2. Informative References 1530 [I-D.ietf-tcpm-icmp-attacks] 1531 Gont, F., "ICMP attacks against TCP", 1532 draft-ietf-tcpm-icmp-attacks-03 (work in progress), 1533 March 2008. 1535 [I-D.ietf-tcpm-tcp-soft-errors] 1536 Gont, F., "TCP's Reaction to Soft Errors", 1537 draft-ietf-tcpm-tcp-soft-errors-07 (work in progress), 1538 December 2007. 1540 [icmp-scanning] 1541 Arkin, 0., "ICMP Usage in Scanning: The Complete Know- 1542 How", http://www.sys-security.com/archive/papers/ 1543 ICMP_Scanning_v3.0.pdf, 2001. 1545 [smurf] CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of- 1546 Service Attacks", 1547 http://www.cert.org/advisories/CA-1998-01.html, 1998. 1549 Appendix A. Change log (to be removed before publication of the 1550 document as an RFC) 1552 blah 1554 Authors' Addresses 1556 Fernando Gont 1557 Universidad Tecnologica Nacional / Facultad Regional Haedo 1558 Evaristo Carriego 2644 1559 Haedo, Provincia de Buenos Aires 1706 1560 Argentina 1562 Phone: +54 11 4650 8472 1563 Email: fernando@gont.com.ar 1564 URI: http://www.gont.com.ar 1566 Guillermo Gont 1567 Universidad Tecnologica Nacional / Facultad Regional Haedo 1568 Evaristo Carriego 2644 1569 Haedo, Provincia de Buenos Aires 1706 1570 Argentina 1572 Phone: +54 11 4650 8472 1573 Email: guillermo@gont.com.ar 1575 Full Copyright Statement 1577 Copyright (C) The IETF Trust (2008). 1579 This document is subject to the rights, licenses and restrictions 1580 contained in BCP 78, and except as set forth therein, the authors 1581 retain all their rights. 1583 This document and the information contained herein are provided on an 1584 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1585 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1586 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1587 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1588 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1589 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1591 Intellectual Property 1593 The IETF takes no position regarding the validity or scope of any 1594 Intellectual Property Rights or other rights that might be claimed to 1595 pertain to the implementation or use of the technology described in 1596 this document or the extent to which any license under such rights 1597 might or might not be available; nor does it represent that it has 1598 made any independent effort to identify any such rights. Information 1599 on the procedures with respect to rights in RFC documents can be 1600 found in BCP 78 and BCP 79. 1602 Copies of IPR disclosures made to the IETF Secretariat and any 1603 assurances of licenses to be made available, or the result of an 1604 attempt made to obtain a general license or permission for the use of 1605 such proprietary rights by implementers or users of this 1606 specification can be obtained from the IETF on-line IPR repository at 1607 http://www.ietf.org/ipr. 1609 The IETF invites any interested party to bring to its attention any 1610 copyrights, patents or patent applications, or other proprietary 1611 rights that may cover technology that may be required to implement 1612 this standard. Please address the information to the IETF at 1613 ietf-ipr@ietf.org.