draft-ietf-opsec-icmp-filtering-00.txt   draft-ietf-opsec-icmp-filtering-01.txt 
Operational Security Capabilities F. Gont Operational Security Capabilities F. Gont
for IP Network Infrastructure G. Gont for IP Network Infrastructure G. Gont
(opsec) UTN/FRH (opsec) UTN/FRH
Internet-Draft September 1, 2008 Internet-Draft October 26, 2009
Intended status: Informational Intended status: Informational
Expires: March 5, 2009 Expires: April 29, 2010
Recommendations for filtering ICMP messages Recommendations for filtering ICMP messages
draft-ietf-opsec-icmp-filtering-00.txt draft-ietf-opsec-icmp-filtering-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 5, 2009. This Internet-Draft will expire on April 29, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document document provides advice on the filtering of ICMPv4 and This document document provides advice on the filtering of ICMPv4 and
ICMPv6 messages. Additionaly, it discusses the operational and ICMPv6 messages. Additionaly, it discusses the operational and
interoperability implications of such filtering. interoperability implications of such filtering.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Internet Control Message Protocol version 4 (ICMP) . . . . . . 5 2. Internet Control Message Protocol version 4 (ICMP) . . . . . . 5
2.1. ICMPv4 error messages . . . . . . . . . . . . . . . . . . 5 2.1. ICMPv4 error messages . . . . . . . . . . . . . . . . . . 5
2.1.1. Destination Unreachable (Type 3) . . . . . . . . . . . 6 2.1.1. Destination Unreachable (Type 3) . . . . . . . . . . . 6
2.1.1.1. Net Unreachable (code 0) . . . . . . . . . . . . . 6 2.1.1.1. Net Unreachable (code 0) . . . . . . . . . . . . . 6
2.1.1.2. Host Unreachable (code 1) . . . . . . . . . . . . 7 2.1.1.2. Host Unreachable (code 1) . . . . . . . . . . . . 7
2.1.1.3. Protocol Unreachable (code 2) . . . . . . . . . . 7 2.1.1.3. Protocol Unreachable (code 2) . . . . . . . . . . 8
2.1.1.4. Port Unreachable (code 3) . . . . . . . . . . . . 8 2.1.1.4. Port Unreachable (code 3) . . . . . . . . . . . . 9
2.1.1.5. Fragmentation needed and DF set (code 4) . . . . . 9 2.1.1.5. Fragmentation needed and DF set (code 4) . . . . . 10
2.1.1.6. Source Route Failed (code 5) . . . . . . . . . . . 9 2.1.1.6. Source Route Failed (code 5) . . . . . . . . . . . 10
2.1.1.7. Destination network unknown (code 6) 2.1.1.7. Destination network unknown (code 6)
(Deprecated) . . . . . . . . . . . . . . . . . . . 10 (Deprecated) . . . . . . . . . . . . . . . . . . . 11
2.1.1.8. Destination host unknown (code 7) . . . . . . . . 11 2.1.1.8. Destination host unknown (code 7) . . . . . . . . 12
2.1.1.9. Source host isolated (code 8) (Deprecated) . . . . 11 2.1.1.9. Source host isolated (code 8) (Deprecated) . . . . 12
2.1.1.10. Communication with destination network 2.1.1.10. Communication with destination network
administratively prohibited (code 9) - administratively prohibited (code 9) -
Deprecated . . . . . . . . . . . . . . . . . . . . 12 Deprecated . . . . . . . . . . . . . . . . . . . . 13
2.1.1.11. Communication with destination host 2.1.1.11. Communication with destination host
administratively prohibited (code 10) - administratively prohibited (code 10) -
Deprecated . . . . . . . . . . . . . . . . . . . . 12 Deprecated . . . . . . . . . . . . . . . . . . . . 14
2.1.1.12. Network unreachable for type of service (code 2.1.1.12. Network unreachable for type of service (code
11) . . . . . . . . . . . . . . . . . . . . . . . 13 11) . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1.13. Host unreachable for type of service (code 12) . . 14 2.1.1.13. Host unreachable for type of service (code 12) . . 16
2.1.1.14. Communication Administratively Prohibited 2.1.1.14. Communication Administratively Prohibited
(code 13) . . . . . . . . . . . . . . . . . . . . 14 (code 13) . . . . . . . . . . . . . . . . . . . . 16
2.1.1.15. Host Precedence Violation (code 14) . . . . . . . 15 2.1.1.15. Host Precedence Violation (code 14) . . . . . . . 17
2.1.1.16. Precedence cutoff in effect (code 15) . . . . . . 16 2.1.1.16. Precedence cutoff in effect (code 15) . . . . . . 18
2.1.2. Source Quench (Type 4, Code 0) . . . . . . . . . . . . 16 2.1.2. Source Quench (Type 4, Code 0) . . . . . . . . . . . . 19
2.1.2.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.2.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.2.2. Message specification . . . . . . . . . . . . . . 16 2.1.2.2. Message specification . . . . . . . . . . . . . . 19
2.1.2.3. Threats . . . . . . . . . . . . . . . . . . . . . 17 2.1.2.3. Threats . . . . . . . . . . . . . . . . . . . . . 19
2.1.2.4. Operational/interoperability impact if blocked . . 17 2.1.2.4. Operational/interoperability impact if blocked . . 19
2.1.3. Redirect (Type 5) . . . . . . . . . . . . . . . . . . 17 2.1.3. Redirect (Type 5) . . . . . . . . . . . . . . . . . . 20
2.1.3.1. Redirect datagrams for the Network (code 0) . . . 17 2.1.3.1. Redirect datagrams for the Network (code 0) . . . 20
2.1.3.2. Redirect datagrams for the Host (code 1) . . . . . 18 2.1.3.2. Redirect datagrams for the Host (code 1) . . . . . 20
2.1.3.3. Redirect datagrams for the Type of Service and 2.1.3.3. Redirect datagrams for the Type of Service and
Network (code 2) . . . . . . . . . . . . . . . . . 18 Network (code 2) . . . . . . . . . . . . . . . . . 21
2.1.3.4. Redirect datagrams for the Type of Service and 2.1.3.4. Redirect datagrams for the Type of Service and
Host (code 3) . . . . . . . . . . . . . . . . . . 19 Host (code 3) . . . . . . . . . . . . . . . . . . 22
2.1.4. Time exceeded (Type 11) . . . . . . . . . . . . . . . 20 2.1.4. Time exceeded (Type 11) . . . . . . . . . . . . . . . 22
2.1.4.1. Time to live exceeded in transit (code 0) . . . . 20 2.1.4.1. Time to live exceeded in transit (code 0) . . . . 22
2.1.4.2. fragment reassembly time exceeded (code 1) . . . . 20 2.1.4.2. fragment reassembly time exceeded (code 1) . . . . 23
2.1.5. Parameter Problem (Type 12) . . . . . . . . . . . . . 21
2.1.5.1. Pointer indicates the error (code 0) . . . . . . . 21 2.1.5. Parameter Problem (Type 12) . . . . . . . . . . . . . 24
2.1.5.2. Required option is missing (code 1) . . . . . . . 22 2.1.5.1. Pointer indicates the error (code 0) . . . . . . . 24
2.2. ICMPv4 Informational messages . . . . . . . . . . . . . . 22 2.1.5.2. Required option is missing (code 1) . . . . . . . 24
2.2.1. Echo or Echo Reply Message . . . . . . . . . . . . . . 22 2.2. ICMPv4 Informational messages . . . . . . . . . . . . . . 25
2.2.1.1. Echo message (type 8, code 0) . . . . . . . . . . 22 2.2.1. Echo or Echo Reply Message . . . . . . . . . . . . . . 25
2.2.1.2. Echo reply message (Type 0, code 0) . . . . . . . 23 2.2.1.1. Echo message (type 8, code 0) . . . . . . . . . . 25
2.2.2. Router Solicitation or Router Advertisement message . 24 2.2.1.2. Echo reply message (Type 0, code 0) . . . . . . . 26
2.2.2.1. Router Solicitation message (type 10, code 0) . . 24 2.2.2. Router Solicitation or Router Advertisement message . 26
2.2.2.2. Router Advertisement message (type 9, code 0) . . 25 2.2.2.1. Router Solicitation message (type 10, code 0) . . 26
2.2.3. Timestamp or Timestamp Reply Message . . . . . . . . . 25 2.2.2.2. Router Advertisement message (type 9, code 0) . . 27
2.2.3.1. Timestamp message (type 13, code 0) . . . . . . . 25 2.2.3. Timestamp or Timestamp Reply Message . . . . . . . . . 28
2.2.3.2. Timestamp reply message (type 14, code 0) . . . . 26 2.2.3.1. Timestamp message (type 13, code 0) . . . . . . . 28
2.2.3.2. Timestamp reply message (type 14, code 0) . . . . 28
2.2.4. Information Request or Information Reply Message 2.2.4. Information Request or Information Reply Message
(Deprecated) . . . . . . . . . . . . . . . . . . . . . 26 (Deprecated) . . . . . . . . . . . . . . . . . . . . . 29
2.2.4.1. Information request message (type 15, code 0) . . 26 2.2.4.1. Information request message (type 15, code 0) . . 29
2.2.4.2. Information reply message (type 16, code 0) . . . 27 2.2.4.2. Information reply message (type 16, code 0) . . . 29
2.2.5. Address Mask Request or Address Mask Reply . . . . . . 27 2.2.5. Address Mask Request or Address Mask Reply . . . . . . 30
2.2.5.1. Address Mask Request (type 17, code 0) . . . . . . 27 2.2.5.1. Address Mask Request (type 17, code 0) . . . . . . 30
2.2.5.2. Address Mask Reply (type 18, code 0) . . . . . . . 28 2.2.5.2. Address Mask Reply (type 18, code 0) . . . . . . . 30
3. Internet Control Message Protocol version 6 (ICMPv6) . . . . . 28 3. Internet Control Message Protocol version 6 (ICMPv6) . . . . . 31
3.1. ICMPv6 error messages . . . . . . . . . . . . . . . . . . 29 3.1. ICMPv6 error messages . . . . . . . . . . . . . . . . . . 31
3.1.1. Destination Unreachable (Type 1) . . . . . . . . . . . 29 3.1.1. Destination Unreachable (Type 1) . . . . . . . . . . . 31
3.1.1.1. No route to destination (code 0) . . . . . . . . . 29 3.1.1.1. No route to destination (code 0) . . . . . . . . . 31
3.1.1.2. Communication with destination 3.1.1.2. Communication with destination
administratively prohibited (code 1) . . . . . . . 29 administratively prohibited (code 1) . . . . . . . 32
3.1.1.3. Beyond scope of source address (code 2) . . . . . 30 3.1.1.3. Beyond scope of source address (code 2) . . . . . 33
3.1.1.4. Address unreachable (code 3) . . . . . . . . . . . 30 3.1.1.4. Address unreachable (code 3) . . . . . . . . . . . 33
3.1.1.5. Port unreachable (code 4) . . . . . . . . . . . . 31 3.1.1.5. Port unreachable (code 4) . . . . . . . . . . . . 34
3.1.1.6. Source address failed ingress/egress policy 3.1.1.6. Source address failed ingress/egress policy
(code 5) . . . . . . . . . . . . . . . . . . . . . 31 (code 5) . . . . . . . . . . . . . . . . . . . . . 34
3.1.1.7. Reject route to destination (code 6) . . . . . . . 32 3.1.1.7. Reject route to destination (code 6) . . . . . . . 35
3.1.2. Packet Too Big Message (Type 2, code 0) . . . . . . . 32 3.1.2. Packet Too Big Message (Type 2, code 0) . . . . . . . 35
3.1.2.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 32 3.1.2.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.2.2. Message specification . . . . . . . . . . . . . . 32 3.1.2.2. Message specification . . . . . . . . . . . . . . 36
3.1.2.3. Threats . . . . . . . . . . . . . . . . . . . . . 32 3.1.2.3. Threats . . . . . . . . . . . . . . . . . . . . . 36
3.1.2.4. Operational/interoperability impact if blocked . . 32 3.1.2.4. Operational/interoperability impact if blocked . . 36
3.1.3. Time Exceeded Message (Type 3) . . . . . . . . . . . . 32 3.1.3. Time Exceeded Message (Type 3) . . . . . . . . . . . . 36
3.1.3.1. Hop limit exceeded in transit (code 0) . . . . . . 33 3.1.3.1. Hop limit exceeded in transit (code 0) . . . . . . 36
3.1.3.2. Fragment reassembly time exceeded (code 1) . . . . 33 3.1.3.2. Fragment reassembly time exceeded (code 1) . . . . 36
3.1.4. Parameter Problem Message (Type 4) . . . . . . . . . . 34 3.1.4. Parameter Problem Message (Type 4) . . . . . . . . . . 37
3.1.4.1. Erroneous header field encountered (code 0) . . . 34 3.1.4.1. Erroneous header field encountered (code 0) . . . 37
3.1.4.2. Unrecognized Next Header type encountered 3.1.4.2. Unrecognized Next Header type encountered
(code 1) . . . . . . . . . . . . . . . . . . . . . 34 (code 1) . . . . . . . . . . . . . . . . . . . . . 38
3.1.4.3. Unrecognized IPv6 option encountered (code 2) . . 35 3.1.4.3. Unrecognized IPv6 option encountered (code 2) . . 38
3.1.5. Private experimentation (Type 100) . . . . . . . . . . 35 3.1.5. Private experimentation (Type 100) . . . . . . . . . . 39
3.1.5.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 35 3.1.5.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.5.2. Message specification . . . . . . . . . . . . . . 35 3.1.5.2. Message specification . . . . . . . . . . . . . . 39
3.1.5.3. Threats . . . . . . . . . . . . . . . . . . . . . 35 3.1.5.3. Threats . . . . . . . . . . . . . . . . . . . . . 39
3.1.5.4. Operational/interoperability impact if blocked . . 35 3.1.5.4. Operational/interoperability impact if blocked . . 39
3.1.6. Private experimentation (Type 101) . . . . . . . . . . 35 3.1.6. Private experimentation (Type 101) . . . . . . . . . . 39
3.1.6.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 35 3.1.6.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.6.2. Message specification . . . . . . . . . . . . . . 36 3.1.6.2. Message specification . . . . . . . . . . . . . . 39
3.1.6.3. Threats . . . . . . . . . . . . . . . . . . . . . 36 3.1.6.3. Threats . . . . . . . . . . . . . . . . . . . . . 40
3.1.6.4. Operational/interoperability impact if blocked . . 36 3.1.6.4. Operational/interoperability impact if blocked . . 40
3.1.7. Reserved for expansion of ICMPv6 error messages 3.1.7. Reserved for expansion of ICMPv6 error messages
(Type 127) . . . . . . . . . . . . . . . . . . . . . . 36 (Type 127) . . . . . . . . . . . . . . . . . . . . . . 40
3.1.7.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 36 3.1.7.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 40
3.1.7.2. Message specification . . . . . . . . . . . . . . 36 3.1.7.2. Message specification . . . . . . . . . . . . . . 40
3.1.7.3. Threats . . . . . . . . . . . . . . . . . . . . . 36 3.1.7.3. Threats . . . . . . . . . . . . . . . . . . . . . 40
3.1.7.4. Operational/interoperability impact if blocked . . 36 3.1.7.4. Operational/interoperability impact if blocked . . 40
3.2. ICMPv6 Informational messages . . . . . . . . . . . . . . 36 3.2. ICMPv6 Informational messages . . . . . . . . . . . . . . 40
3.2.1. Echo Request or Echo Reply Message . . . . . . . . . . 36 3.2.1. Echo Request or Echo Reply Message . . . . . . . . . . 40
3.2.1.1. Echo Request message (type 128, code 0) . . . . . 36 3.2.1.1. Echo Request message (type 128, code 0) . . . . . 40
3.2.1.2. Echo reply message (Type 129, code 0) . . . . . . 36 3.2.1.2. Echo reply message (Type 129, code 0) . . . . . . 40
3.2.2. Private experimentation (Type 200) . . . . . . . . . . 37 3.2.2. Private experimentation (Type 200) . . . . . . . . . . 41
3.2.2.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 37 3.2.2.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.2.2. Message specification . . . . . . . . . . . . . . 37 3.2.2.2. Message specification . . . . . . . . . . . . . . 41
3.2.2.3. Threats . . . . . . . . . . . . . . . . . . . . . 37 3.2.2.3. Threats . . . . . . . . . . . . . . . . . . . . . 41
3.2.2.4. Operational/interoperability impact if blocked . . 37 3.2.2.4. Operational/interoperability impact if blocked . . 41
3.2.3. Private experimentation (Type 201) . . . . . . . . . . 37 3.2.3. Private experimentation (Type 201) . . . . . . . . . . 41
3.2.3.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 37 3.2.3.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.3.2. Message specification . . . . . . . . . . . . . . 37 3.2.3.2. Message specification . . . . . . . . . . . . . . 41
3.2.3.3. Threats . . . . . . . . . . . . . . . . . . . . . 37 3.2.3.3. Threats . . . . . . . . . . . . . . . . . . . . . 41
3.2.3.4. Operational/interoperability impact if blocked . . 37 3.2.3.4. Operational/interoperability impact if blocked . . 41
3.2.4. Reserved for expansion of ICMPv6 informational 3.2.4. Reserved for expansion of ICMPv6 informational
messages (Type 255) . . . . . . . . . . . . . . . . . 37 messages (Type 255) . . . . . . . . . . . . . . . . . 41
3.2.4.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.4.1. Uses . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.4.2. Message specification . . . . . . . . . . . . . . 38 3.2.4.2. Message specification . . . . . . . . . . . . . . 41
3.2.4.3. Threats . . . . . . . . . . . . . . . . . . . . . 38 3.2.4.3. Threats . . . . . . . . . . . . . . . . . . . . . 42
3.2.4.4. Operational/interoperability impact if blocked . . 38 3.2.4.4. Operational/interoperability impact if blocked . . 42
4. Security Considerations . . . . . . . . . . . . . . . . . . . 38 4. Security Considerations . . . . . . . . . . . . . . . . . . . 42
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.1. Normative References . . . . . . . . . . . . . . . . . . . 38 6.1. Normative References . . . . . . . . . . . . . . . . . . . 42
6.2. Informative References . . . . . . . . . . . . . . . . . . 39 6.2. Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Change log (to be removed before publication of Appendix A. Change log (to be removed before publication of
the document as an RFC) . . . . . . . . . . . . . . . 39 the document as an RFC) . . . . . . . . . . . . . . . 43
A.1. Changes from draft-gont-opsec-icmp-filtering-00 . . . . . 39 A.1. Changes from draft-ietf-opsec-icmp-filtering-00 . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 A.2. Changes from draft-gont-opsec-icmp-filtering-00 . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This document document provides advice on the filtering of ICMPv4 and This document document provides advice on the filtering of ICMPv4 and
ICMPv6 messages. Additionaly, it discusses the operational and ICMPv6 messages. Additionaly, it discusses the operational and
interoperability implications of such filtering. interoperability implications of such filtering.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 6, line 38 skipping to change at page 6, line 38
that the transport layer SHOULD use the information appropriately. that the transport layer SHOULD use the information appropriately.
2.1.1.1. Net Unreachable (code 0) 2.1.1.1. Net Unreachable (code 0)
2.1.1.1.1. Uses 2.1.1.1.1. Uses
Used to indicate that a router cannot forward a packet because it has Used to indicate that a router cannot forward a packet because it has
no routes at all (including no default route) to the destination no routes at all (including no default route) to the destination
specified in the packet. A number of systems abort connections in specified in the packet. A number of systems abort connections in
non-synchronized states in response to this message, to avoid long non-synchronized states in response to this message, to avoid long
delays in connection establishment attempts delays in connection establishment attempts [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.1.2. Message specification 2.1.1.1.2. Message specification
Defined in [RFC0792]. Section 4.3.3.1 of [RFC1812] states that if a 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 router cannot forward a packet because it has no routes at all
(including no default route) to the destination specified in the (including no default route) to the destination specified in the
packet, then the router MUST generate a Destination Unreachable, Code packet, then the router MUST generate a Destination Unreachable, Code
0 (Network Unreachable) ICMP message. Section 3.2.2.1 of [RFC1122] 0 (Network Unreachable) ICMP message. Section 3.2.2.1 of [RFC1122]
states that this message may result from a routing transient, and states that this message may result from a routing transient, and
MUST therefore be interpreted as only a hint, not proof, that the MUST therefore be interpreted as only a hint, not proof, that the
specified destination is unreachable. For example, it MUST NOT be 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 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 that this message indicates a soft error, and therefore TCP MUST NOT
abort the connection, and SHOULD make the information available to abort the connection, and SHOULD make the information available to
the application. the application.
2.1.1.1.3. Threats 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 can be mitigated by rate limiting the rate of IMCP messages
generated. For rate limiting ICMPv6 messages see Section 2.4.f of
[RFC4443].
2.1.1.1.4. Operational/interoperability impact if blocked 2.1.1.1.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts May lead to long delays between connection establishment attempts
that could have been avoided by those systems aborting non- that could have been avoided by those systems aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.2. Host Unreachable (code 1) 2.1.1.2. Host Unreachable (code 1)
2.1.1.2.1. Uses 2.1.1.2.1. Uses
Used to indicate that a router cannot forward a to the intended Used to indicate that a router cannot forward a to the intended
destination because it is unreachable. A number of systems abort destination because it is unreachable. A number of systems abort
connections in non-synchronized states in response to this message, connections in non-synchronized states in response to this message,
to avoid long delays in connection establishment attempts to avoid long delays in connection establishment attempts [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.2.2. Message specification 2.1.1.2.2. Message specification
Defined in [RFC0792]. Section 3.2.2.1 of [RFC1122] states that his Defined in [RFC0792]. Section 3.2.2.1 of [RFC1122] states that his
message may result from a routing transient, and MUST therefore be message may result from a routing transient, and MUST therefore be
interpreted as only a hint, not proof, that the specified destination 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 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 gateway. Section 4.2.3.9 of [RFC1122] states that this message
indicates a soft error, and therefore TCP MUST NOT abort the indicates a soft error, and therefore TCP MUST NOT abort the
connection, and SHOULD make the information available to the connection, and SHOULD make the information available to the
application. application.
2.1.1.2.3. Threats 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 ICMPv6 messages see Section 2.4.f of
[RFC4443].
2.1.1.2.4. Operational/interoperability impact if blocked 2.1.1.2.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts May lead to long delays between connection establishment attempts
that could have been avoided by those systems aborting non- that could have been avoided by those systems aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.3. Protocol Unreachable (code 2) 2.1.1.3. Protocol Unreachable (code 2)
2.1.1.3.1. Uses 2.1.1.3.1. Uses
Used by hosts to indicate that the designated transport protocol is Used by hosts to indicate that the designated transport protocol is
not supported. not supported.
2.1.1.3.2. Message specification 2.1.1.3.2. Message specification
Defined in [RFC0792]. [RFC1122] states that a host SHOULD send a Defined in [RFC0792]. [RFC1122] states that a host SHOULD send a
protocol unreachable when the designated transport protocol is not protocol unreachable when the designated transport protocol is not
supported. Section 4.2.3.9 of [RFC1122] states that this message supported. Section 4.2.3.9 of [RFC1122] states that this message
skipping to change at page 8, line 21 skipping to change at page 8, line 36
Defined in [RFC0792]. [RFC1122] states that a host SHOULD send a Defined in [RFC0792]. [RFC1122] states that a host SHOULD send a
protocol unreachable when the designated transport protocol is not protocol unreachable when the designated transport protocol is not
supported. Section 4.2.3.9 of [RFC1122] states that this message supported. Section 4.2.3.9 of [RFC1122] states that this message
indicates a hard error condition, so TCP SHOULD abort the connection. indicates a hard error condition, so TCP SHOULD abort the connection.
2.1.1.3.3. Threats 2.1.1.3.3. Threats
Can be exploited to perform connection-reset attacks Can be exploited to perform connection-reset attacks
[I-D.ietf-tcpm-icmp-attacks]. [I-D.ietf-tcpm-icmp-attacks].
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 ICMPv6 messages see Section 2.4.f of
[RFC4443].
2.1.1.3.4. Operational/interoperability impact if blocked 2.1.1.3.4. Operational/interoperability impact if blocked
None. None.
2.1.1.4. Port Unreachable (code 3) 2.1.1.4. Port Unreachable (code 3)
2.1.1.4.1. Uses 2.1.1.4.1. Uses
Used by end-systems to signal the source system that it could not Used by end-systems to signal the source system that it could not
demultiplex the received packet (i.e., there was no listening process demultiplex the received packet (i.e., there was no listening process
on the destination port). Used by UDP-based trace route to locate 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 the final destination (UDP probes are sent to an UDP port that is
believed to be unused). Some firewalls respond with this error believed to be unused). Some firewalls respond with this error
message when a received packet is discarded due to a violation of the message when a received packet is discarded due to a violation of the
firewall security policy. A number of systems abort connections in firewall security policy. A number of systems abort connections in
non-synchronized states in response to this message, to avoid long non-synchronized states in response to this message, to avoid long
delays in connection establishment attempts delays in connection establishment attempts [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.4.2. Message specification 2.1.1.4.2. Message specification
Defined in [RFC0792]. Section 3.2.2.1 of [RFC1122] states that a Defined in [RFC0792]. Section 3.2.2.1 of [RFC1122] states that a
host SHOULD send an ICMP port unreachable when the designated host SHOULD send an ICMP port unreachable when the designated
transport protocol (e.g., UDP) is unable to demultiplex the datagram transport protocol (e.g., UDP) is unable to demultiplex the datagram
but has no protocol mechanism to inform the sender. Additionally, it but has no protocol mechanism to inform the sender. Additionally, it
states that a transport protocol that has its own mechanism for states that a transport protocol that has its own mechanism for
notifying the sender that a port is unreachable MUST nevertheless notifying the sender that a port is unreachable MUST nevertheless
accept an ICMP Port Unreachable for the same purpose. accept an ICMP Port Unreachable for the same purpose.
Section 4.2.3.9 of [RFC1122] states that this message indicates a Section 4.2.3.9 of [RFC1122] states that this message indicates a
hard error condition, so TCP SHOULD abort the connection. hard error condition, so TCP SHOULD abort the connection.
2.1.1.4.3. Threats 2.1.1.4.3. Threats
Can be abused to perform connection-reset attacks Can be abused to perform connection-reset attacks
[I-D.ietf-tcpm-icmp-attacks]. [I-D.ietf-tcpm-icmp-attacks].
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 ICMPv6 messages see Section 2.4.f of
[RFC4443].
2.1.1.4.4. Operational/interoperability impact if blocked 2.1.1.4.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.5. Fragmentation needed and DF set (code 4) 2.1.1.5. Fragmentation needed and DF set (code 4)
2.1.1.5.1. Uses 2.1.1.5.1. Uses
Used for the Path-MTU Discovery mechanism described in [RFC1191]. Used for the Path-MTU Discovery mechanism described in [RFC1191].
2.1.1.5.2. Message specification 2.1.1.5.2. Message specification
Defined in [RFC0792] Defined in [RFC0792]
skipping to change at page 10, line 11 skipping to change at page 10, line 48
gateway. Section 4.2.3.9 of [RFC1122] states that this message gateway. Section 4.2.3.9 of [RFC1122] states that this message
indicates a soft error, and therefore TCP MUST NOT abort the indicates a soft error, and therefore TCP MUST NOT abort the
connection, and SHOULD make the information available to the connection, and SHOULD make the information available to the
application. application.
Section 4.2.3.9 of [RFC1122] states that this message indicates a Section 4.2.3.9 of [RFC1122] states that this message indicates a
hard error condition, so TCP SHOULD abort the connection. hard error condition, so TCP SHOULD abort the connection.
2.1.1.6.3. Threats 2.1.1.6.3. Threats
There shouldn't be any security threats araising from the use of this An attacker can potentially perform a Denial of Service (DoS) attack
error message. 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 ICMPv6 messages see Section 2.4.f of
[RFC4443].
2.1.1.6.4. Operational/interoperability impact if blocked 2.1.1.6.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.7. Destination network unknown (code 6) (Deprecated) 2.1.1.7. Destination network unknown (code 6) (Deprecated)
2.1.1.7.1. Uses 2.1.1.7.1. Uses
Signal unreachability condition to the sending system. Currently Signal unreachability condition to the sending system. Currently
deprecated. A number of systems abort connections in non- deprecated. A number of systems abort connections in non-
synchronized states in response to this message, to avoid long delays synchronized states in response to this message, to avoid long delays
in connection establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. in connection establishment attempts [RFC5461].
2.1.1.7.2. Message specification 2.1.1.7.2. Message specification
Defined in [RFC1122]. [RFC1812] states that this code SHOULD NOT be Defined in [RFC1122]. [RFC1812] states that this code SHOULD NOT be
generated since it would imply on the part of the router that the generated since it would imply on the part of the router that the
destination network does not exist (net unreachable code 0 SHOULD be destination network does not exist (net unreachable code 0 SHOULD be
used in place of code 6). used in place of code 6).
2.1.1.7.3. Threats 2.1.1.7.3. Threats
There shouldn't be any security threats araising from the use of this An attacker can potentially perform a Denial of Service (DoS) attack
error message. 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 ICMPv6 messages see Section 2.4.f of
[RFC4443].
2.1.1.7.4. Operational/interoperability impact if blocked 2.1.1.7.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.8. Destination host unknown (code 7) 2.1.1.8. Destination host unknown (code 7)
2.1.1.8.1. Uses 2.1.1.8.1. Uses
Signal unreachability condition to the sending system. A number of Signal unreachability condition to the sending system. A number of
systems abort connections in non-synchronized states in response to systems abort connections in non-synchronized states in response to
this message, to avoid long delays in connection establishment this message, to avoid long delays in connection establishment
attempts [I-D.ietf-tcpm-tcp-soft-errors]. attempts [RFC5461].
2.1.1.8.2. Message specification 2.1.1.8.2. Message specification
Defined in [RFC1122], and is generated only when a router can Defined in [RFC1122], and is generated only when a router can
determine (from link layer advice) that the destination host does not determine (from link layer advice) that the destination host does not
exist exist
2.1.1.8.3. Threats 2.1.1.8.3. Threats
There shouldn't be any security threats araising from the use of this An attacker can potentially perform a Denial of Service (DoS) attack
error message. 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 ICMPv6 messages see Section 2.4.f of
[RFC4443].
2.1.1.8.4. Operational/interoperability impact if blocked 2.1.1.8.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.9. Source host isolated (code 8) (Deprecated) 2.1.1.9. Source host isolated (code 8) (Deprecated)
2.1.1.9.1. Uses 2.1.1.9.1. Uses
Signal unreachability condition to the sending system, but is Signal unreachability condition to the sending system, but is
currently deprecated. A number of systems abort connections in non- currently deprecated. A number of systems abort connections in non-
synchronized states in response to this message, to avoid long delays synchronized states in response to this message, to avoid long delays
in connection establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. in connection establishment attempts [RFC5461].
2.1.1.9.2. Message specification 2.1.1.9.2. Message specification
Defined in [RFC1122]. [RFC1812] states that routers SHOULD NOT Defined in [RFC1122]. [RFC1812] states that routers SHOULD NOT
generate this error message, and states that whichever of Codes 0 generate this error message, and states that whichever of Codes 0
(Network Unreachable) and 1 (Host Unreachable) is appropriate SHOULD (Network Unreachable) and 1 (Host Unreachable) is appropriate SHOULD
be used instead. be used instead.
2.1.1.9.3. Threats 2.1.1.9.3. Threats
There shouldn't be any security threats araising from the use of this An attacker can potentially perform a Denial of Service (DoS) attack
error message. 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 ICMPv6 messages see Section 2.4.f of
[RFC4443].
2.1.1.9.4. Operational/interoperability impact if blocked 2.1.1.9.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or Might lead to long delays between connection establishment attempts
long response times that could have been avoided by aborting non- or long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors]. However, this error message is However, this error message is deprecated, and thus systems should
deprecated, and thus system should not depend on it for any purpose. not depend on it for any purpose.
2.1.1.10. Communication with destination network administratively 2.1.1.10. Communication with destination network administratively
prohibited (code 9) - Deprecated prohibited (code 9) - Deprecated
2.1.1.10.1. Uses 2.1.1.10.1. Uses
Signal unreachability condition to the sending system. A number of Signal unreachability condition to the sending system. A number of
systems abort connections in non-synchronized states in response to systems abort connections in non-synchronized states in response to
this message, to avoid long delays in connection establishment this message, to avoid long delays in connection establishment
attempts [I-D.ietf-tcpm-tcp-soft-errors]. attempts [RFC5461].
2.1.1.10.2. Message specification 2.1.1.10.2. Message specification
This error code is defined in [RFC1122], and was intended for use by This error code is defined in [RFC1122], and was intended for use by
end-to-end encryption devices used by U.S military agencies. end-to-end encryption devices used by U.S military agencies.
[RFC1812] deprecates its use, stating that routers SHOULD use the [RFC1812] deprecates its use, stating that routers SHOULD use the
Code 13 (Communication Administratively Prohibited) if they Code 13 (Communication Administratively Prohibited) if they
administratively filter packets. administratively filter packets.
2.1.1.10.3. Threats 2.1.1.10.3. Threats
May reveal filtering policies. 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 ICMP
messages.
This can be mitigated by rate limiting the rate of IMCP messages
generated. For rate limiting ICMPv6 messages see Section 2.4.f of
[RFC4443].
2.1.1.10.4. Operational/interoperability impact if blocked 2.1.1.10.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors]. However, this error message is However, this error message is deprecated, and thus system should not
deprecated, and thus system should not depend on it for any purpose. depend on it for any purpose.
2.1.1.11. Communication with destination host administratively 2.1.1.11. Communication with destination host administratively
prohibited (code 10) - Deprecated prohibited (code 10) - Deprecated
2.1.1.11.1. Uses 2.1.1.11.1. Uses
Signal unreachability condition to the sending system, but is Signal unreachability condition to the sending system, but is
currently deprecated. A number of systems abort connections in non- currently deprecated. A number of systems abort connections in non-
synchronized states in response to this message, to avoid long delays synchronized states in response to this message, to avoid long delays
in connection establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. in connection establishment attempts [RFC5461].
2.1.1.11.2. Message specification 2.1.1.11.2. Message specification
This error code is defined in [RFC1122], and was intended for use by This error code is defined in [RFC1122], and was intended for use by
end-to-end encryption devices used by U.S military agencies. end-to-end encryption devices used by U.S military agencies.
[RFC1812] deprecates its use, stating that routers SHOULD use the [RFC1812] deprecates its use, stating that routers SHOULD use the
Code 13 (Communication Administratively Prohibited) if they Code 13 (Communication Administratively Prohibited) if they
administratively filter packets. administratively filter packets.
2.1.1.11.3. Threats 2.1.1.11.3. Threats
May reveal filtering policies. 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 ICMP
messages.
This can be mitigated by rate limiting the rate of IMCP messages
generated. For rate limiting ICMPv6 messages see Section 2.4.f of
[RFC4443].
2.1.1.11.4. Operational/interoperability impact if blocked 2.1.1.11.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors]. However, this error message is However, this error message is deprecated, and thus system should not
deprecated, and thus system should not depend on it for any purpose. depend on it for any purpose.
2.1.1.12. Network unreachable for type of service (code 11) 2.1.1.12. Network unreachable for type of service (code 11)
2.1.1.12.1. Uses 2.1.1.12.1. Uses
Signal unreachability condition to the sending system when TOS-based Signal unreachability condition to the sending system when TOS-based
routing is implemented, because the TOS specified for the routes is routing is implemented, because the TOS specified for the routes is
neither the default TOS (0000) nor the TOS of the packet that the neither the default TOS (0000) nor the TOS of the packet that the
router is attempting to route. A number of systems abort connections router is attempting to route. A number of systems abort connections
in non-synchronized states in response to this message, to avoid long in non-synchronized states in response to this message, to avoid long
delays in connection establishment attempts delays in connection establishment attempts [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.12.2. Message specification 2.1.1.12.2. Message specification
Defined in [RFC1122]. Section 4.3.3.1 of [RFC1812] states that if a 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 router cannot forward a packet because the TOS specified for the
routes is neither the default TOS (0000) nor the TOS of the packet 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 that the router is attempting to route, then the router MUST generate
a Destination Unreachable, Code 11 (Network Unreachable for TOS) ICMP a Destination Unreachable, Code 11 (Network Unreachable for TOS) ICMP
message. message.
2.1.1.12.3. Threats 2.1.1.12.3. Threats
May reveal routing policies. 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 IMCP messages
generated. For rate limiting ICMPv6 messages see Section 2.4.f of
[RFC4443].
2.1.1.12.4. Operational/interoperability impact if blocked 2.1.1.12.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.13. Host unreachable for type of service (code 12) 2.1.1.13. Host unreachable for type of service (code 12)
2.1.1.13.1. Uses 2.1.1.13.1. Uses
Signal unreachability condition to the sending system, when TOS-based Signal unreachability condition to the sending system, when TOS-based
routing is implemented, because the TOS specified for the routes is routing is implemented, because the TOS specified for the routes is
neither the default TOS (0000) nor the TOS of the packet that the neither the default TOS (0000) nor the TOS of the packet that the
router is attempting to route. A number of systems abort connections router is attempting to route. A number of systems abort connections
in non-synchronized states in response to this message, to avoid long in non-synchronized states in response to this message, to avoid long
delays in connection establishment attempts delays in connection establishment attempts [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.13.1.1. Message specification 2.1.1.13.1.1. Message specification
Defined in [RFC1122]. Section 4.3.3.1 of [RFC1812] states that this 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 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 network that is directly connected to the router and the router
cannot forward the packet because no route to the destination has a 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 TOS that is either equal to the TOS requested in the packet or is the
default TOS (0000). default TOS (0000).
2.1.1.13.2. Threats 2.1.1.13.2. Threats
May reveal routing policies. 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 IMCP messages
generated. For rate limiting ICMPv6 messages see Section 2.4.f of
[RFC4443].
2.1.1.13.3. Operational/interoperability impact if blocked 2.1.1.13.3. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.14. Communication Administratively Prohibited (code 13) 2.1.1.14. Communication Administratively Prohibited (code 13)
2.1.1.14.1. Uses 2.1.1.14.1. Uses
Signal unreachability condition (due to filtering policies) to the Signal unreachability condition (due to filtering policies) to the
sending system. A number of systems abort connections in non- sending system. A number of systems abort connections in non-
synchronized states in response to this message, to avoid long delays synchronized states in response to this message, to avoid long delays
in connection establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. in connection establishment attempts [RFC5461].
2.1.1.14.2. Message specification 2.1.1.14.2. Message specification
Defined in [RFC1812], and is generated if a router cannot forward a Defined in [RFC1812], and is generated if a router cannot forward a
packet due to administrative filtering. packet due to administrative filtering.
2.1.1.14.3. Threats 2.1.1.14.3. Threats
May reveal filtering policies.
Given that the semantics of this error message are not accurately Given that the semantics of this error message are not accurately
specified, some systems might abort transport connections upon specified, some systems might abort transport connections upon
receipt of this error message. [I-D.ietf-tcpm-icmp-attacks]. receipt of this error message. [I-D.ietf-tcpm-icmp-attacks].
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 ICMPv6 messages see Section
2.4.f of [RFC4443].
2.1.1.14.4. Operational/interoperability impact if blocked 2.1.1.14.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.15. Host Precedence Violation (code 14) 2.1.1.15. Host Precedence Violation (code 14)
2.1.1.15.1. Uses 2.1.1.15.1. Uses
Signal unreachability condition to the sending system. A number of Signal unreachability condition to the sending system. A number of
systems abort connections in non-synchronized states in response to systems abort connections in non-synchronized states in response to
this message, to avoid long delays in connection establishment this message, to avoid long delays in connection establishment
attempts [I-D.ietf-tcpm-tcp-soft-errors]. attempts [RFC5461].
2.1.1.15.2. Message specification 2.1.1.15.2. Message specification
Defined in [RFC1812], and is sent by the first hop router to a host 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 to indicate that a requested precedence is not permitted for the
particular combination of source/destination host or network, upper particular combination of source/destination host or network, upper
layer protocol, and source/destination port layer protocol, and source/destination port
2.1.1.15.3. Threats 2.1.1.15.3. Threats
May reveal routing policies. 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 IMCP
messages generated. For rate limiting ICMPv6 messages see Section
2.4.f of [RFC4443].
2.1.1.15.4. Operational/interoperability impact if blocked 2.1.1.15.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.1.16. Precedence cutoff in effect (code 15) 2.1.1.16. Precedence cutoff in effect (code 15)
2.1.1.16.1. Uses 2.1.1.16.1. Uses
A number of systems abort connections in non-synchronized states in A number of systems abort connections in non-synchronized states in
response to this message, to avoid long delays in connection response to this message, to avoid long delays in connection
establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. establishment attempts [RFC5461].
2.1.1.16.2. Message specification 2.1.1.16.2. Message specification
Defined in [RFC1812], and is sent when the network operators have Defined in [RFC1812], and is sent when the network operators have
imposed a minimum level of precedence required for operation, and a imposed a minimum level of precedence required for operation, and a
datagram was sent with a precedence below this level. datagram was sent with a precedence below this level.
2.1.1.16.3. Threats 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 IMCP
messages generated. For rate limiting ICMPv6 messages see Section
2.4.f of [RFC4443].
2.1.1.16.4. Operational/interoperability impact if blocked 2.1.1.16.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.2. Source Quench (Type 4, Code 0) 2.1.2. Source Quench (Type 4, Code 0)
2.1.2.1. Uses 2.1.2.1. Uses
Originally meant to aid in congestion-control and flow-control. Originally meant to aid in congestion-control and flow-control.
Currently ignored by moost end-system implementations, because of its Currently ignored by most end-system implementations, because of its
security implications (see [I-D.ietf-tcpm-icmp-attacks]. security implications (see [I-D.ietf-tcpm-icmp-attacks].
2.1.2.2. Message specification 2.1.2.2. Message specification
The Source Quench message is defined in [RFC0792]. The Source Quench message is defined in [RFC0792].
Section 3.2.2.3 of [RFC1122] states that host MAY send a Source Section 3.2.2.3 of [RFC1122] states that host MAY send a Source
Quench message if it is approaching, or has reached, the point at Quench message if it is approaching, or has reached, the point at
which it is forced to discard incoming datagrams due to a shortage of which it is forced to discard incoming datagrams due to a shortage of
reassembly buffers or other resources. It also states that if a reassembly buffers or other resources. It also states that if a
skipping to change at page 17, line 16 skipping to change at page 19, line 43
[RFC1812] notes that research seems to suggest that ICMP Source [RFC1812] notes that research seems to suggest that ICMP Source
Quench is an ineffective (and unfair) antidote for congestion, and Quench is an ineffective (and unfair) antidote for congestion, and
states that routers SHOULD NOT send ICMP Source Quench messages in states that routers SHOULD NOT send ICMP Source Quench messages in
response to congestion. A router that does originate Source Quench response to congestion. A router that does originate Source Quench
messages MUST be able to limit the rate at which they are generated. messages MUST be able to limit the rate at which they are generated.
Finally, Section 4.3.3.3 of [RFC1812] states that a router MAY ignore Finally, Section 4.3.3.3 of [RFC1812] states that a router MAY ignore
any ICMP Source Quench messages it receives. any ICMP Source Quench messages it receives.
2.1.2.3. Threats 2.1.2.3. Threats
Can be exploited for performing throughput-reduction attacks
[I-D.ietf-tcpm-icmp-attacks].
2.1.2.4. Operational/interoperability impact if blocked 2.1.2.4. Operational/interoperability impact if blocked
None. None.
2.1.3. Redirect (Type 5) 2.1.3. Redirect (Type 5)
Section 3.2.2.2 of [RFC1122] states that SHOULD NOT send an ICMP 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 Redirect message, and that a host receiving a Redirect message MUST
update its routing information accordingly, and process the ICMP update its routing information accordingly, and process the ICMP
redirect according to the rules stated in Section 3.3.1.2 of redirect according to the rules stated in Section 3.3.1.2 of
skipping to change at page 17, line 42 skipping to change at page 20, line 27
Redirects when choosing a path for a packet originated by the router Redirects when choosing a path for a packet originated by the router
if the router is running a routing protocol or if forwarding is 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 enabled on the router and on the interface over which the packet is
being sent. being sent.
2.1.3.1. Redirect datagrams for the Network (code 0) 2.1.3.1. Redirect datagrams for the Network (code 0)
2.1.3.1.1. Uses 2.1.3.1.1. Uses
Used by routers to communicate end-systems a better first-hop router Used by routers to communicate end-systems a better first-hop router
for a particular network. Currently ignored my a large number of for a particular network. Currently ignored by a large number of
stacks. stacks.
2.1.3.1.2. Message specification 2.1.3.1.2. Message specification
Defined in [RFC0792]. Defined in [RFC0792].
2.1.3.1.3. Threats 2.1.3.1.3. Threats
Can be abused by an attacker to direct all or some traffic to himself Can be abused by an attacker to redirect all or some traffic to
and/or to perform a DoS attack. himself and/or to perform a DoS attack.
2.1.3.1.4. Operational/interoperability impact if blocked 2.1.3.1.4. Operational/interoperability impact if blocked
If the ICMP redirect was originated in some network segment other If the ICMP redirect was originated in some network segment other
than the one it should be forwarded on, there is no operational 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 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 Redirect that was locally generated is blocked, the end-system will
not be informed of the better first-hop for reaching the target not be informed of the better first-hop for reaching the target
network, and thus this would result in less-optimum routes being used network, and thus this would result in less-optimum routes being used
to get the target network. to get the target network.
skipping to change at page 18, line 28 skipping to change at page 21, line 15
Used by routers to communicate end-systems a better first-hop for a Used by routers to communicate end-systems a better first-hop for a
particular host. Currently ignored my a large number of stacks. particular host. Currently ignored my a large number of stacks.
2.1.3.2.2. Message specification 2.1.3.2.2. Message specification
Defined in [RFC0792]. Defined in [RFC0792].
2.1.3.2.3. Threats 2.1.3.2.3. Threats
Can be abused by an attacker to direct all or some traffic to himself Can be abused by an attacker to redirect all or some traffic to
and/or to perform a DoS attack. himself and/or to perform a DoS attack.
2.1.3.2.4. Operational/interoperability impact if blocked 2.1.3.2.4. Operational/interoperability impact if blocked
If the ICMP redirect was originated in some network segment other If the ICMP redirect was originated in some network segment other
than the one it should be forwarded on, there is no operational 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 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 Redirect that was locally generated is blocked, the end-system will
not be informed of the better first-hop for reaching the target not be informed of the better first-hop for reaching the target
network, and thus this would result in less-optimum routes being used network, and thus this would result in less-optimum routes being used
to get the target network. to get the target network.
skipping to change at page 19, line 37 skipping to change at page 22, line 21
Used by routers to communicate end-systems a better first-hop for a Used by routers to communicate end-systems a better first-hop for a
particular host. Currently ignored my a large number of stacks. particular host. Currently ignored my a large number of stacks.
2.1.3.4.2. Message specification 2.1.3.4.2. Message specification
Defined in [RFC0792]. Defined in [RFC0792].
2.1.3.4.3. Threats 2.1.3.4.3. Threats
Can be abused by an attacker to direct all or some traffic to himself Can be abused by an attacker to redirect all or some traffic to
and/or to perform a DoS attack. himself and/or to perform a DoS attack.
2.1.3.4.4. Operational/interoperability impact if blocked 2.1.3.4.4. Operational/interoperability impact if blocked
If the ICMP redirect was originated in some network segment other If the ICMP redirect was originated in some network segment other
than the one it should be forwarded on, there is no operational 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 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 Redirect that was locally generated is blocked, the end-system will
not be informed of the better first-hop for reaching the target not be informed of the better first-hop for reaching the target
network, and thus this would result in less-optimum routes being used network, and thus this would result in less-optimum routes being used
to get the target network. to get the target network.
skipping to change at page 20, line 21 skipping to change at page 22, line 50
(i.e., is destined for the router) a Time Exceeded message, it MUST (i.e., is destined for the router) a Time Exceeded message, it MUST
comply with [RFC1122]. comply with [RFC1122].
2.1.4.1. Time to live exceeded in transit (code 0) 2.1.4.1. Time to live exceeded in transit (code 0)
2.1.4.1.1. Uses 2.1.4.1.1. Uses
Used for the traceroute troubleshooting tool. Signals unreachability Used for the traceroute troubleshooting tool. Signals unreachability
condition due to routing loops. A number of systems abort condition due to routing loops. A number of systems abort
connections in non-synchronized states in response to this message, connections in non-synchronized states in response to this message,
to avoid long delays in connection establishment attempts to avoid long delays in connection establishment attempts [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.4.1.2. Message specification 2.1.4.1.2. Message specification
Defined in [RFC0792]. Defined in [RFC0792].
[RFC1812] states that a router MUST generate a Time Exceeded message [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 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 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, be handled by TCP in the same way as Destination Unreachable codes 0,
1, 5. 1, 5.
2.1.4.1.3. Threats 2.1.4.1.3. Threats
Can be used for network mapping. Can be used for network mapping.
2.1.4.1.4. Operational/interoperability impact if blocked 2.1.4.1.4. Operational/interoperability impact if blocked
Breaks the traceroute tool. May lead to long delays between Breaks the traceroute tool. May lead to long delays between
connection establishment attempts or long response times that could connection establishment attempts or long response times that could
have been avoided by aborting non-synchronized connections in have been avoided by aborting non-synchronized connections in
response to ICMP soft errors [I-D.ietf-tcpm-tcp-soft-errors]. response to ICMP soft errors [RFC5461].
2.1.4.2. fragment reassembly time exceeded (code 1) 2.1.4.2. fragment reassembly time exceeded (code 1)
2.1.4.2.1. Uses 2.1.4.2.1. Uses
Signals fragment reassembly timeout. A number of systems abort Signals fragment reassembly timeout. A number of systems abort
connections in non-synchronized states in response to this message, connections in non-synchronized states in response to this message,
to avoid long delays in connection establishment attempts to avoid long delays in connection establishment attempts [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.4.2.2. Message specification 2.1.4.2.2. Message specification
Defined in [RFC0792]. [RFC0792] states this message may be sent by a Defined in [RFC0792]. [RFC0792] states this message may be sent by a
host reassembling a fragmented datagram if it cannot complete the host reassembling a fragmented datagram if it cannot complete the
reassembly due to missing fragments within its time limit. Section reassembly due to missing fragments within its time limit. Section
4.2.3.9 of [RFC1122] states that this message should be handled by 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. TCP in the same way as Destination Unreachable codes 0, 1, 5.
2.1.4.2.3. Threats 2.1.4.2.3. Threats
May reveal the timeout value used by a system for fragment May reveal the timeout value used by a system for fragment
reassembly, and thus aid in evading NIDSs and fingerprinting the reassembly, and thus aid in evading NIDSs and fingerprinting the
operating system in use by the sender of this error message. operating system in use by the sender of this error message.
2.1.4.2.4. Operational/interoperability impact if blocked 2.1.4.2.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.5. Parameter Problem (Type 12) 2.1.5. Parameter Problem (Type 12)
Section 3.2.2.5 of [RFC1122] states that a host SHOULD generate Section 3.2.2.5 of [RFC1122] states that a host SHOULD generate
Parameter Problem messages. An incoming Parameter Problem message Parameter Problem messages. An incoming Parameter Problem message
MUST be passed to the transport layer, and it MAY be reported to the 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 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, be handled by TCP in the same way as Destination Unreachable codes 0,
1, 5. 1, 5.
skipping to change at page 21, line 48 skipping to change at page 24, line 27
byte indicated by the pointer field MUST be included unchanged in 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 IP header returned with this ICMP message. Section 4.3.2 of the same
document defines an exception to this rule. document defines an exception to this rule.
2.1.5.1. Pointer indicates the error (code 0) 2.1.5.1. Pointer indicates the error (code 0)
2.1.5.1.1. Uses 2.1.5.1.1. Uses
A number of systems abort connections in non-synchronized states in A number of systems abort connections in non-synchronized states in
response to this message, to avoid long delays in connection response to this message, to avoid long delays in connection
establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. establishment attempts [RFC5461].
2.1.5.1.2. Message specification 2.1.5.1.2. Message specification
Defined in [RFC0792]. Defined in [RFC0792].
2.1.5.1.3. Threats 2.1.5.1.3. Threats
May be used to fingerprint the operating system of the host sending May be used to fingerprint the operating system of the host sending
this error message. this error message.
2.1.5.1.4. Operational/interoperability impact if blocked 2.1.5.1.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
2.1.5.2. Required option is missing (code 1) 2.1.5.2. Required option is missing (code 1)
2.1.5.2.1. Uses 2.1.5.2.1. Uses
Used in the military community for a missing security option. Used in the military community for a missing security option.
2.1.5.2.2. Message specification 2.1.5.2.2. Message specification
Defined in Section 3.2.2.5 of [RFC1122]. It was meant to be used in Defined in Section 3.2.2.5 of [RFC1122]. It was meant to be used in
skipping to change at page 24, line 51 skipping to change at page 27, line 27
configuration variables specified for routers, with the specified configuration variables specified for routers, with the specified
defaults. defaults.
2.2.2.1.3. Threats 2.2.2.1.3. Threats
Can be used for network mapping (e.g., learning about routers on a Can be used for network mapping (e.g., learning about routers on a
network segment.). network segment.).
2.2.2.1.4. Operational/interoperability impact if blocked 2.2.2.1.4. Operational/interoperability impact if blocked
This mesages should ot be routed. Therefore, there is no This mesages should not be routed. Therefore, there is no
operational/interoperability impact if blocked. operational/interoperability impact if blocked.
2.2.2.2. Router Advertisement message (type 9, code 0) 2.2.2.2. Router Advertisement message (type 9, code 0)
2.2.2.2.1. Uses 2.2.2.2.1. Uses
Used to advertise routers on a network segment. Used to advertise routers on a network segment.
2.2.2.2.2. Message specification 2.2.2.2.2. Message specification
skipping to change at page 26, line 7 skipping to change at page 28, line 32
Section 3.2.2.8 of [RFC1122] states that a host MAY implement Section 3.2.2.8 of [RFC1122] states that a host MAY implement
Timestamp and Timestamp Reply. For hosts that implement these Timestamp and Timestamp Reply. For hosts that implement these
messages, a number of requirements are stated. messages, a number of requirements are stated.
2.2.3.1.3. Threats 2.2.3.1.3. Threats
Can be used for network mapping, and device fingerprinting. Can be used for network mapping, and device fingerprinting.
2.2.3.1.4. Operational/interoperability impact if blocked 2.2.3.1.4. Operational/interoperability impact if blocked
None. (?) None.
2.2.3.2. Timestamp reply message (type 14, code 0) 2.2.3.2. Timestamp reply message (type 14, code 0)
2.2.3.2.1. Uses 2.2.3.2.1. Uses
May be used as a fall-back mechanism when NTP fails (?). May be used as a fall-back mechanism when NTP fails (?).
2.2.3.2.2. Message specification 2.2.3.2.2. Message specification
Defined in [RFC0792]. Defined in [RFC0792].
2.2.3.2.3. Threats 2.2.3.2.3. Threats
Can be used for network mapping, and device fingerprinting. Can be used for network mapping and device fingerprinting.
2.2.3.2.4. Operational/interoperability impact if blocked 2.2.3.2.4. Operational/interoperability impact if blocked
None. Systems depending on ICMP timestamps for time synchronization Systems will not be able to use ICMP timestamps as a fall-bak
will lose their synchronization. mechanism when NTP fails.
2.2.4. Information Request or Information Reply Message (Deprecated) 2.2.4. Information Request or Information Reply Message (Deprecated)
These messages are described in [RFC0792] as "a way for a host to 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 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 [RFC1122] and Section 4.3.3.7 of [RFC1812] deprecate the use of these
messages. messages.
2.2.4.1. Information request message (type 15, code 0) 2.2.4.1. Information request message (type 15, code 0)
skipping to change at page 27, line 7 skipping to change at page 29, line 30
Defined in [RFC0792]. Defined in [RFC0792].
These messages are described in [RFC0792] as "a way for a host to 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 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 [RFC1122] and Section 4.3.3.7 of [RFC1812] deprecate the use of these
messages. messages.
2.2.4.1.3. Threats 2.2.4.1.3. Threats
Allow for OS and device fingerprintng. Allows for OS (Operating Sytem) and device fingerprintng.
2.2.4.1.4. Operational/interoperability impact if blocked 2.2.4.1.4. Operational/interoperability impact if blocked
None. None.
2.2.4.2. Information reply message (type 16, code 0) 2.2.4.2. Information reply message (type 16, code 0)
2.2.4.2.1. Uses 2.2.4.2.1. Uses
These messages originally provided a basic and simple mechanism for These messages originally provided a basic and simple mechanism for
skipping to change at page 29, line 21 skipping to change at page 31, line 44
3.1.1. Destination Unreachable (Type 1) 3.1.1. Destination Unreachable (Type 1)
3.1.1.1. No route to destination (code 0) 3.1.1.1. No route to destination (code 0)
3.1.1.1.1. Uses 3.1.1.1.1. Uses
Used to indicate that the ofending packet cannot be delivered because Used to indicate that the ofending packet cannot be delivered because
there is no route towords the destination address. A number of there is no route towords the destination address. A number of
systems abort connections in non-synchronized states in response to systems abort connections in non-synchronized states in response to
this message, to avoid long delays in connection establishment this message, to avoid long delays in connection establishment
attempts [I-D.ietf-tcpm-tcp-soft-errors]. attempts [RFC5461].
3.1.1.1.2. Message specification 3.1.1.1.2. Message specification
Defined in [RFC4443]. Defined in [RFC4443].
3.1.1.1.3. Threats 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.f of [RFC4443].
3.1.1.1.4. Operational/interoperability impact if blocked 3.1.1.1.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
3.1.1.2. Communication with destination administratively prohibited 3.1.1.2. Communication with destination administratively prohibited
(code 1) (code 1)
3.1.1.2.1. Uses 3.1.1.2.1. Uses
A number of systems abort connections in non-synchronized states in A number of systems abort connections in non-synchronized states in
response to this message, to avoid long delays in connection response to this message, to avoid long delays in connection
establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. establishment attempts [RFC5461].
3.1.1.2.2. Message specification 3.1.1.2.2. Message specification
Defined in [RFC4443]. Defined in [RFC4443].
3.1.1.2.3. Threats 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.f of [RFC4443].
3.1.1.2.4. Operational/interoperability impact if blocked 3.1.1.2.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
3.1.1.3. Beyond scope of source address (code 2) 3.1.1.3. Beyond scope of source address (code 2)
3.1.1.3.1. Uses 3.1.1.3.1. Uses
A number of systems abort connections in non-synchronized states in A number of systems abort connections in non-synchronized states in
response to this message, to avoid long delays in connection response to this message, to avoid long delays in connection
establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. establishment attempts [RFC5461].
3.1.1.3.2. Message specification 3.1.1.3.2. Message specification
Defined in [RFC4443]. Defined in [RFC4443].
3.1.1.3.3. Threats 3.1.1.3.3. Threats
3.1.1.3.4. Operational/interoperability impact if blocked 3.1.1.3.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
3.1.1.4. Address unreachable (code 3) 3.1.1.4. Address unreachable (code 3)
3.1.1.4.1. Uses 3.1.1.4.1. Uses
A number of systems abort connections in non-synchronized states in A number of systems abort connections in non-synchronized states in
response to this message, to avoid long delays in connection response to this message, to avoid long delays in connection
establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. establishment attempts [RFC5461].
3.1.1.4.2. Message specification 3.1.1.4.2. Message specification
Defined in [RFC4443]. Defined in [RFC4443].
3.1.1.4.3. Threats 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.f of [RFC4443].
3.1.1.4.4. Operational/interoperability impact if blocked 3.1.1.4.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
3.1.1.5. Port unreachable (code 4) 3.1.1.5. Port unreachable (code 4)
3.1.1.5.1. Uses 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 3.1.1.5.2. Message specification
Defined in [RFC4443]. Defined in [RFC4443].
3.1.1.5.3. Threats 3.1.1.5.3. Threats
This error message might used to perform Denial of Service (DoS) This error message might used to perform Denial of Service (DoS)
attacks against transport protocols. [I-D.ietf-tcpm-icmp-attacks] attacks against transport protocols. [I-D.ietf-tcpm-icmp-attacks]
describes the use of this error message to attack TCP connections. 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.f of [RFC4443].
3.1.1.5.4. Operational/interoperability impact if blocked 3.1.1.5.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
3.1.1.6. Source address failed ingress/egress policy (code 5) 3.1.1.6. Source address failed ingress/egress policy (code 5)
3.1.1.6.1. Uses 3.1.1.6.1. Uses
A number of systems abort connections in non-synchronized states in A number of systems abort connections in non-synchronized states in
response to this message, to avoid long delays in connection response to this message, to avoid long delays in connection
establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. establishment attempts [RFC5461].
3.1.1.6.2. Message specification 3.1.1.6.2. Message specification
Defined in [RFC4443]. Defined in [RFC4443].
3.1.1.6.3. Threats 3.1.1.6.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.f of [RFC4443].
3.1.1.6.4. Operational/interoperability impact if blocked 3.1.1.6.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
3.1.1.7. Reject route to destination (code 6) 3.1.1.7. Reject route to destination (code 6)
3.1.1.7.1. Uses 3.1.1.7.1. Uses
A number of systems abort connections in non-synchronized states in A number of systems abort connections in non-synchronized states in
response to this message, to avoid long delays in connection response to this message, to avoid long delays in connection
establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. establishment attempts [RFC5461].
3.1.1.7.2. Message specification 3.1.1.7.2. Message specification
Defined in [RFC4443]. Defined in [RFC4443].
3.1.1.7.3. Threats 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.f of [RFC4443].
3.1.1.7.4. Operational/interoperability impact if blocked 3.1.1.7.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
3.1.2. Packet Too Big Message (Type 2, code 0) 3.1.2. Packet Too Big Message (Type 2, code 0)
3.1.2.1. Uses 3.1.2.1. Uses
Used for the Path-MTU discovery mechanism for IPv6 defined in Used for the Path-MTU discovery mechanism for IPv6 defined in
[RFC1981]. [RFC1981].
3.1.2.2. Message specification 3.1.2.2. Message specification
Defined in [RFC4443]. Defined in [RFC4443].
3.1.2.3. Threats 3.1.2.3. Threats
skipping to change at page 33, line 4 skipping to change at page 36, line 25
This error message can be used to perform Denial of Service (DoS) This error message can be used to perform Denial of Service (DoS)
attacks against transport protocols. [I-D.ietf-tcpm-icmp-attacks] attacks against transport protocols. [I-D.ietf-tcpm-icmp-attacks]
describes the use of this error message to attack TCP connections. describes the use of this error message to attack TCP connections.
3.1.2.4. Operational/interoperability impact if blocked 3.1.2.4. Operational/interoperability impact if blocked
Filtering this error message will break the Path-MTU Discovery Filtering this error message will break the Path-MTU Discovery
mechanism defined in [RFC1981]. mechanism defined in [RFC1981].
3.1.3. Time Exceeded Message (Type 3) 3.1.3. Time Exceeded Message (Type 3)
3.1.3.1. Hop limit exceeded in transit (code 0) 3.1.3.1. Hop limit exceeded in transit (code 0)
3.1.3.1.1. Uses 3.1.3.1.1. Uses
A number of systems abort connections in non-synchronized states in A number of systems abort connections in non-synchronized states in
response to this message, to avoid long delays in connection response to this message, to avoid long delays in connection
establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. establishment attempts [RFC5461].
3.1.3.1.2. Message specification 3.1.3.1.2. Message specification
Defined in [RFC4443]. Defined in [RFC4443].
3.1.3.1.3. Threats 3.1.3.1.3. Threats
May be used for network mapping.
3.1.3.1.4. Operational/interoperability impact if blocked 3.1.3.1.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
3.1.3.2. Fragment reassembly time exceeded (code 1) 3.1.3.2. Fragment reassembly time exceeded (code 1)
3.1.3.2.1. Uses 3.1.3.2.1. Uses
Used to signal a timeout in fragment reassembly. A number of systems Used to signal a timeout in fragment reassembly. A number of systems
abort connections in non-synchronized states in response to this abort connections in non-synchronized states in response to this
message, to avoid long delays in connection establishment attempts message, to avoid long delays in connection establishment attempts
[I-D.ietf-tcpm-tcp-soft-errors]. [RFC5461].
3.1.3.2.2. Message specification 3.1.3.2.2. Message specification
Defined in [RFC4443]. Defined in [RFC4443].
3.1.3.2.3. Threats 3.1.3.2.3. Threats
May reveal the timeout value used by a system for fragment May reveal the timeout value used by a system for fragment
reassembly, and thus help to perform remote OS fingerprinting. reassembly, and thus help to perform remote OS fingerprinting.
Additionally, revealing the fragment reassembly timeout value may Additionally, revealing the fragment reassembly timeout value may
help an attacker to evade a NIDS. help an attacker to evade a NIDS.
3.1.3.2.4. Operational/interoperability impact if blocked 3.1.3.2.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
3.1.4. Parameter Problem Message (Type 4) 3.1.4. Parameter Problem Message (Type 4)
3.1.4.1. Erroneous header field encountered (code 0) 3.1.4.1. Erroneous header field encountered (code 0)
3.1.4.1.1. Uses 3.1.4.1.1. Uses
A number of systems abort connections in non-synchronized states in A number of systems abort connections in non-synchronized states in
response to this message, to avoid long delays in connection response to this message, to avoid long delays in connection
establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. establishment attempts [RFC5461].
3.1.4.1.2. Message specification 3.1.4.1.2. Message specification
Defined in [RFC4443]. Defined in [RFC4443].
3.1.4.1.3. Threats 3.1.4.1.3. Threats
This error message might used to perform Denial of Service (DoS) This error message might used to perform Denial of Service (DoS)
attacks against transport protocols. [I-D.ietf-tcpm-icmp-attacks] attacks against transport protocols. [I-D.ietf-tcpm-icmp-attacks]
describes the use of this error message to attack TCP connections. 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.f of
[RFC4443].
3.1.4.1.4. Operational/interoperability impact if blocked 3.1.4.1.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
3.1.4.2. Unrecognized Next Header type encountered (code 1) 3.1.4.2. Unrecognized Next Header type encountered (code 1)
3.1.4.2.1. Uses 3.1.4.2.1. Uses
A number of systems abort connections in non-synchronized states in A number of systems abort connections in non-synchronized states in
response to this message, to avoid long delays in connection response to this message, to avoid long delays in connection
establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. establishment attempts [RFC5461].
3.1.4.2.2. Message specification 3.1.4.2.2. Message specification
Defined in [RFC4443]. Defined in [RFC4443].
3.1.4.2.3. Threats 3.1.4.2.3. Threats
This error message might used to perform Denial of Service (DoS) This error message might used to perform Denial of Service (DoS)
attacks against transport protocols. [I-D.ietf-tcpm-icmp-attacks] attacks against transport protocols. [I-D.ietf-tcpm-icmp-attacks]
describes the use of this error message to attack TCP connections. 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.f of
[RFC4443].
3.1.4.2.4. Operational/interoperability impact if blocked 3.1.4.2.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
3.1.4.3. Unrecognized IPv6 option encountered (code 2) 3.1.4.3. Unrecognized IPv6 option encountered (code 2)
3.1.4.3.1. Uses 3.1.4.3.1. Uses
A number of systems abort connections in non-synchronized states in A number of systems abort connections in non-synchronized states in
response to this message, to avoid long delays in connection response to this message, to avoid long delays in connection
establishment attempts [I-D.ietf-tcpm-tcp-soft-errors]. establishment attempts [RFC5461].
3.1.4.3.2. Message specification 3.1.4.3.2. Message specification
Defined in [RFC4443]. Defined in [RFC4443].
3.1.4.3.3. Threats 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.f of
[RFC4443].
3.1.4.3.4. Operational/interoperability impact if blocked 3.1.4.3.4. Operational/interoperability impact if blocked
May lead to long delays between connection establishment attempts or May lead to long delays between connection establishment attempts or
long response times that could have been avoided by aborting non- long response times that could have been avoided by aborting non-
synchronized connections in response to ICMP soft errors synchronized connections in response to ICMP soft errors [RFC5461].
[I-D.ietf-tcpm-tcp-soft-errors].
3.1.5. Private experimentation (Type 100) 3.1.5. Private experimentation (Type 100)
3.1.5.1. Uses 3.1.5.1. Uses
3.1.5.2. Message specification 3.1.5.2. Message specification
Defined in [RFC4443]. Defined in [RFC4443].
3.1.5.3. Threats 3.1.5.3. Threats
skipping to change at page 38, line 18 skipping to change at page 42, line 12
Defined in [RFC4443]. Defined in [RFC4443].
3.2.4.3. Threats 3.2.4.3. Threats
3.2.4.4. Operational/interoperability impact if blocked 3.2.4.4. Operational/interoperability impact if blocked
4. Security Considerations 4. Security Considerations
This document does not introduce any new security implications. It This document does not introduce any new security implications. It
attempts to help mitigate security threats that rely on ICMP through attempts to help mitigate security threats that rely on ICMP or
packet filtering and rate-limiting. ICMPv6 messages, through packet filtering and rate-limiting.
5. Acknowledgements 5. Acknowledgements
The authors would like to thank Alfred Hoenes for his valuable The authors would like to thank (in alphabetical order) Steinthor
feedback on earlier versions of this document. Bjarnason and Alfred Hoenes for their valuable feedback on earlier
versions of this document.
The survey of ICMP specifications is based on a yet-to-be-published The survey of ICMP specifications is based on a yet-to-be-published
internet-draft on ICMP by Fernando Gont and Carlos Pignataro. This internet-draft on ICMP by Fernando Gont and Carlos Pignataro. This
document borrows its structure from the "ICMP filtering" wiki started document borrows its structure from the "ICMP filtering" wiki started
by George Jones. by George Jones.
Fernando would like to thank Paula Piedra for her love and support.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
skipping to change at page 39, line 26 skipping to change at page 43, line 19
Control", RFC 2581, April 1999. Control", RFC 2581, April 1999.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
6.2. Informative References 6.2. Informative References
[I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP", Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-03 (work in progress), draft-ietf-tcpm-icmp-attacks-06 (work in progress),
March 2008. August 2009.
[I-D.ietf-tcpm-tcp-soft-errors] [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
Gont, F., "TCP's Reaction to Soft Errors", February 2009.
draft-ietf-tcpm-tcp-soft-errors-08 (work in progress),
April 2008.
[icmp-scanning] [icmp-scanning]
Arkin, 0., "ICMP Usage in Scanning: The Complete Know- Arkin, 0., "ICMP Usage in Scanning: The Complete Know-
How", http://www.sys-security.com/archive/papers/ How", http://www.sys-security.com/archive/papers/
ICMP_Scanning_v3.0.pdf, 2001. ICMP_Scanning_v3.0.pdf, 2001.
[smurf] CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of- [smurf] CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of-
Service Attacks", Service Attacks",
http://www.cert.org/advisories/CA-1998-01.html, 1998. http://www.cert.org/advisories/CA-1998-01.html, 1998.
Appendix A. Change log (to be removed before publication of the Appendix A. Change log (to be removed before publication of the
document as an RFC) document as an RFC)
A.1. Changes from draft-gont-opsec-icmp-filtering-00 A.1. Changes from draft-ietf-opsec-icmp-filtering-00
o Populated a few more sections
o Updated outdated references
o Minor editorial changes
A.2. Changes from draft-gont-opsec-icmp-filtering-00
o Resubmitted the Internet Draft as "draft-ietf" o Resubmitted the Internet Draft as "draft-ietf"
o Swapped order of the "Uses" and "Message specification" sections o Swapped order of the "Uses" and "Message specification" sections
for each of the ICMP messages, as suggested by Alfred Hoenes. for each of the ICMP messages, as suggested by Alfred Hoenes.
o Populated a number of sections of the draft. o Populated a number of sections of the draft.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
Universidad Tecnologica Nacional / Facultad Regional Haedo Universidad Tecnologica Nacional / Facultad Regional Haedo
Evaristo Carriego 2644 Evaristo Carriego 2644
skipping to change at page 41, line 4 skipping to change at line 2052
URI: http://www.gont.com.ar URI: http://www.gont.com.ar
Guillermo Gont Guillermo Gont
Universidad Tecnologica Nacional / Facultad Regional Haedo Universidad Tecnologica Nacional / Facultad Regional Haedo
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: guillermo@gont.com.ar Email: guillermo@gont.com.ar
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 127 change blocks. 
253 lines changed or deleted 479 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/