draft-ietf-tcpm-icmp-attacks-12.txt   rfc5927.txt 
TCP Maintenance and Minor F. Gont Internet Engineering Task Force (IETF) F. Gont
Extensions (tcpm) UTN/FRH Request for Comments: 5927 UTN/FRH
Internet-Draft March 30, 2010 Category: Informational July 2010
Intended status: Informational ISSN: 2070-1721
Expires: October 1, 2010
ICMP attacks against TCP ICMP Attacks against TCP
draft-ietf-tcpm-icmp-attacks-12.txt
Abstract Abstract
This document discusses the use of the Internet Control Message This document discusses the use of the Internet Control Message
Protocol (ICMP) to perform a variety of attacks against the Protocol (ICMP) to perform a variety of attacks against the
Transmission Control Protocol (TCP). Additionally, describes a Transmission Control Protocol (TCP). Additionally, this document
number of widely implemented modifications to TCP's handling of ICMP describes a number of widely implemented modifications to TCP's
error messages that help to mitigate these issues. handling of ICMP error messages that help to mitigate these issues.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on October 1, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5927.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5 2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5
2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 5 2.1.1. ICMP for IP version 4 (ICMPv4) . . . . . . . . . . . . 5
2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6 2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6
2.2. Handling of ICMP error messages . . . . . . . . . . . . . 6 2.2. Handling of ICMP Error Messages . . . . . . . . . . . . . 6
2.3. Handling of ICMP error messages in the context of IPsec . 7 2.3. Handling of ICMP Error Messages in the Context of IPsec . 7
3. Constraints in the possible solutions . . . . . . . . . . . . 8 3. Constraints in the Possible Solutions . . . . . . . . . . . . 8
4. General counter-measures against ICMP attacks . . . . . . . . 10 4. General Counter-Measures against ICMP Attacks . . . . . . . . 10
4.1. TCP sequence number checking . . . . . . . . . . . . . . . 10 4.1. TCP Sequence Number Checking . . . . . . . . . . . . . . . 10
4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 11 4.2. Port Randomization . . . . . . . . . . . . . . . . . . . . 11
4.3. Filtering ICMP error messages based on the ICMP payload . 11 4.3. Filtering ICMP Error Messages Based on the ICMP Payload . 11
5. Blind connection-reset attack . . . . . . . . . . . . . . . . 12 5. Blind Connection-Reset Attack . . . . . . . . . . . . . . . . 12
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Attack-specific counter-measures . . . . . . . . . . . . . 13 5.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 13
6. Blind throughput-reduction attack . . . . . . . . . . . . . . 15 6. Blind Throughput-Reduction Attack . . . . . . . . . . . . . . 16
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Attack-specific counter-measures . . . . . . . . . . . . . 16 6.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 16
7. Blind performance-degrading attack . . . . . . . . . . . . . . 16 7. Blind Performance-Degrading Attack . . . . . . . . . . . . . . 16
7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Attack-specific counter-measures . . . . . . . . . . . . . 18 7.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 18
7.3. The counter-measure for the PMTUD attack in action . . . . 21 7.3. The Counter-Measure for the PMTUD Attack in Action . . . . 22
7.3.1. Normal operation for bulk transfers . . . . . . . . . 22 7.3.1. Normal Operation for Bulk Transfers . . . . . . . . . 22
7.3.2. Operation during Path-MTU changes . . . . . . . . . . 23 7.3.2. Operation during Path-MTU Changes . . . . . . . . . . 24
7.3.3. Idle connection being attacked . . . . . . . . . . . . 25 7.3.3. Idle Connection Being Attacked . . . . . . . . . . . . 25
7.3.4. Active connection being attacked after discovery 7.3.4. Active Connection Being Attacked after Discovery
of the Path-MTU . . . . . . . . . . . . . . . . . . . 25 of the Path-MTU . . . . . . . . . . . . . . . . . . . 26
7.3.5. TCP peer attacked when sending small packets just 7.3.5. TCP Peer Attacked when Sending Small Packets Just
after the three-way handshake . . . . . . . . . . . . 26 after the Three-Way Handshake . . . . . . . . . . . . 26
7.4. Pseudo-code for the counter-measure for the blind 7.4. Pseudo-Code for the Counter-Measure for the Blind
performance-degrading attack . . . . . . . . . . . . . . . 27 Performance-Degrading Attack . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 10.2. Informative References . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Changes from previous versions of the draft (to
be removed by the RFC Editor before publishing
this document as an RFC) . . . . . . . . . . . . . . 36
A.1. Changes from draft-ietf-tcpm-icmp-attacks-10 . . . . . . . 36
A.2. Changes from draft-ietf-tcpm-icmp-attacks-09 . . . . . . . 36
A.3. Changes from draft-ietf-tcpm-icmp-attacks-08 . . . . . . . 36
A.4. Changes from draft-ietf-tcpm-icmp-attacks-07 . . . . . . . 36
A.5. Changes from draft-ietf-tcpm-icmp-attacks-06 . . . . . . . 36
A.6. Changes from draft-ietf-tcpm-icmp-attacks-05 . . . . . . . 37
A.7. Changes from draft-ietf-tcpm-icmp-attacks-04 . . . . . . . 37
A.8. Changes from draft-ietf-tcpm-icmp-attacks-03 . . . . . . . 37
A.9. Changes from draft-ietf-tcpm-icmp-attacks-02 . . . . . . . 37
A.10. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 37
A.11. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 38
A.12. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 38
A.13. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 38
A.14. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 39
A.15. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 39
A.16. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 39
A.17. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, ICMP [RFC0792] [RFC4443] is a fundamental part of the TCP/IP protocol
and is used mainly for reporting network error conditions. However, suite, and is used mainly for reporting network error conditions.
the current specifications do not recommend any kind of validation However, the current specifications do not recommend any kind of
checks on the received ICMP error messages, thus allowing variety of validation checks on the received ICMP error messages, thus allowing
attacks against TCP [RFC0793] by means of ICMP, which include blind a variety of attacks against TCP [RFC0793] by means of ICMP, which
connection-reset, blind throughput-reduction, and blind performance- include blind connection-reset, blind throughput-reduction, and blind
degrading attacks. All of these attacks can be performed even being performance-degrading attacks. All of these attacks can be performed
off-path, without the need to sniff the packets that correspond to even when the attacker is off-path, without the need to sniff the
the attacked TCP connection. packets that correspond to the attacked TCP connection.
While the possible security implications of ICMP have been known in While the possible security implications of ICMP have been known in
the research community for a long time, there has never been an the research community for a long time, there has never been an
official proposal on how to deal with these vulnerabilities. In official proposal on how to deal with these vulnerabilities. In
2005, a disclosure process was carried out by the UK's National 2005, a disclosure process was carried out by the UK's National
Infrastructure Security Co-ordination Centre (NISCC) (now CPNI, Infrastructure Security Co-ordination Centre (NISCC) (now CPNI,
Centre for the Protection of National Infrastructure), with the Centre for the Protection of National Infrastructure), with the
collaboration of other computer emergency response teams. A large collaboration of other computer emergency response teams. A large
number of implementations were found vulnerable to either all or a number of implementations were found vulnerable to either all or a
subset of the attacks discussed in this document [NISCC][US-CERT]. subset of the attacks discussed in this document [NISCC][US-CERT].
skipping to change at page 5, line 44 skipping to change at page 4, line 44
This document aims to raise awareness of the use of ICMP to perform a This document aims to raise awareness of the use of ICMP to perform a
variety of attacks against TCP, and discusses several counter- variety of attacks against TCP, and discusses several counter-
measures that eliminate or minimize the impact of these attacks. measures that eliminate or minimize the impact of these attacks.
Most of the these counter-measures can be implemented while still Most of the these counter-measures can be implemented while still
remaining compliant with the current specifications, as they simply remaining compliant with the current specifications, as they simply
describe reasons for not taking the advice provided in the describe reasons for not taking the advice provided in the
specifications in terms of "SHOULDs", but still comply with the specifications in terms of "SHOULDs", but still comply with the
requirements stated as "MUSTs". requirements stated as "MUSTs".
We note that the counter-measures discussed in this document are not We note that the counter-measures discussed in this document are not
part of standard TCP behavior and this document does not change that part of standard TCP behavior, and this document does not change that
state of affairs. The consensus of the TCPM WG (TCP Maintenance and state of affairs. The consensus of the TCPM WG (TCP Maintenance and
Minor Extensions Working Group) was to document this widespread Minor Extensions Working Group) was to document this widespread
implementation of nonstandard TCP behavior but to not change the TCP implementation of nonstandard TCP behavior but to not change the TCP
standard. standard.
Section 2 provides background information on ICMP. Section 3 Section 2 provides background information on ICMP. Section 3
discusses the constraints in the general counter-measures that can be discusses the constraints in the general counter-measures that can be
implemented against the attacks described in this document. implemented against the attacks described in this document.
Section 4 describes several general validation checks that can be Section 4 describes several general validation checks that can be
skipping to change at page 6, line 26 skipping to change at page 5, line 26
2.1. The Internet Control Message Protocol (ICMP) 2.1. The Internet Control Message Protocol (ICMP)
The Internet Control Message Protocol (ICMP) is used in the Internet The Internet Control Message Protocol (ICMP) is used in the Internet
architecture mainly to perform the fault-isolation function, that is, architecture mainly to perform the fault-isolation function, that is,
the group of actions that hosts and routers take to determine that the group of actions that hosts and routers take to determine that
there is some network failure [RFC0816]. there is some network failure [RFC0816].
When an intermediate router detects a network problem while trying to When an intermediate router detects a network problem while trying to
forward an IP packet, it will usually send an ICMP error message to forward an IP packet, it will usually send an ICMP error message to
the source system, to inform about the network problem taking place. the source system, to inform the source system of the network problem
In the same way, there are a number of scenarios in which an end- taking place. In the same way, there are a number of scenarios in
system may generate an ICMP error message if it finds a problem while which an end-system may generate an ICMP error message if it finds a
processing a datagram. The received ICMP errors are handed to the problem while processing a datagram. The received ICMP errors are
corresponding transport-protocol instance, which will usually perform handed to the corresponding transport-protocol instance, which will
a fault recovery function. usually perform a fault recovery function.
It is important to note that ICMP error messages are transmitted It is important to note that ICMP error messages are transmitted
unreliably, and may be discarded due to data corruption, network unreliably and may be discarded due to data corruption, network
congestion or rate-limiting. Thus, while they provide useful congestion, or rate-limiting. Thus, while they provide useful
information, upper layer protocols cannot depend on ICMP for correct information, upper-layer protocols cannot depend on ICMP for correct
operation. operation.
It should be noted that are no timeliness requirements for ICMP error It should be noted that there are no timeliness requirements for ICMP
messages. ICMP error messages could be delayed for various reasons, error messages. ICMP error messages could be delayed for various
and at least in theory could be received with an arbitrarily long reasons, and at least in theory could be received with an arbitrarily
delay. For example, there are no existing requirements that a router long delay. For example, there are no existing requirements that a
flushes any queued ICMP error messages when it is rebooted. router flush any queued ICMP error messages when it is rebooted.
2.1.1. ICMP for IP version 4 (ICMP) 2.1.1. ICMP for IP version 4 (ICMPv4)
[RFC0792] specifies the Internet Control Message Protocol (ICMP) to [RFC0792] specifies the Internet Control Message Protocol (ICMP) to
be used with the Internet Protocol version 4 (IPv4). It defines, be used with the Internet Protocol version 4 (IPv4) -- henceforth
among other things, a number of error messages that can be used by "ICMPv4". It defines, among other things, a number of error messages
end-systems and intermediate systems to report errors to the sending that can be used by end-systems and intermediate systems to report
system. The Host Requirements RFC [RFC1122] classifies ICMP error errors to the sending system. The Host Requirements RFC [RFC1122]
messages into those that indicate "soft errors", and those that classifies ICMPv4 error messages into those that indicate "soft
indicate "hard errors", thus roughly defining the semantics of them. errors", and those that indicate "hard errors", thus roughly defining
the semantics of them.
The ICMP specification [RFC0792] also defines the ICMP Source Quench The ICMPv4 specification [RFC0792] also defines the ICMPv4 Source
message (type 4, code 0), which is meant to provide a mechanism for Quench message (type 4, code 0), which is meant to provide a
flow control and congestion control. mechanism for flow control and congestion control.
[RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD), [RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD),
which makes use of ICMP error messages of type 3 (Destination which makes use of ICMPv4 error messages of type 3 (Destination
Unreachable), code 4 (fragmentation needed and DF bit set) to allow Unreachable), code 4 (fragmentation needed and DF bit set) to allow
systems to determine the MTU of an arbitrary internet path. systems to determine the MTU of an arbitrary internet path.
Finally, [RFC4884] redefines selected ICMP messages to include an Finally, [RFC4884] redefines selected ICMPv4 messages to include an
extension structure and a length attribute, such that those ICMP extension structure and a length attribute, such that those ICMPv4
messages can carry additional information by encoding that messages can carry additional information by encoding that
information in the extension structure. information in the extension structure.
Appendix D of [RFC4301] provides information about which ICMP error Appendix D of [RFC4301] provides information about which ICMPv4 error
messages are produced by hosts, intermediate routers, or both. messages are produced by hosts, intermediate routers, or both.
2.1.2. ICMP for IP version 6 (ICMPv6) 2.1.2. ICMP for IP version 6 (ICMPv6)
[RFC4443] specifies the Internet Control Message Protocol (ICMPv6) to [RFC4443] specifies the Internet Control Message Protocol (ICMPv6) to
be used with the Internet Protocol version 6 (IPv6) [RFC2460]. be used with the Internet Protocol version 6 (IPv6) [RFC2460].
[RFC4443] defines the "Packet Too Big" (type 2, code 0) error [RFC4443] defines the "Packet Too Big" (type 2, code 0) error
message, that is analogous to the ICMP "fragmentation needed and DF message, which is analogous to the ICMPv4 "fragmentation needed and
bit set" (type 3, code 4) error message. [RFC1981] defines the Path DF bit set" (type 3, code 4) error message. [RFC1981] defines the
MTU Discovery mechanism for IP Version 6, that makes use of these Path MTU Discovery mechanism for IP version 6, which makes use of
messages to determine the MTU of an arbitrary internet path. these messages to determine the MTU of an arbitrary internet path.
Finally, [RFC4884] redefines selected ICMP messages to include an Finally, [RFC4884] redefines selected ICMPv6 messages to include an
extension structure and a length attribute, such that those ICMP extension structure and a length attribute, such that those ICMPv6
messages can carry additional information by encoding that messages can carry additional information by encoding that
information in the extension structure. information in the extension structure.
Appendix D of [RFC4301] provides information about which ICMPv6 error Appendix D of [RFC4301] provides information about which ICMPv6 error
messages are produced by hosts, intermediate routers, or both. messages are produced by hosts, intermediate routers, or both.
2.2. Handling of ICMP error messages 2.2. Handling of ICMP Error Messages
The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that a The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that
TCP MUST act on an ICMP error message passed up from the IP layer, TCP MUST act on an ICMP error message passed up from the IP layer,
directing it to the connection that triggered the error. directing it to the connection that triggered the error.
In order to allow ICMP messages to be demultiplexed by the receiving In order to allow ICMP messages to be demultiplexed by the receiving
system, part of the original packet that triggered the message is system, part of the original packet that triggered the message is
included in the payload of the ICMP error message. Thus, the included in the payload of the ICMP error message. Thus, the
receiving system can use that information to match the ICMP error to receiving system can use that information to match the ICMP error to
the transport protocol instance that triggered it. the transport protocol instance that triggered it.
Neither the Host Requirements RFC [RFC1122] nor the original TCP Neither the Host Requirements RFC [RFC1122] nor the original TCP
specification [RFC0793] recommend any validation checks on the specification [RFC0793] recommends any validation checks on the
received ICMP messages. Thus, as long as the ICMP payload contains received ICMP messages. Thus, as long as the ICMP payload contains
the information that identifies an existing communication instance, the information that identifies an existing communication instance,
it will be processed by the corresponding transport-protocol it will be processed by the corresponding transport-protocol
instance, and the corresponding action will be performed. instance, and the corresponding action will be performed.
Therefore, in the case of TCP, an attacker could send a crafted ICMP Therefore, in the case of TCP, an attacker could send a crafted ICMP
error message to the attacked system, and, as long as he is able to error message to the attacked system, and, as long as he is able to
guess the four-tuple (i.e., Source IP Address, Source TCP port, guess the four-tuple (i.e., Source IP Address, Source TCP port,
Destination IP Address, and Destination TCP port) that identifies the Destination IP Address, and Destination TCP port) that identifies the
communication instance to be attacked, he will be able to use ICMP to communication instance to be attacked, he will be able to use ICMP to
perform a variety of attacks. perform a variety of attacks.
Generally, the four-tuple required to perform these attacks is not Generally, the four-tuple required to perform these attacks is not
known. However, as discussed in [Watson] and [RFC4953], there are a known. However, as discussed in [Watson] and [RFC4953], there are a
number of scenarios (notably that of TCP connections established number of scenarios (notably that of TCP connections established
between two BGP routers [RFC4271]), in which an attacker may be able between two BGP routers [RFC4271]) in which an attacker may be able
to know or guess the four-tuple that identifies a TCP connection. In to know or guess the four-tuple that identifies a TCP connection. In
such a case, if we assume the attacker knows the two systems involved such a case, if we assume the attacker knows the two systems involved
in the TCP connection to be attacked, both the client-side and the in the TCP connection to be attacked, both the client-side and the
server-side IP addresses could be known or be within a reasonable server-side IP addresses could be known or be within a reasonable
number of possibilities. Furthermore, as most Internet services use number of possibilities. Furthermore, as most Internet services use
the so-called "well-known" ports, only the client port number might the so-called "well-known" ports, only the client port number might
need to be guessed. In such a scenario, an attacker would need to need to be guessed. In such a scenario, an attacker would need to
send, in principle, at most 65536 packets to perform any of the send, in principle, at most 65536 packets to perform any of the
attacks described in this document. These issues are exacerbated by attacks described in this document. These issues are exacerbated by
the fact that most systems choose the port numbers they use for the fact that most systems choose the port numbers they use for
outgoing connections from a subset of the whole port number space, outgoing connections from a subset of the whole port number space,
thus reducing the amount of work needed to successfully perform these thus reducing the amount of work needed to successfully perform these
attacks. attacks.
The need to be more cautious when processing received ICMP error The need to be more cautious when processing received ICMP error
messages in order to mitigate or eliminate the impact of the attacks messages in order to mitigate or eliminate the impact of the attacks
described in this document has been documented by the Internet described in this RFC has been documented by the Internet
Architecture Board (IAB) in [RFC4907]. Architecture Board (IAB) in [RFC4907].
2.3. Handling of ICMP error messages in the context of IPsec 2.3. Handling of ICMP Error Messages in the Context of IPsec
Section 5.2 of [RFC4301] describes the processing of inbound IP Section 5.2 of [RFC4301] describes the processing of inbound IP
Traffic in the case of "unprotected-to-protected". In the case of traffic in the case of "unprotected-to-protected". In the case of
ICMP, when an unprotected ICMP error message is received, it is ICMP, when an unprotected ICMP error message is received, it is
matched to the corresponding security association by means of the SPI matched to the corresponding security association by means of the SPI
(Security Parameters Index) included in the payload of the ICMP error (Security Parameters Index) included in the payload of the ICMP error
message. Then, local policy is applied to determine whether to message. Then, local policy is applied to determine whether to
accept or reject the message and, if accepted, what action to take as accept or reject the message and, if accepted, what action to take as
a result. For example, if an ICMP unreachable message is received, a result. For example, if an ICMP Destination Unreachable message is
the implementation must decide whether to act on it, reject it, or received, the implementation must decide whether to act on it, reject
act on it with constraints. Section 8 ("Path MTU/DF processing") it, or act on it with constraints. Section 8 ("Path MTU/DF
discusses the processing of unauthenticated ICMP "fragmentation Processing") discusses the processing of unauthenticated ICMPv4
needed and DF bit set" (type 3, code 3) and ICMPv6 "Packet Too Big" "fragmentation needed and DF bit set" (type 3, code 4) and ICMPv6
(type 2, code 0) messages when an IPsec implementation is configured "Packet Too Big" (type 2, code 0) messages when an IPsec
to process (vs. ignore) such messages. implementation is configured to process (vs. ignore) such messages.
Section 6.1.1 of [RFC4301] notes that processing of unauthenticated Section 6.1.1 of [RFC4301] notes that processing of unauthenticated
ICMP error messages may result in denial or degradation of service, ICMP error messages may result in denial or degradation of service,
and therefore it would be desirable to ignore such messages. and therefore it would be desirable to ignore such messages.
However, it also notes that in many cases ignoring these ICMP However, it also notes that in many cases, ignoring these ICMP
messages can degrade service, e.g., because of a failure to process messages can degrade service, e.g., because of a failure to process
PMTUD and redirection messages, and therefore there is also a PMTUD and redirection messages, and therefore there is also a
motivation for accepting and acting upon them. It finally states motivation for accepting and acting upon them. It finally states
that to accommodate both ends of this spectrum, a compliant IPsec that to accommodate both ends of this spectrum, a compliant IPsec
implementation MUST permit a local administrator to configure an implementation MUST permit a local administrator to configure an
IPsec implementation to accept or reject unauthenticated ICMP IPsec implementation to accept or reject unauthenticated ICMP
traffic, and that this control MUST be at the granularity of ICMP traffic, and that this control MUST be at the granularity of ICMP
type and MAY be at the granularity of ICMP type and code. type and MAY be at the granularity of ICMP type and code.
Additionally, an implementation SHOULD incorporate mechanisms and Additionally, an implementation SHOULD incorporate mechanisms and
parameters for dealing with such traffic. parameters for dealing with such traffic.
Thus, the policy to apply for the processing of unprotected ICMP Thus, the policy to apply for the processing of unprotected ICMP
error messages is left up to the implementation and administrator. error messages is left up to the implementation and administrator.
3. Constraints in the possible solutions 3. Constraints in the Possible Solutions
If a host wants perform validation checks on the received ICMP error If a host wants to perform validation checks on the received ICMP
messages before acting on them, it is limited by the piece of the error messages before acting on them, it is limited by the piece of
packet that triggered error that the sender of the ICMP error message the packet that triggered the error that the sender of the ICMP error
chose to include in the ICMP payload. This contrains the possible message chose to include in the ICMP payload. This constrains the
validation checks, as the number of bytes of the packet that possible validation checks, as the number of bytes of the packet that
triggered the error message that is included in the ICMP payload is triggered the error message that is included in the ICMP payload is
limited. limited.
For ICMPv4, [RFC0792] states that the IP header plus the first 64 For ICMPv4, [RFC0792] states that the IP header plus the first
bits of the packet that triggered the ICMP message are to be included 64 bits of the packet that triggered the ICMPv4 message are to be
in the payload of the ICMP error message. Thus, it is assumed that included in the payload of the ICMPv4 error message. Thus, it is
all data needed to identify a transport protocol instance and process assumed that all data needed to identify a transport protocol
the ICMP error message is contained in the first 64 bits of the instance and process the ICMPv4 error message is contained in the
transport protocol header. Section 3.2.2 of [RFC1122] states that first 64 bits of the transport protocol header. Section 3.2.2 of
"the Internet header and at least the first 8 data octets of the [RFC1122] states that "the Internet header and at least the first 8
datagram that triggered the error" are to be included in the payload data octets of the datagram that triggered the error" are to be
of ICMP error messages, and that "more than 8 octets MAY be sent", included in the payload of ICMPv4 error messages, and that "more than
thus allowing implementations to include more data from the original 8 octets MAY be sent", thus allowing implementations to include more
packet than those required by the original ICMP specification. The data from the original packet than those required by the original
Requirements for IP Version 4 Routers RFC [RFC1812] states that ICMP ICMPv4 specification. The "Requirements for IP Version 4 Routers"
error messages "SHOULD contain as much of the original datagram as RFC [RFC1812] states that ICMPv4 error messages "SHOULD contain as
possible without the length of the ICMP datagram exceeding 576 much of the original datagram as possible without the length of the
bytes". ICMP datagram exceeding 576 bytes".
Thus, for ICMP messages generated by hosts, we can only expect to get Thus, for ICMPv4 messages generated by hosts, we can only expect to
the entire IP header of the original packet, plus the first 64 bits get the entire IP header of the original packet, plus the first
of its payload. For TCP, this means that the only fields that will 64 bits of its payload. For TCP, this means that the only fields
be included in the ICMP payload are: the source port number, the that will be included in the ICMPv4 payload are the source port
destination port number, and the 32-bit TCP sequence number. This number, the destination port number, and the 32-bit TCP sequence
clearly imposes a constraint on the possible validation checks that number. This clearly imposes a constraint on the possible validation
can be performed, as there is not much information available on which checks that can be performed, as there is not much information
to perform them. available on which to perform them.
This means, for example, that even if TCP were signing its segments This means, for example, that even if TCP were signing its segments
by means of the TCP MD5 signature option [RFC2385], this mechanism by means of the TCP MD5 signature option [RFC2385], this mechanism
could not be used as a counter-measure against ICMP-based attacks, could not be used as a counter-measure against ICMP-based attacks,
because, as ICMP messages include only a piece of the TCP segment because, as ICMP messages include only a piece of the TCP segment
that triggered the error, the MD5 [RFC1321] signature could not be that triggered the error, the MD5 [RFC1321] signature could not be
recalculated. In the same way, even if the attacked peer were recalculated. In the same way, even if the attacked peer were
authenticating its packets at the IP layer [RFC4301], because only a authenticating its packets at the IP layer [RFC4301], because only a
part of the original IP packet would be available, the signature used part of the original IP packet would be available, the signature used
for authentication could not be recalculated, and thus the for authentication could not be recalculated, and thus the
authentication header in the original packet could not be used as a authentication header in the original packet could not be used as a
counter-measure for ICMP-based attacks against TCP. counter-measure for ICMP-based attacks against TCP.
[RFC4884] updated [RFC0792] and specified that ICMPv4 Destination
Unreachable (type 3), Time Exceeded (type 11), and Parameter Problem
(type 12) messages that have an ICMP Extension Structure appended
include at least 128 octets in the "original datagram" field. This
would improve the situation, but at the time of this writing,
[RFC4884] is not yet widely deployed for end-systems.
For IPv6, the payload of ICMPv6 error messages includes as many For IPv6, the payload of ICMPv6 error messages includes as many
octets from the IPv6 packet that triggered the ICMPv6 error message octets from the IPv6 packet that triggered the ICMPv6 error message
as will fit without making the resulting ICMPv6 error message exceed as will fit without making the resulting ICMPv6 error message exceed
the minimum IPv6 MTU (1280 octets) [RFC4443]. Thus, more information the minimum IPv6 MTU (1280 octets) [RFC4443]. Thus, more information
is available than in the IPv4 case. is available than in the IPv4 case.
Hosts could require ICMP error messages to be authenticated Hosts could require ICMP error messages to be authenticated
[RFC4301], in order to act upon them. However, while this [RFC4301], in order to act upon them. However, while this
requirement could make sense for those ICMP error messages sent by requirement could make sense for those ICMP error messages sent by
hosts, it would not be feasible for those ICMP error messages hosts, it would not be feasible for those ICMP error messages
skipping to change at page 11, line 5 skipping to change at page 10, line 13
system should have a security association [RFC4301] with every system should have a security association [RFC4301] with every
existing intermediate system, or that it should be able to establish existing intermediate system, or that it should be able to establish
one dynamically. Current levels of deployment of protocols for one dynamically. Current levels of deployment of protocols for
dynamic establishment of security associations makes this unfeasible. dynamic establishment of security associations makes this unfeasible.
Additionally, this would require routers to use certificates with Additionally, this would require routers to use certificates with
paths compatible for all hosts on the network. Finally, there may be paths compatible for all hosts on the network. Finally, there may be
some scenarios, such as embedded devices, in which the processing some scenarios, such as embedded devices, in which the processing
power requirements of authentication might not allow IPsec power requirements of authentication might not allow IPsec
authentication to be implemented effectively. authentication to be implemented effectively.
4. General counter-measures against ICMP attacks 4. General Counter-Measures against ICMP Attacks
The following subsections describe a number of mitigation techniques The following subsections describe a number of mitigation techniques
that help to eliminate or mitigate the impact of the attacks that help to eliminate or mitigate the impact of the attacks
discussed in this document. Rather than being alternative counter- discussed in this document. Rather than being alternative counter-
measures, they can be implemented together to increase the protection measures, they can be implemented together to increase the protection
against these attacks. against these attacks.
4.1. TCP sequence number checking 4.1. TCP Sequence Number Checking
The current specifications do not impose any validity checks on the The current specifications do not impose any validity checks on the
TCP segment that is contained in the ICMP payload. For instance, no TCP segment that is contained in the ICMP payload. For instance, no
checks are performed to verify that a received ICMP error message has checks are performed to verify that a received ICMP error message has
been triggered by a segment that was "in flight" to the destination. been triggered by a segment that was "in flight" to the destination.
Thus, even stale ICMP error messages will be acted upon. Thus, even stale ICMP error messages will be acted upon.
Many TCP implementations have incorporated a validation check such Many TCP implementations have incorporated a validation check such
that they react only to those ICMP error messages that appear to that they react only to those ICMP error messages that appear to
relate to segments currently "in-flight" to the destination system. relate to segments currently "in flight" to the destination system.
These implementations check that the TCP sequence number contained in These implementations check that the TCP sequence number contained in
the payload of the ICMP error message is within the range SND.UNA =< the payload of the ICMP error message is within the range
SEG.SEQ < SND.NXT. This means that they require that the sequence SND.UNA =< SEG.SEQ < SND.NXT. This means that they require that the
number be within the range of the data already sent but not yet sequence number be within the range of the data already sent but not
acknowledged. If an ICMP error message does not pass this check, it yet acknowledged. If an ICMP error message does not pass this check,
is discarded. it is discarded.
Even if an attacker were able to guess the four-tuple that identifies Even if an attacker were able to guess the four-tuple that identifies
the TCP connection, this additional check would reduce the the TCP connection, this additional check would reduce the
possibility of considering a spoofed ICMP packet as valid to possibility of considering a spoofed ICMP packet as valid to
Flight_Size/2^^32 (where Flight_Size is the number of data bytes Flight_Size/2^^32 (where Flight_Size is the number of data bytes
already sent to the remote peer, but not yet acknowledged [RFC5681]). already sent to the remote peer, but not yet acknowledged [RFC5681]).
For connections in the SYN-SENT or SYN-RECEIVED states, this would For connections in the SYN-SENT or SYN-RECEIVED states, this would
reduce the possibility of considering a spoofed ICMP packet as valid reduce the possibility of considering a spoofed ICMP packet as valid
to 1/2^^32. For a TCP endpoint with no data "in flight", this would to 1/2^^32. For a TCP endpoint with no data "in flight", this would
completely eliminate the possibility of success of these attacks. completely eliminate the possibility of success of these attacks.
This validation check has been implemented in Linux [Linux] for many This validation check has been implemented in Linux [Linux] for many
years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and
NetBSD [NetBSD] since 2005. NetBSD [NetBSD] since 2005.
It is important to note that while this check greatly increases the It is important to note that while this check greatly increases the
number of packets required to perform any of the attacks discussed in number of packets required to perform any of the attacks discussed in
this document, this may not be enough in those scenarios in which this document, this may not be enough in those scenarios in which
bandwidth is easily available, and/or large TCP windows [RFC1323] are bandwidth is easily available and/or large TCP windows [RFC1323] are
in use. Additionally, this validation check does not help to prevent in use. Additionally, this validation check does not help to prevent
on-path attacks, that is, attacks performed in scenarios in which the on-path attacks, that is, attacks performed in scenarios in which the
attacker can sniff the packets that correspond to the target TCP attacker can sniff the packets that correspond to the target TCP
connection. connection.
It should be noted that as there are no timeliness requirements for It should be noted that, as there are no timeliness requirements for
ICMP error messages, the TCP Sequence Number check described in this ICMP error messages, the TCP Sequence Number check described in this
section might cause legitimate ICMP error messages to be discarded. section might cause legitimate ICMP error messages to be discarded.
Also, even if this check is enforced, TCP might end up responding to Also, even if this check is enforced, TCP might end up responding to
stale ICMP error messages (e.g., if the Sequence Number for the stale ICMP error messages (e.g., if the Sequence Number for the
corresponding direction of the data transfer wrap around). corresponding direction of the data transfer wraps around).
4.2. Port randomization 4.2. Port Randomization
As discussed in the previous sections, in order to perform any of the As discussed in the previous sections, in order to perform any of the
attacks described in this document, an attacker would need to guess attacks described in this document, an attacker would need to guess
(or know) the four-tuple that identifies the connection to be (or know) the four-tuple that identifies the connection to be
attacked. Increasing the port number range used for outgoing TCP attacked. Increasing the port number range used for outgoing TCP
connections, and randomizing the port number chosen for each outgoing connections, and randomizing the port number chosen for each outgoing
TCP connections would make it harder for an attacker to perform any TCP connection, would make it harder for an attacker to perform any
of the attacks discussed in this document. of the attacks discussed in this document.
[I-D.ietf-tsvwg-port-randomization] recommends that transport [PORT-RANDOM] recommends that transport protocols randomize the
protocols randomize the ephemeral ports used by clients, and proposes ephemeral ports used by clients, and proposes a number of
a number of randomization algorithms. randomization algorithms.
4.3. Filtering ICMP error messages based on the ICMP payload 4.3. Filtering ICMP Error Messages Based on the ICMP Payload
The source address of ICMP error messages does not need to be spoofed The source address of ICMP error messages does not need to be spoofed
to perform the attacks described in this document, as the ICMP error to perform the attacks described in this document, as the ICMP error
messages might legitimately come from an intermediate system. messages might legitimately come from an intermediate system.
Therefore, simple filtering based on the source address of ICMP error Therefore, simple filtering based on the source address of ICMP error
messages does not serve as a counter-measure against these attacks. messages does not serve as a counter-measure against these attacks.
However, a more advanced packet filtering can be implemented in However, a more advanced packet filtering can be implemented in
middlebox devices such as firewalls and NATs. Middleboxes middlebox devices such as firewalls and NATs. Middleboxes
implementing such advanced filtering look at the payload of the ICMP implementing such advanced filtering look at the payload of the ICMP
error messages, and perform ingress and egress packet filtering based error messages, and perform ingress and egress packet filtering based
on the source IP address of the IP header contained in the payload of on the source address of the IP header contained in the payload of
the ICMP error message. As the source IP address contained in the the ICMP error message. As the source address contained in the
payload of the ICMP error message does need to be spoofed to perform payload of the ICMP error message does need to be spoofed to perform
the attacks described in this document, this kind of advanced the attacks described in this document, this kind of advanced
filtering serves as a counter-measure against these attacks. As with filtering serves as a counter-measure against these attacks. As with
traditional egress filtering [IP-filtering], egress filtering based traditional egress filtering [IP-filtering], egress filtering based
on the ICMP payload can help to prevent users of the network being on the ICMP payload can help to prevent users of the network being
protected by the firewall from successfully performing ICMP attacks protected by the firewall from successfully performing ICMP attacks
against TCP connections established between external systems. against TCP connections established between external systems.
Additionally, ingress filtering based on the ICMP payload can prevent Additionally, ingress filtering based on the ICMP payload can prevent
TCP connections established between internal systems from attacks TCP connections established between internal systems from being
performed by external systems. [ICMP-Filtering] provides examples of attacked by external systems. [ICMP-Filtering] provides examples of
ICMP filtering based on the ICMP payload. ICMP filtering based on the ICMP payload.
This filtering technique has been implemented in OpenBSD's Packet This filtering technique has been implemented in OpenBSD's Packet
Filter [OpenBSD-PF], which has in turn been ported to a number of Filter [OpenBSD-PF], which has in turn been ported to a number of
systems, including FreeBSD [FreeBSD]. systems, including FreeBSD [FreeBSD].
5. Blind connection-reset attack 5. Blind Connection-Reset Attack
5.1. Description 5.1. Description
When TCP is handed an ICMP error message, it will perform its fault When TCP is handed an ICMP error message, it will perform its fault
recovery function, as follows: recovery function, as follows:
o If the network problem being reported is a hard error, TCP will o If the network problem being reported is a "hard error", TCP will
abort the corresponding connection. abort the corresponding connection.
o If the network problem being reported is a soft error, TCP will o If the network problem being reported is a "soft error", TCP will
just record this information, and repeatedly retransmit its data just record this information, and repeatedly retransmit its data
until they either get acknowledged, or the connection times out. until they either get acknowledged, or the connection times out.
The Host Requirements RFC [RFC1122] states (in Section 4.2.3.9) that The Host Requirements RFC [RFC1122] states (in Section 4.2.3.9) that
a host SHOULD abort the corresponding connection when receiving an a host SHOULD abort the corresponding connection when receiving an
ICMP error message that indicates a "hard error", and states that ICMPv4 error message that indicates a "hard error", and states that
ICMP error messages of type 3 (Destination Unreachable) codes 2 ICMPv4 error messages of type 3 (Destination Unreachable), codes 2
(protocol unreachable), 3 (port unreachable), and 4 (fragmentation (protocol unreachable), 3 (port unreachable), and 4 (fragmentation
needed and DF bit set) should be considered to indicate hard errors. needed and DF bit set) should be considered as indicating "hard
In the case of ICMP port unreachables, the specifications are errors". In the case of ICMPv4 port unreachables, the specifications
ambiguous, as Section 4.2.3.9 of [RFC1122] states that TCP SHOULD are ambiguous, as Section 4.2.3.9 of [RFC1122] states that TCP SHOULD
abort the corresponding connection in response to them, but Section abort the corresponding connection in response to them, but
3.2.2.1 of the same RFC ([RFC1122] states that TCP MUST abort the Section 3.2.2.1 of the same RFC ([RFC1122]) states that TCP MUST
connection in response to them. abort the connection in response to them.
While [RFC4443] did not exist when [RFC1122] was published, one could While [RFC4443] did not exist when [RFC1122] was published, one could
extrapolate the concept of "hard errors" to ICMPv6 error messages of extrapolate the concept of "hard errors" to ICMPv6 error messages of
type 1 (Destination unreachable) codes 1 (communication with type 1 (Destination Unreachable), codes 1 (communication with
destination administratively prohibited), and 4 (port unreachable). destination administratively prohibited), and 4 (port unreachable).
Thus, an attacker could use ICMP to perform a blind connection-reset Thus, an attacker could use ICMP to perform a blind connection-reset
attack by sending any ICMP error message that indicates a "hard attack by sending any ICMP error message that indicates a "hard
error", to either of the two TCP endpoints of the connection. error" to either of the two TCP endpoints of the connection. Because
Because of TCP's fault recovery policy, the connection would be of TCP's fault recovery policy, the connection would be immediately
immediately aborted. aborted.
Some stacks are known to extrapolate ICMP hard errors across TCP Some stacks are known to extrapolate ICMP "hard errors" across TCP
connections, increasing the impact of this attack, as a single ICMP connections, increasing the impact of this attack, as a single ICMP
packet could bring down all the TCP connections between the packet could bring down all the TCP connections between the
corresponding peers. corresponding peers.
It is important to note that even if TCP itself were protected It is important to note that even if TCP itself were protected
against the blind connection-reset attack described in [Watson] and against the blind connection-reset attack described in [Watson] and
[I-D.ietf-tcpm-tcpsecure], by means of authentication at the network [TCPM-TCPSECURE] by means of authentication at the network layer
layer [RFC4301], by means of the TCP MD5 signature option [RFC2385], [RFC4301], by means of the TCP MD5 signature option [RFC2385], by
by means of the TCP-AO [I-D.ietf-tcpm-tcp-auth-opt], or by means of means of the TCP-AO [RFC5925], or by means of the mechanism specified
the mechanism specified in [I-D.ietf-tcpm-tcpsecure], the blind in [TCPM-TCPSECURE], the blind connection-reset attack described in
connection-reset attack described in this document would still this document would still succeed.
succeed.
5.2. Attack-specific counter-measures 5.2. Attack-Specific Counter-Measures
An analysis of the circumstances in which ICMP messages that indicate An analysis of the circumstances in which ICMP messages that indicate
hard errors may be received can shed some light to mitigate the "hard errors" may be received can shed some light on opportunities to
impact of ICMP-based blind connection-reset attacks. mitigate the impact of ICMP-based blind connection-reset attacks.
ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable) ICMPv4 type 3 (Destination Unreachable), code 2 (protocol
unreachable)
This ICMP error message indicates that the host sending the ICMP This ICMP error message indicates that the host sending the ICMP
error message received a packet meant for a transport protocol it error message received a packet meant for a transport protocol it
does not support. For connection-oriented protocols such as TCP, does not support. For connection-oriented protocols such as TCP,
one could expect to receive such an error as the result of a one could expect to receive such an error as the result of a
connection-establishment attempt. However, it would be strange to connection-establishment attempt. However, it would be strange to
get such an error during the life of a connection, as this would get such an error during the life of a connection, as this would
indicate that support for that transport protocol has been removed indicate that support for that transport protocol has been removed
from the system sending the error message during the life of the from the system sending the error message during the life of the
corresponding connection. corresponding connection.
ICMP type 3 (Destination Unreachable), code 3 (port unreachable) ICMPv4 type 3 (Destination Unreachable), code 3 (port unreachable)
This error message indicates that the system sending the ICMP This error message indicates that the system sending the ICMP
error message received a packet meant for a socket (IP address, error message received a packet meant for a socket (IP address,
port number) on which there is no process listening. Those port number) on which there is no process listening. Those
transport protocols which have their own mechanisms for notifying transport protocols that have their own mechanisms for signaling
this condition should not be receiving these error messages, as this condition should not be receiving these error messages, as
the protocol would signal the port unreachable condition by means the protocol would signal the port unreachable condition by means
of its own messages. Assuming that once a connection is of its own mechanisms. Assuming that once a connection is
established it is not usual for the transport protocol to change established it is not usual for the transport protocol to change
(or be reloaded), it should be unusual to get these error (or be reloaded), it should be unusual to get these error
messages. messages.
ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed ICMPv4 type 3 (Destination Unreachable), code 4 (fragmentation needed
and DF bit set) and DF bit set)
This error message indicates that an intermediate node needed to This error message indicates that an intermediate node needed to
fragment a datagram, but the DF (Don't Fragment) bit in the IP fragment a datagram, but the DF (Don't Fragment) bit in the IP
header was set. It is considered a soft error when TCP implements header was set. It is considered a "soft error" when TCP
PMTUD, and a hard error if TCP does not implement PMTUD. Those implements PMTUD, and a "hard error" if TCP does not implement
TCP/IP stacks that do not implement PMTUD (or have disabled it) PMTUD. Those TCP/IP stacks that do not implement PMTUD (or have
but support IP fragmentation/reassembly should not be sending disabled it) but support IP fragmentation/reassembly should not be
their IP packets with the DF bit set, and thus should not be sending their IP packets with the DF bit set, and thus should not
receiving these ICMP error messages. Some TCP/IP stacks that do be receiving these ICMP error messages. Some TCP/IP stacks that
not implement PMTUD and that do not support IP fragmentation/ do not implement PMTUD and that do not support IP fragmentation/
reassembly are known to send their packets with the DF bit set, reassembly are known to send their packets with the DF bit set,
and thus could legitimately receive these ICMP error messages. and thus could legitimately receive these ICMP error messages.
ICMPv6 type 1 (Destination Unreachable), code 1 (communication with ICMPv6 type 1 (Destination Unreachable), code 1 (communication with
destination administratively prohibited) destination administratively prohibited)
This error message indicates that the destination is unreachable This error message indicates that the destination is unreachable
because of an administrative policy. For connection-oriented because of an administrative policy. For connection-oriented
protocols such as TCP, one could expect to receive such an error protocols such as TCP, one could expect to receive such an error
as the result of a connection-establishment attempt. Receiving as the result of a connection-establishment attempt. Receiving
such an error for a connection in any of the synchronized states such an error for a connection in any of the synchronized states
would mean that the administrative policy changed during the life would mean that the administrative policy changed during the life
of the connection. However, in the same way this error condition of the connection. However, in the same way this error condition
(which was not present when the connection was established) (which was not present when the connection was established)
appeared, it could get solved in the near term. appeared, it could get solved in the near term.
ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable) ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable)
This error message is analogous to the ICMP type 3 (Destination This error message is analogous to the ICMPv4 type 3 (Destination
Unreachable), code 3 (Port unreachable) error message discussed Unreachable), code 3 (port unreachable) error message discussed
above. Therefore, the same considerations apply. above. Therefore, the same considerations apply.
The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that
TCP SHOULD abort the corresponding connection in response to ICMP TCP SHOULD abort the corresponding connection in response to ICMPv4
messages of type 3, codes 2 (protocol unreachable), 3 (port messages of type 3 (Destination Unreachable), codes 2 (protocol
unreachable), and 4 (fragmentation needed and DF bit set). However, unreachable), 3 (port unreachable), and 4 (fragmentation needed and
Section 3.2.2.1 states that TCP MUST accept an ICMP port unreachable DF bit set). However, Section 3.2.2.1 states that TCP MUST accept an
(type 3, code 3) for the same purpose as an RST. Therefore, for ICMP ICMPv4 port unreachable (type 3, code 3) for the same purpose as a
messages of type 3 codes 2 and 4 there is room to go against the RST. Therefore, for ICMPv4 messages of type 3, codes 2 and 4, there
advice provided in the existing specifications, while in the case of is room to go against the advice provided in the existing
ICMP messages of type 3 code 3 there is ambiguity in the specifications, while in the case of ICMPv4 messages of type 3,
specifications that may or may not provide some room to go against code 3, there is ambiguity in the specifications that may or may not
that advice. provide some room to go against that advice.
Based on this analysis, most popular TCP implementations treat all Based on this analysis, most popular TCP implementations treat all
ICMP "hard errors" received for connections in any of the ICMP "hard errors" received for connections in any of the
synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
CLOSING, LAST-ACK or TIME-WAIT) as "soft errors". That is, they do CLOSING, LAST-ACK, or TIME-WAIT) as "soft errors". That is, they do
not abort the corresponding connection upon receipt of them. not abort the corresponding connection upon receipt of them.
Additionally, they do not extrapolate ICMP errors across TCP Additionally, they do not extrapolate ICMP errors across TCP
connections. This policy is based on the premise that TCP should be connections. This policy is based on the premise that TCP should be
as robust as possible. Aborting the connection would be to ignore as robust as possible. Aborting the connection would be to ignore
the valuable feature of the Internet that for many internal failures the valuable feature of the Internet -- that for many internal
it reconstructs its function without any disruption of the end points failures, it reconstructs its function without any disruption of the
[RFC0816]. endpoints [RFC0816].
It should be noted that treating ICMP hard errors as soft errors for It should be noted that treating ICMP "hard errors" as "soft errors"
connections in any of the synchronized states may prevent TCP from for connections in any of the synchronized states may prevent TCP
responding quickly to a legitimate ICMP error message. from responding quickly to a legitimate ICMP error message.
It is interesting to note that, as ICMP error messages are It is interesting to note that, as ICMP error messages are
transmitted unreliably, transport protocols should not depend on them transmitted unreliably, transport protocols should not depend on them
for correct functioning. In the event one of these messages were for correct functioning. In the event one of these messages were
legitimate, the corresponding connection would eventually time out. legitimate, the corresponding connection would eventually time out.
Also, applications may still be notified asynchronously about the Also, applications may still be notified asynchronously about the
error condition, and thus may still abort their connections on their error condition, and thus may still abort their connections on their
own if they consider it appropriate. own if they consider it appropriate.
In scenarios such as that in which an intermediate system sets the DF In scenarios such as that in which an intermediate system sets the DF
skipping to change at page 16, line 31 skipping to change at page 15, line 40
probably preferable to potentially lose responsiveness for the sake probably preferable to potentially lose responsiveness for the sake
of robustness. It should also be noted that applications may still of robustness. It should also be noted that applications may still
be notified asynchronously about the error condition, and thus may be notified asynchronously about the error condition, and thus may
still abort their connections on their own if they consider it still abort their connections on their own if they consider it
appropriate. appropriate.
In scenarios of multipath routing or route changes, failures in some In scenarios of multipath routing or route changes, failures in some
(but not all) of the paths may elicit ICMP error messages that would (but not all) of the paths may elicit ICMP error messages that would
likely not cause a connection abort if any of the counter-measures likely not cause a connection abort if any of the counter-measures
described in this section were implemented. However, aborting the described in this section were implemented. However, aborting the
connection would be to ignore the valuable feature of the Internet connection would be to ignore the valuable feature of the Internet --
that for many internal failures it reconstructs its function without that for many internal failures, it reconstructs its function without
any disruption of the end points [RFC0816]. That is, communication any disruption of the endpoints [RFC0816]. That is, communication
should survive if there is still a working path to the destination should survive if there is still a working path to the destination
system [DClark]. Additionally, applications may still be notified system [DClark]. Additionally, applications may still be notified
asynchronously about the error condition, and thus may still abort asynchronously about the error condition, and thus may still abort
their connections on their own if they consider it appropriate. their connections on their own if they consider it appropriate.
This counter-measure has been implemented in BSD-derived TCP/IP This counter-measure has been implemented in BSD-derived TCP/IP
implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more
than ten years [Wright][McKusick]. The Linux kernel has also than ten years [Wright][McKusick]. The Linux kernel has also
implemented this policy for more than ten years [Linux]. implemented this policy for more than ten years [Linux].
6. Blind throughput-reduction attack 6. Blind Throughput-Reduction Attack
6.1. Description 6.1. Description
The Host requirements RFC [RFC1122] states in Section 4.2.3.9 that The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that
hosts MUST react to ICMP Source Quench messages by slowing hosts MUST react to ICMPv4 Source Quench messages by slowing
transmission on the connection. Thus, an attacker could send ICMP transmission on the connection. Thus, an attacker could send ICMPv4
Source Quench (type 4, code 0) messages to a TCP endpoint to make it Source Quench (type 4, code 0) messages to a TCP endpoint to make it
reduce the rate at which it sends data to the other end-point of the reduce the rate at which it sends data to the other endpoint of the
connection. [RFC1122] further adds that the RECOMMENDED procedure is connection. [RFC1122] further adds that the RECOMMENDED procedure is
to put the corresponding connection in the slow-start phase of TCP's to put the corresponding connection in the slow-start phase of TCP's
congestion control algorithm [RFC5681]. In the case of those congestion control algorithm [RFC5681]. In the case of those
implementations that use an initial congestion window of one segment, implementations that use an initial congestion window of one segment,
a sustained attack would reduce the throughput of the attacked a sustained attack would reduce the throughput of the attacked
connection to about SMSS (Sender Maximum Segment Size) [RFC5681] connection to about SMSS (Sender Maximum Segment Size) [RFC5681]
bytes per RTT (round-trip time). The throughput achieved during an bytes per RTT (round-trip time). The throughput achieved during an
attack might be a little higher if a larger initial congestion window attack might be a little higher if a larger initial congestion window
is in use [RFC3390]. is in use [RFC3390].
6.2. Attack-specific counter-measures 6.2. Attack-Specific Counter-Measures
As discussed in the Requirements for IP Version 4 Routers RFC As discussed in the "Requirements for IP Version 4 Routers" RFC
[RFC1812], research seems to suggest that ICMP Source Quench is an [RFC1812], research seems to suggest that ICMPv4 Source Quench
ineffective (and unfair) antidote for congestion. [RFC1812] further messages are an ineffective (and unfair) antidote for congestion.
states that routers SHOULD NOT send ICMP Source Quench messages in [RFC1812] further states that routers SHOULD NOT send ICMPv4 Source
response to congestion. Furthermore, TCP implements its own Quench messages in response to congestion. Furthermore, TCP
congestion control mechanisms [RFC5681] [RFC3168], that do not depend implements its own congestion control mechanisms ([RFC5681]
on ICMP Source Quench messages. [RFC3168]) that do not depend on ICMPv4 Source Quench messages.
Based on this reasoning, a large number of implementations completely Based on this reasoning, a large number of implementations completely
ignore ICMP Source Quench messages meant for TCP connections. This ignore ICMPv4 Source Quench messages meant for TCP connections. This
behavior has been implemented in, at least, Linux [Linux] since 2004, behavior has been implemented in, at least, Linux [Linux] since 2004,
and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD]
since 2005. However, it must be noted that this behaviour violates since 2005. However, it must be noted that this behavior violates
the requirement in [RFC1122] to react to ICMP Source Quench messages the requirement in [RFC1122] to react to ICMPv4 Source Quench
by slowing transmission on the connection. messages by slowing transmission on the connection.
7. Blind performance-degrading attack 7. Blind Performance-Degrading Attack
7.1. Description 7.1. Description
When one IP system has a large amount of data to send to another When one IP system has a large amount of data to send to another
system, the data will be transmitted as a series of IP datagrams. It system, the data will be transmitted as a series of IP datagrams. It
is usually preferable that these datagrams be of the largest size is usually preferable that these datagrams be of the largest size
that does not require fragmentation anywhere along the path from the that does not require fragmentation anywhere along the path from the
source to the destination. This datagram size is referred to as the source to the destination. This datagram size is referred to as the
Path MTU (PMTU), and is equal to the minimum of the MTUs of each hop Path MTU (PMTU) and is equal to the minimum of the MTUs of each hop
in the path. A technique called "Path MTU Discovery" (PMTUD) lets IP in the path. A technique called "Path MTU Discovery" (PMTUD) lets IP
systems determine the Path MTU of an arbitrary internet path. systems determine the Path MTU of an arbitrary internet path.
[RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and [RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and
IPv6, respectively. IPv6, respectively.
The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the
IP header to dynamically discover the Path MTU. The basic idea IP header to dynamically discover the Path MTU. The basic idea
behind the PMTUD mechanism is that a source system assumes that the behind the PMTUD mechanism is that a source system assumes that the
MTU of the path is that of the first hop, and sends all its datagrams MTU of the path is that of the first hop, and sends all its datagrams
with the DF bit set. If any of the datagrams is too large to be with the DF bit set. If any of the datagrams is too large to be
forwarded without fragmentation by some intermediate router, the forwarded without fragmentation by some intermediate router, the
router will discard the corresponding datagram, and will return an router will discard the corresponding datagram and will return an
ICMP "Destination Unreachable" (type 3) "fragmentation needed and DF ICMPv4 "Destination Unreachable, fragmentation needed and DF set"
set" (code 4) error message to the sending system. This message will (type 3, code 4) error message to the sending system. This message
report the MTU of the constricting hop, so that the sending system will report the MTU of the constricting hop, so that the sending
can reduce the assumed Path-MTU accordingly. system can reduce the assumed Path-MTU accordingly.
For IPv6, intermediate systems do not fragment packets. Thus, For IPv6, intermediate systems do not fragment packets. Thus,
there's an "implicit" DF bit set in every packet sent on a network. there's an "implicit" DF bit set in every packet sent on a network.
If any of the datagrams is too large to be forwarded without If any of the datagrams is too large to be forwarded without
fragmentation by some intermediate router, the router will discard fragmentation by some intermediate router, the router will discard
the corresponding datagram, and will return an ICMPv6 "Packet Too the corresponding datagram, and will return an ICMPv6 "Packet Too
Big" (type 2, code 0) error message to sending system. This message Big" (type 2, code 0) error message to the sending system. This
will report the MTU of the constricting hop, so that the sending message will report the MTU of the constricting hop, so that the
system can reduce the assumed Path-MTU accordingly. sending system can reduce the assumed Path-MTU accordingly.
As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery
mechanism can be used to attack TCP. An attacker could send a mechanism can be used to attack TCP. An attacker could send a
crafted ICMP "Destination Unreachable, fragmentation needed and DF crafted ICMPv4 "Destination Unreachable, fragmentation needed and DF
set" packet (or their ICMPv6 counterpart) to the sending system, set" packet (or their ICMPv6 counterpart) to the sending system,
advertising a small Next-Hop MTU. As a result, the attacked system advertising a small Next-Hop MTU. As a result, the attacked system
would reduce the size of the packets it sends for the corresponding would reduce the size of the packets it sends for the corresponding
connection accordingly. connection accordingly.
The effect of this attack is two-fold. On one hand, it will increase The effect of this attack is two-fold. On one hand, it will increase
the headers/data ratio, thus increasing the overhead needed to send the headers/data ratio, thus increasing the overhead needed to send
data to the remote TCP end-point. On the other hand, if the attacked data to the remote TCP endpoint. On the other hand, if the attacked
system wanted to keep the same throughput it was achieving before system wanted to keep the same throughput it was achieving before
being attacked, it would have to increase the packet rate. On being attacked, it would have to increase the packet rate. On
virtually all systems this will lead to an increased processing virtually all systems, this will lead to an increased processing
overhead, thus degrading the overall system performance. overhead, thus degrading the overall system performance.
A particular scenario that may take place is that in which an A particular scenario that may take place is one in which an attacker
attacker reports a Next-Hop MTU smaller than or equal to the amount reports a Next-Hop MTU smaller than or equal to the amount of bytes
of bytes needed for headers (IP header, plus TCP header). For needed for headers (IP header, plus TCP header). For example, if the
example, if the attacker reports a Next-Hop MTU of 68 bytes, and the attacker reports a Next-Hop MTU of 68 bytes, and the amount of bytes
amount of bytes used for headers (IP header, plus TCP header) is used for headers (IP header, plus TCP header) is larger than
larger than 68 bytes, the assumed Path-MTU will not even allow the 68 bytes, the assumed Path-MTU will not even allow the attacked
attacked system to send a single byte of application data without system to send a single byte of application data without
fragmentation. This particular scenario might lead to unpredictable fragmentation. This particular scenario might lead to unpredictable
results. Another possible scenario is that in which a TCP connection results. Another possible scenario is one in which a TCP connection
is being secured by means of IPsec. If the Next-Hop MTU reported by is being secured by means of IPsec. If the Next-Hop MTU reported by
the attacker is smaller than the amount of bytes needed for headers the attacker is smaller than the amount of bytes needed for headers
(IP and IPsec, in this case), the assumed Path-MTU will not even (IP and IPsec, in this case), the assumed Path-MTU will not even
allow the attacked system to send a single byte of the TCP header allow the attacked system to send a single byte of the TCP header
without fragmentation. This is another scenario that may lead to without fragmentation. This is another scenario that may lead to
unpredictable results. unpredictable results.
For IPv4, the reported Next-Hop MTU could be as small as 68 octets, For IPv4, the reported Next-Hop MTU could be as small as 68 octets,
as [RFC0791] requires every internet module to be able to forward a as [RFC0791] requires every internet module to be able to forward a
datagram of 68 octets without further fragmentation. For IPv6, while datagram of 68 octets without further fragmentation. For IPv6, while
the required minimum IPv6 MTU is 1280, the reported Next-Hop MTU can the required minimum IPv6 MTU is 1280, the reported Next-Hop MTU can
be smaller than 1280 octets [RFC2460]. If the reported Next-Hop MTU be smaller than 1280 octets [RFC2460]. If the reported Next-Hop MTU
is smaller than the minimum IPv6 MTU, the receiving host is not is smaller than the minimum IPv6 MTU, the receiving host is not
required to reduce the Path-MTU to a value smaller than 1280, but is required to reduce the Path-MTU to a value smaller than 1280, but is
required to include a fragmentation header in the outgoing packets to required to include a fragmentation header in the outgoing packets to
that destination from that moment on. that destination from that moment on.
7.2. Attack-specific counter-measures 7.2. Attack-Specific Counter-Measures
The IETF has standardized a Path-MTU Discovery mechanism called The IETF has standardized a Path-MTU Discovery mechanism called
"Packetization Layer Path MTU Discovery" that does not depend on ICMP "Packetization Layer Path MTU Discovery" (PLPMTUD) that does not
error messages. Implementation of the aforementioned mechanism in depend on ICMP error messages. Implementation of the aforementioned
replacement of the traditional PMTUD (specified in [RFC1191] and mechanism in replacement of the traditional PMTUD (specified in
[RFC1981]) eliminates this vulnerability. However, it can also lead [RFC1191] and [RFC1981]) eliminates this vulnerability. However, it
to an increase of the PMTUD convergence time. can also lead to an increase in PMTUD convergence time.
This section describes a modification to the PMTUD mechanism This section describes a modification to the PMTUD mechanism
specified in [RFC1191] and [RFC1981] that has been incorporated in specified in [RFC1191] and [RFC1981] that has been incorporated in
OpenBSD and NetBSD (since 2005) to improve TCP's resistance to the OpenBSD and NetBSD (since 2005) to improve TCP's resistance to the
blind performance-degrading attack described in Section 7.1. The blind performance-degrading attack described in Section 7.1. The
described mechanism basically disregards ICMP messages when a described counter-measure basically disregards ICMP messages when a
connection makes progress, without violating any of the requirements connection makes progress, without violating any of the requirements
stated in [RFC1191] and [RFC1981]. stated in [RFC1191] and [RFC1981].
Henceforth, we will refer to both ICMP "fragmentation needed and DF Henceforth, we will refer to both ICMPv4 "fragmentation needed and DF
bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too
Big" messages. Big" messages.
In addition to the general validation check described in Section 4.1, In addition to the general validation check described in Section 4.1,
these implementations include a modification to TCP's reaction to these implementations include a modification to TCP's reaction to
ICMP "Packet Too Big" error messages that disregards them when a ICMP "Packet Too Big" error messages that disregards them when a
connection makes progress, and honors them only after the connection makes progress, and honors them only after the
corresponding data have been retransmitted a specified number of corresponding data have been retransmitted a specified number of
times. This means that upon receipt of an ICMP "Packet Too Big" times. This means that upon receipt of an ICMP "Packet Too Big"
error message, TCP just records this information, and honors it only error message, TCP just records this information, and honors it only
skipping to change at page 20, line 13 skipping to change at page 19, line 21
This would be particularly annoying for connections that have just This would be particularly annoying for connections that have just
been established, as it might take TCP several transmission attempts been established, as it might take TCP several transmission attempts
(and the corresponding timeouts) before it discovers the PMTU for the (and the corresponding timeouts) before it discovers the PMTU for the
corresponding connection. Thus, this policy would increase the time corresponding connection. Thus, this policy would increase the time
it takes for data to begin to be received at the destination host. it takes for data to begin to be received at the destination host.
In order to protect TCP from the attack against the PMTUD mechanism, In order to protect TCP from the attack against the PMTUD mechanism,
while still allowing TCP to quickly determine the initial Path-MTU while still allowing TCP to quickly determine the initial Path-MTU
for a connection, the aforementioned implementations have divided the for a connection, the aforementioned implementations have divided the
traditional PMTUD mechanism into two stages: Initial Path-MTU traditional PMTUD mechanism into two stages: Initial Path-MTU
Discovery, and Path-MTU Update. Discovery and Path-MTU Update.
The Initial Path-MTU Discovery stage is when TCP tries to send The Initial Path-MTU Discovery stage is when TCP tries to send
segments that are larger than the ones that have so far been sent and segments that are larger than the ones that have so far been sent and
acknowledged for this connection. That is, in the Initial Path-MTU acknowledged for this connection. That is, in the Initial Path-MTU
Discovery stage TCP has no record of these large segments getting to Discovery stage, TCP has no record of these large segments getting to
the destination host, and thus these implementations believe the the destination host, and thus these implementations believe the
network when it reports that these packets are too large to reach the network when it reports that these packets are too large to reach the
destination host without being fragmented. destination host without being fragmented.
The Path-MTU Update stage is when TCP tries to send segments that are The Path-MTU Update stage is when TCP tries to send segments that are
equal to or smaller than the ones that have already been sent and equal to or smaller than the ones that have already been sent and
acknowledged for this connection. During the Path-MTU Update stage, acknowledged for this connection. During the Path-MTU Update stage,
TCP already has knowledge of the estimated Path-MTU for the given TCP already has knowledge of the estimated Path-MTU for the given
connection. Thus, in this case these implementations are more connection. Thus, in this case, these implementations are more
cautious with the errors being reported by the network. cautious with the errors being reported by the network.
In order to allow TCP to distinguish segments between those In order to allow TCP to distinguish segments between those
performing Initial Path-MTU Discovery and those performing Path-MTU performing Initial Path-MTU Discovery and those performing Path-MTU
Update, two new variables are introduced to TCP: maxsizeacked and Update, two new variables are introduced to TCP: maxsizesent and
maxsizesent. maxsizeacked.
maxsizesent holds the size (in octets) of the largest packet that has The maxsizesent variable holds the size (in octets) of the largest
so far been sent for this connection. It is initialized to 68 (the packet that has so far been sent for this connection. It is
minimum IPv4 MTU) when the underlying internet protocol is IPv4, and initialized to 68 (the minimum IPv4 MTU) when the underlying Internet
is initialized to 1280 (the minimum IPv6 MTU) when the underlying Protocol is IPv4, and is initialized to 1280 (the minimum IPv6 MTU)
internet protocol is IPv6. Whenever a packet larger than maxsizesent when the underlying Internet Protocol is IPv6. Whenever a packet
octets is sent, maxsizesent is set to that value. larger than maxsizesent octets is sent, maxsizesent is set to that
value.
On the other hand, maxsizeacked holds the size (in octets) of the On the other hand, maxsizeacked holds the size (in octets) of the
largest packet (data, plus headers) that has so far been acknowledged largest packet (data, plus headers) that has so far been acknowledged
for this connection. It is initialized to 68 (the minimum IPv4 MTU) for this connection. It is initialized to 68 (the minimum IPv4 MTU)
when the underlying internet protocol is IPv4, and is initialized to when the underlying Internet Protocol is IPv4, and is initialized to
1280 (the minimum IPv6 MTU) when the underlying internet protocol is 1280 (the minimum IPv6 MTU) when the underlying Internet Protocol is
IPv6. Whenever an acknowledgement for a packet larger than IPv6. Whenever an acknowledgement for a packet larger than
maxsizeacked octets is received, maxsizeacked is set to the size of maxsizeacked octets is received, maxsizeacked is set to the size of
that acknowledged packet. Note that because of TCP's cumulative that acknowledged packet. Note that because of TCP's cumulative
acknowledgement, a single ACK may acknowledge the receipt of more acknowledgement, a single ACK may acknowledge the receipt of more
than one packet. When that happens, the algorithm may "incorrectly" than one packet. When that happens, the algorithm may "incorrectly"
asume it is in the "Path-MTU Update" stage, rather than the "Initial assume it is in the "Path-MTU Update" stage, rather than the "Initial
Path-MTU Discovery" stage (as described bellow). Path-MTU Discovery" stage (as described below).
Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop
MTU claimed by the ICMP message (henceforth "claimedmtu") is compared MTU claimed by the ICMP message (henceforth "claimedmtu") is compared
with maxsizesent. If claimedmtu is larger than maxsizesent, then the with maxsizesent. If claimedmtu is larger than maxsizesent, then the
ICMP error message is silently discarded. The rationale for this is ICMP error message is silently discarded. The rationale for this is
that the ICMP error message cannot be legitimate if it claims to have that the ICMP error message cannot be legitimate if it claims to have
been triggered by a packet larger than the largest packet we have so been triggered by a packet larger than the largest packet we have so
far sent for this connection. far sent for this connection.
If this check is passed, claimedmtu is compared with maxsizeacked. If this check is passed, claimedmtu is compared with maxsizeacked.
If claimedmtu is equal to or larger than maxsizeacked, TCP is If claimedmtu is equal to or larger than maxsizeacked, TCP is
supposed to be at the Initial Path-MTU Discovery stage, and thus the supposed to be at the Initial Path-MTU Discovery stage, and thus the
ICMP "Packet Too Big" error message is honored immediately. That is, ICMP "Packet Too Big" error message is honored immediately. That is,
the assumed Path-MTU is updated according to the Next-Hop MTU claimed the assumed Path-MTU is updated according to the Next-Hop MTU claimed
in the ICMP error message. Also, maxsizesent is reset to the minimum in the ICMP error message. Also, maxsizesent is reset to the minimum
MTU of the internet protocol in use (68 for IPv4, and 1280 for IPv6). MTU of the Internet Protocol in use (68 for IPv4, and 1280 for IPv6).
On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is
supposed to be in the Path-MTU Update stage. At this stage, these supposed to be in the Path-MTU Update stage. At this stage, these
implementations are more cautious with the errors being reported by implementations are more cautious with the errors being reported by
the network, and therefore just record the received error message, the network, and therefore just record the received error message,
and delay the update of the assumed Path-MTU. and delay the update of the assumed Path-MTU.
To perform this delay, one new variable and one new parameter is To perform this delay, one new variable and one new parameter are
introduced to TCP: nsegrto and MAXSEGRTO. nsegrto holds the number of introduced to TCP: nsegrto and MAXSEGRTO. The nsegrto variable holds
times a specified segment has timed out. It is initialized to zero, the number of times a specified segment has timed out. It is
and is incremented by one every time the corresponding segment times initialized to zero, and is incremented by one every time the
out. MAXSEGRTO specifies the number of times a given segment must corresponding segment times out. MAXSEGRTO specifies the number of
timeout before an ICMP "Packet Too Big" error message can be honored, times a given segment must time out before an ICMP "Packet Too Big"
and can be set, in principle, to any value greater than or equal to error message can be honored, and can be set, in principle, to any
0. value greater than or equal to 0.
Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a
pending ICMP "Packet Too Big" error message, the corresponding error pending ICMP "Packet Too Big" error message, the corresponding error
message is processed. At that point, maxsizeacked is set to message is processed. At that point, maxsizeacked is set to
claimedmtu, and maxsizesent is set to 68 (for IPv4) or 1280 (for claimedmtu, and maxsizesent is set to 68 (for IPv4) or 1280 (for
IPv6). IPv6).
If while there is a pending ICMP "Packet Too Big" error message the If, while there is a pending ICMP "Packet Too Big" error message, the
TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK
that acknowledges that sequence number is received), then the that acknowledges that sequence number is received), then the
"pending error" condition is cleared. "pending error" condition is cleared.
The rationale behind performing this delayed processing of ICMP The rationale behind performing this delayed processing of ICMP
"Packet Too Big" messages is that if there is progress on the "Packet Too Big" messages is that if there is progress on the
connection, the ICMP "Packet Too Big" errors must be a false claim. connection, the ICMP "Packet Too Big" errors must be a false claim.
By checking for progress on the connection, rather than just for By checking for progress on the connection, rather than just for
staleness of the received ICMP messages, TCP is protected from attack staleness of the received ICMP messages, TCP is protected from attack
even if the offending ICMP messages are "in window", and as a even if the offending ICMP messages are "in window", and as a
corollary, is made more robust to spurious ICMP messages triggered corollary, is made more robust to spurious ICMP messages triggered
by, for example, corrupted TCP segments. by, for example, corrupted TCP segments.
MAXSEGRTO can be set, in principle, to any value greater than or MAXSEGRTO can be set, in principle, to any value greater than or
equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the
traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A
MAXSEGRTO of 1 provides enough protection for most cases. In any MAXSEGRTO of 1 provides enough protection for most cases. In any
skipping to change at page 22, line 38 skipping to change at page 22, line 5
this counter-measure in pseudo-code. this counter-measure in pseudo-code.
It is important to note that the mechanism described in this section It is important to note that the mechanism described in this section
is an improvement to the current Path-MTU discovery mechanism, to is an improvement to the current Path-MTU discovery mechanism, to
mitigate its security implications. The current PMTUD mechanism, as mitigate its security implications. The current PMTUD mechanism, as
specified by [RFC1191] and [RFC1981], still suffers from some specified by [RFC1191] and [RFC1981], still suffers from some
functionality problems [RFC2923] that this document does not aim to functionality problems [RFC2923] that this document does not aim to
address. A mechanism that addresses those issues is described in address. A mechanism that addresses those issues is described in
[RFC4821]. [RFC4821].
7.3. The counter-measure for the PMTUD attack in action 7.3. The Counter-Measure for the PMTUD Attack in Action
This section illustrates the operation of the counter-measure for the This section illustrates the operation of the counter-measure for the
ICMP attack against the PMTUD mechanism that has been implemented in ICMP attack against the PMTUD mechanism that has been implemented in
OpenBSD and NetBSD . It shows both how the fix protects TCP from OpenBSD and NetBSD. It shows both how the fix protects TCP from
being attacked and how the counter-measure works in normal scenarios. being attacked and how the counter-measure works in normal scenarios.
As discussed in Section 7.2, this section assumes the PMTUD-specific As discussed in Section 7.2, this section assumes the PMTUD-specific
counter-measure is implemented in addition to the TCP sequence number counter-measure is implemented in addition to the TCP sequence number
checking described in Section 4.1. checking described in Section 4.1.
Figure 1 illustrates an hypothetical scenario in which two hosts are Figure 1 illustrates a hypothetical scenario in which two hosts are
connected by means of three intermediate routers. It also shows the connected by means of three intermediate routers. It also shows the
MTU of each hypothetical hop. All the following subsections assume MTU of each hypothetical hop. All the following subsections assume
the network setup of this figure. the network setup of this figure.
Also, for simplicity sake, all subsections assume an IP header of 20 Also, for simplicity's sake, all subsections assume an IP header of
octets and a TCP header of 20 octets. Thus, for example, when the 20 octets and a TCP header of 20 octets. Thus, for example, when the
PMTU is assumed to be 1500 octets, TCP will send segments that PMTU is assumed to be 1500 octets, TCP will send segments that
contain, at most, 1460 octets of data. contain, at most, 1460 octets of data.
For simplicity sake, all the following subsections assume the TCP For simplicity's sake, all the following subsections assume the TCP
implementation at Host 1 has chosen a a MAXSEGRTO of 1. implementation at Host 1 (H1) has chosen a MAXSEGRTO of 1.
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 | | H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
MTU=4464 MTU=2048 MTU=1500 MTU=4464 MTU=4464 MTU=2048 MTU=1500 MTU=4464
Figure 1: Hypothetical scenario Figure 1: Hypothetical Scenario
7.3.1. Normal operation for bulk transfers 7.3.1. Normal Operation for Bulk Transfers
This subsection shows the counter-measure in normal operation, when a This subsection shows the counter-measure in normal operation, when a
TCP connection is used for bulk transfers. That is, it shows how the TCP connection is used for bulk transfers. That is, it shows how the
counter-measure works when there is no attack taking place, and a TCP counter-measure works when there is no attack taking place and a TCP
connection is used for transferring large amounts of data. This connection is used for transferring large amounts of data. This
section assumes that just after the connection is established, one of section assumes that just after the connection is established, one of
the TCP endpoints begins to transfer data in packets that are as the TCP endpoints begins to transfer data in packets that are as
large as possible. large as possible.
Host 1 Host 2 Host 1 Host 2
1. --> <SEQ=100><CTL=SYN> --> 1. --> <SEQ=100><CTL=SYN> -->
2. <-- <SEQ=X><ACK=101><CTL=SYN,ACK> <-- 2. <-- <SEQ=X><ACK=101><CTL=SYN,ACK> <--
3. --> <SEQ=101><ACK=X+1><CTL=ACK> --> 3. --> <SEQ=101><ACK=X+1><CTL=ACK> -->
4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=4424> --> 4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=4424> -->
5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1 5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1
6. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=2008> --> 6. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=2008> -->
7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2 7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2
8. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=1460> --> 8. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=1460> -->
9. <-- <SEQ=X+1><ACK=1561><CTL=ACK> <-- 9. <-- <SEQ=X+1><ACK=1561><CTL=ACK> <--
Figure 2: Normal operation for bulk transfers Figure 2: Normal Operation for Bulk Transfers
nsegrto is initialized to zero. Both maxsizeacked and maxsizesent The nsegrto variable is initialized to zero. Both maxsizeacked and
are initialized to the minimum MTU for the internet protocol being maxsizesent are initialized to the minimum MTU for the Internet
used (68 for IPv4, and 1280 for IPv6). Protocol being used (68 for IPv4, and 1280 for IPv6).
In lines 1 to 3 the three-way handshake takes place, and the In lines 1 to 3, the three-way handshake takes place, and the
connection is established. In line 4, H1 tries to send a full-sized connection is established. In line 4, H1 tries to send a full-sized
TCP segment. As described by [RFC1191] and [RFC1981], in this case TCP segment. As described by [RFC1191] and [RFC1981], in this case,
TCP will try to send a segment with 4424 bytes of data, which will TCP will try to send a segment with 4424 bytes of data, which will
result in an IP packet of 4464 octets. Therefore, maxsizesent is set result in an IP packet of 4464 octets. Therefore, maxsizesent is set
to 4464. When the packet reaches R1, it elicits an ICMP "Packet Too to 4464. When the packet reaches R1, it elicits an ICMP "Packet Too
Big" error message. Big" error message.
In line 5, H1 receives the ICMP error message, which reports a Next- In line 5, H1 receives the ICMP error message, which reports a Next-
Hop MTU of 2048 octets. After performing the TCP sequence number Hop MTU of 2048 octets. After performing the TCP sequence number
check described in Section 4.1, the Next-Hop MTU reported by the ICMP check described in Section 4.1, the Next-Hop MTU reported by the ICMP
error message (claimedmtu) is compared with maxsizesent. As it is error message (claimedmtu) is compared with maxsizesent. As it is
smaller than maxsizesent, it passes the check, and thus is then smaller than maxsizesent, it passes the check, and thus is then
compared with maxsizeacked. As claimedmtu is larger than compared with maxsizeacked. As claimedmtu is larger than
maxsizeacked, TCP assumes that the corresponding TCP segment was maxsizeacked, TCP assumes that the corresponding TCP segment was
performing the Initial PMTU Discovery. Therefore, the TCP at H1 performing the Initial PMTU Discovery. Therefore, the TCP at H1
honors the ICMP message by updating the assumed Path-MTU. maxsizesent honors the ICMP message by updating the assumed Path-MTU. The
is reset to the minimum MTU of the internet protocol in use (68 for maxsizesent variable is reset to the minimum MTU of the Internet
IPv4, and 1280 for IPv6). Protocol in use (68 for IPv4, and 1280 for IPv6).
In line 6, the TCP at H1 sends a segment with 2008 bytes of data, In line 6, the TCP at H1 sends a segment with 2008 bytes of data,
which results in an IP packet of 2048 octets. maxsizesent is thus set which results in an IP packet of 2048 octets. The maxsizesent
to 2008 bytes. When the packet reaches R2, it elicits an ICMP variable is thus set to 2008 bytes. When the packet reaches R2, it
"Packet Too Big" error message. elicits an ICMP "Packet Too Big" error message.
In line 7, H1 receives the ICMP error message, which reports a Next- In line 7, H1 receives the ICMP error message, which reports a Next-
Hop MTU of 1500 octets. After performing the TCP sequence number Hop MTU of 1500 octets. After performing the TCP sequence number
check, the Next-Hop MTU reported by the ICMP error message check, the Next-Hop MTU reported by the ICMP error message
(claimedmtu) is compared with maxsizesent. As it is smaller than (claimedmtu) is compared with maxsizesent. As it is smaller than
maxsizesent, it passes the check, and thus is then compared with maxsizesent, it passes the check, and thus is then compared with
maxsizeacked. As claimedmtu is larger than maxsizeacked, TCP assumes maxsizeacked. As claimedmtu is larger than maxsizeacked, TCP assumes
that the corresponding TCP segment was performing the Initial PMTU that the corresponding TCP segment was performing the Initial PMTU
Discovery. Therefore, the TCP at H1 honors the ICMP message by Discovery. Therefore, the TCP at H1 honors the ICMP message by
updating the assumed Path-MTU. maxsizesent is reset to the minimum updating the assumed Path-MTU. The maxsizesent variable is reset to
MTU of the internet protocol in use. the minimum MTU of the Internet Protocol in use.
In line 8, the TCP at H1 sends a segment with 1460 bytes of data, In line 8, the TCP at H1 sends a segment with 1460 bytes of data,
which results in an IP packet of 1500 octets. maxsizesent is thus set which results in an IP packet of 1500 octets. Thus, maxsizesent is
to 1500. This packet reaches H2, where it elicits an acknowledgement set to 1500. This packet reaches H2, where it elicits an
(ACK) segment. acknowledgement (ACK) segment.
In line 9, H1 finally gets the acknowledgement for the data segment. In line 9, H1 finally gets the acknowledgement for the data segment.
As the corresponding packet was larger than maxsizeacked, TCP updates As the corresponding packet was larger than maxsizeacked, TCP updates
maxsizeacked, setting it to 1500. At this point TCP has discovered maxsizeacked, setting it to 1500. At this point, TCP has discovered
the Path-MTU for this TCP connection. the Path-MTU for this TCP connection.
7.3.2. Operation during Path-MTU changes 7.3.2. Operation during Path-MTU Changes
Let us suppose a TCP connection between H1 and H2 has already been Let us suppose a TCP connection between H1 and H2 has already been
established, and that the PMTU for the connection has already been established, and that the PMTU for the connection has already been
discovered to be 1500. At this point, both maxsizesent and discovered to be 1500. At this point, both maxsizesent and
maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose
some time later the PMTU decreases to 1492. For simplicity, let us some time later the PMTU decreases to 1492. For simplicity, let us
suppose that the Path-MTU has decreased because the MTU of the link suppose that the Path-MTU has decreased because the MTU of the link
between R2 and R3 has decreased from 1500 to 1492. Figure 3 between R2 and R3 has decreased from 1500 to 1492. Figure 3
illustrates how the counter-measure would work in this scenario. illustrates how the counter-measure would work in this scenario.
Host 1 Host 2 Host 1 Host 2
1. (Path-MTU decreases) 1. (Path-MTU decreases)
2. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1460> --> 2. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1460> -->
3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2 3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2
4. (Segment times out) 4. (Segment times out)
5. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1452> --> 5. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1452> -->
6. <-- <SEQ=X><ACK=1552><CTL=ACK> <-- 6. <-- <SEQ=X><ACK=1552><CTL=ACK> <--
Figure 3: Operation during Path-MTU changes Figure 3: Operation during Path-MTU Changes
In line 1, the Path-MTU for this connection decreases from 1500 to In line 1, the Path-MTU for this connection decreases from 1500 to
1492. In line 2, the TCP at H1, without being aware of the Path-MTU 1492. In line 2, the TCP at H1, without being aware of the Path-MTU
change, sends a 1500-byte packet to H2. When the packet reaches R2, change, sends a 1500-byte packet to H2. When the packet reaches R2,
it elicits an ICMP "Packet Too Big" error message. it elicits an ICMP "Packet Too Big" error message.
In line 3, H1 receives the ICMP error message, which reports a Next- In line 3, H1 receives the ICMP error message, which reports a Next-
Hop MTU of 1492 octets. After performing the TCP sequence number Hop MTU of 1492 octets. After performing the TCP sequence number
check, the Next-Hop MTU reported by the ICMP error message check, the Next-Hop MTU reported by the ICMP error message
(claimedmtu) is compared with maxsizesent. As claimedmtu is smaller (claimedmtu) is compared with maxsizesent. As claimedmtu is smaller
than maxsizesent, it is then compared with maxsizeacked. As than maxsizesent, it is then compared with maxsizeacked. As
claimedmtu is smaller than maxsizeacked (full-sized packets were claimedmtu is smaller than maxsizeacked (full-sized packets were
getting to the remote end-point), this packet is assumed to be getting to the remote endpoint), this packet is assumed to be
performing Path-MTU Update. And a "pending error" condition is performing Path-MTU Update, and a "pending error" condition is
recorded. recorded.
In line 4, the segment times out. Thus, nsegrto is incremented by 1. In line 4, the segment times out. Thus, nsegrto is incremented by 1.
As nsegrto is greater than or equal to MAXSEGRTO, the assumed Path- As nsegrto is greater than or equal to MAXSEGRTO, the assumed Path-
MTU is updated. nsegrto is reset to 0, and maxsizeacked is set to MTU is updated. The nsegrto variable is reset to 0, maxsizeacked is
claimedmtu, and maxsizesent is set to the minimum MTU of the internet set to claimedmtu, and maxsizesent is set to the minimum MTU of the
protocol in use. Internet Protocol in use.
In line 5, H1 retransmits the data using the updated PMTU, and thus In line 5, H1 retransmits the data using the updated PMTU, and thus
maxsizesent is set to 1492. The resulting packet reaches H2, where maxsizesent is set to 1492. The resulting packet reaches H2, where
it elicits an acknowledgement (ACK) segment. it elicits an acknowledgement (ACK) segment.
In line 6, H1 finally gets the acknowledgement for the data segment. In line 6, H1 finally gets the acknowledgement for the data segment.
At this point TCP has discovered the new Path-MTU for this TCP At this point, TCP has discovered the new Path-MTU for this TCP
connection. connection.
7.3.3. Idle connection being attacked 7.3.3. Idle Connection Being Attacked
Let us suppose a TCP connection between H1 and H2 has already been Let us suppose a TCP connection between H1 and H2 has already been
established, and the PMTU for the connection has already been established, and the PMTU for the connection has already been
discovered to be 1500. Figure 4 shows a sample time-line diagram discovered to be 1500. Figure 4 shows a sample time-line diagram
that illustrates an idle connection being attacked. that illustrates an idle connection being attacked.
Host 1 Host 2 Host 1 Host 2
1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=50> --> 1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=50> -->
2. <-- <SEQ=X><ACK=150><CTL=ACK> <-- 2. <-- <SEQ=X><ACK=150><CTL=ACK> <--
3. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 3. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
4. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 4. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
Figure 4: Idle connection being attacked Figure 4: Idle Connection Being Attacked
In line 1, H1 sends its last bunch of data. At line 2, H2 In line 1, H1 sends its last bunch of data. In line 2, H2
acknowledges the receipt of these data. Then the connection becomes acknowledges the receipt of these data. Then the connection becomes
idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet
Too Big" error messages to H1. Regardless of how many packets it Too Big" error messages to H1. Regardless of how many packets it
sends and the TCP sequence number each ICMP packet includes, none of sends and of the TCP sequence number each ICMP packet includes, none
these ICMP error messages will pass the TCP sequence number check of these ICMP error messages will pass the TCP sequence number check
described in Section 4.1, as H1 has no unacknowledged data in flight described in Section 4.1, as H1 has no unacknowledged data "in
to H2. Therefore, the attack does not succeed. flight" to H2. Therefore, the attack does not succeed.
7.3.4. Active connection being attacked after discovery of the Path-MTU 7.3.4. Active Connection Being Attacked after Discovery of the Path-MTU
Let us suppose an attacker attacks a TCP connection for which the Let us suppose an attacker attacks a TCP connection for which the
PMTU has already been discovered. In this case, as illustrated in PMTU has already been discovered. In this case, as illustrated in
Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a
possible packet exchange. possible packet exchange.
Host 1 Host 2 Host 1 Host 2
1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1460> --> 1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1460> -->
2. --> <SEQ=1560><ACK=X><CTL=ACK><DATA=1460> --> 2. --> <SEQ=1560><ACK=X><CTL=ACK><DATA=1460> -->
3. --> <SEQ=3020><ACK=X><CTL=ACK><DATA=1460> --> 3. --> <SEQ=3020><ACK=X><CTL=ACK><DATA=1460> -->
4. --> <SEQ=4480><ACK=X><CTL=ACK><DATA=1460> --> 4. --> <SEQ=4480><ACK=X><CTL=ACK><DATA=1460> -->
5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <--- 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
6. <-- <SEQ=X><CTL=ACK><ACK=1560> <-- 6. <-- <SEQ=X><CTL=ACK><ACK=1560> <--
Figure 5: Active connection being attacked after discovery of PMTU Figure 5: Active Connection Being Attacked after Discovery of PMTU
As we assume the PMTU has already been discovered, we also assume As we assume the PMTU has already been discovered, we also assume
both maxsizesent and maxsizeacked are equal to 1500. We assume both maxsizesent and maxsizeacked are equal to 1500. We assume
nsegrto is equal to zero, as there have been no segment timeouts. nsegrto is equal to zero, as there have been no segment timeouts.
In lines 1, 2, 3, and 4, H1 sends four data segments to H2. In line In lines 1, 2, 3, and 4, H1 sends four data segments to H2. In
5, an attacker sends a forged ICMP packet to H1. We assume the line 5, an attacker sends a forged ICMP error message to H1. We
attacker is lucky enough to guess both the four-tuple that identifies assume the attacker is lucky enough to guess both the four-tuple that
the connection and a valid TCP sequence number. As the Next-Hop MTU identifies the connection and a valid TCP sequence number. As the
claimed in the ICMP "Packet Too Big" message (claimedmtu) is smaller Next-Hop MTU claimed in the ICMP "Packet Too Big" message
than maxsizeacked, this packet is assumed to be performing Path-MTU (claimedmtu) is smaller than maxsizeacked, this packet is assumed to
Update. Thus, the error message is recorded. be performing Path-MTU Update. Thus, the error message is recorded.
In line 6, H1 receives an acknowledgement for the segment sent in In line 6, H1 receives an acknowledgement for the segment sent in
line 1, before it times out. At this point, the "pending error" line 1, before it times out. At this point, the "pending error"
condition is cleared, and the recorded ICMP "Packet Too Big" error condition is cleared, and the recorded ICMP "Packet Too Big" error
message is ignored. Therefore, the attack does not succeed. message is ignored. Therefore, the attack does not succeed.
7.3.5. TCP peer attacked when sending small packets just after the 7.3.5. TCP Peer Attacked when Sending Small Packets Just after the
three-way handshake Three-Way Handshake
This section analyzes an scenario in which a TCP peer that is sending This section analyzes a scenario in which a TCP peer that is sending
small segments just after the connection has been established, is small segments just after the connection has been established is
attacked. The connection could be being used by protocols such as attacked. The connection could be in use by protocols such as SMTP
SMTP [RFC5321] and HTTP [RFC2616], for example, which usually behave [RFC5321] and HTTP [RFC2616], for example, which usually behave like
like this. this.
Figure 6 shows a possible packet exchange for such scenario. Figure 6 shows a possible packet exchange for such a scenario.
Host 1 Host 2 Host 1 Host 2
1. --> <SEQ=100><CTL=SYN> --> 1. --> <SEQ=100><CTL=SYN> -->
2. <-- <SEQ=X><ACK=101><CTL=SYN,ACK> <-- 2. <-- <SEQ=X><ACK=101><CTL=SYN,ACK> <--
3. --> <SEQ=101><ACK=X+1><CTL=ACK> --> 3. --> <SEQ=101><ACK=X+1><CTL=ACK> -->
4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=100> --> 4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=100> -->
5. <-- <SEQ=X+1><ACK=201><CTL=ACK> <-- 5. <-- <SEQ=X+1><ACK=201><CTL=ACK> <--
6. --> <SEQ=201><ACK=X+1><CTL=ACK><DATA=100> --> 6. --> <SEQ=201><ACK=X+1><CTL=ACK><DATA=100> -->
7. --> <SEQ=301><ACK=X+1><CTL=ACK><DATA=100> --> 7. --> <SEQ=301><ACK=X+1><CTL=ACK><DATA=100> -->
8. <--- ICMP "Packet Too Big" MTU=150, TCPseq#=201 <--- 8. <--- ICMP "Packet Too Big" MTU=150, TCPseq#=201 <---
Figure 6: TCP peer attacked when sending small packets just after the Figure 6: TCP Peer Attacked when Sending Small Packets
three-way handshake Just after the Three-Way Handshake
nsegrto is initialized to zero. Both maxsizesent and maxsizeacked The nsegrto variable is initialized to zero. Both maxsizesent and
are initialized to the minimum MTU for the internet protocol being maxsizeacked are initialized to the minimum MTU for the Internet
used (68 for IPv4, and 1280 for IPv6). Protocol being used (68 for IPv4, and 1280 for IPv6).
In lines 1 to 3 the three-way handshake takes place, and the In lines 1 to 3, the three-way handshake takes place, and the
connection is established. At this point, the assumed Path-MTU for connection is established. At this point, the assumed Path-MTU for
this connection is 4464. In line 4, H1 sends a small segment (which this connection is 4464. In line 4, H1 sends a small segment (which
results in a 140-byte packet) to H2. maxsizesent is thus set to 140. results in a 140-byte packet) to H2. Therefore, maxsizesent is set
In line 5 this segment is acknowledged, and thus maxsizeacked is set to 140. In line 5, this segment is acknowledged, and thus
to 140. maxsizeacked is set to 140.
In lines 6 and 7, H1 sends two small segments to H2. In line 8, In lines 6 and 7, H1 sends two small segments to H2. In line 8,
while the segments from lines 6 and 7 are still in flight to H2, an while the segments from lines 6 and 7 are still "in flight" to H2, an
attacker sends a forged ICMP "Packet Too Big" error message to H1. attacker sends a forged ICMP "Packet Too Big" error message to H1.
Assuming the attacker is lucky enough to guess a valid TCP sequence Assuming the attacker is lucky enough to guess a valid TCP sequence
number, this ICMP message will pass the TCP sequence number check. number, this ICMP message will pass the TCP sequence number check.
The Next-Hop MTU reported by the ICMP error message (claimedmtu) is The Next-Hop MTU reported by the ICMP error message (claimedmtu) is
then compared with maxsizesent. As claimedmtu is larger than then compared with maxsizesent. As claimedmtu is larger than
maxsizesent, the ICMP error message is silently discarded. maxsizesent, the ICMP error message is silently discarded.
Therefore, the attack does not succeed. Therefore, the attack does not succeed.
7.4. Pseudo-code for the counter-measure for the blind performance- 7.4. Pseudo-Code for the Counter-Measure for the Blind Performance-
degrading attack Degrading Attack
This section contains a pseudo-code version of the counter-measure This section contains a pseudo-code version of the counter-measure
described in Section 7.2 for the blind performance-degrading attack described in Section 7.2 for the blind performance-degrading attack
described in Section 7. It is meant as guidance for developers on described in Section 7. It is meant as guidance for developers on
how to implement this counter-measure. how to implement this counter-measure.
The pseudo-code makes use of the following variables, constants, and The pseudo-code makes use of the following variables, constants, and
functions: functions:
ack ack
Variable holding the acknowledgement number contained in the TCP Variable holding the acknowledgement number contained in the TCP
segment that has just been received. segment that has just been received.
acked_packet_size acked_packet_size
Variable holding the packet size (data, plus headers) the ACK that Variable holding the packet size (data, plus headers) that the ACK
has just been received is acknowledging. that has just been received is acknowledging.
adjust_mtu() adjust_mtu()
Function that adjusts the MTU for this connection, according to Function that adjusts the MTU for this connection, according to
the ICMP "Packet Too Big" that was last received. the ICMP "Packet Too Big" that was last received.
claimedmtu claimedmtu
Variable holding the Next-Hop MTU advertised by the ICMP "Packet Variable holding the Next-Hop MTU advertised by the ICMP "Packet
Too Big" error message. Too Big" error message.
claimedtcpseq claimedtcpseq
skipping to change at page 30, line 17 skipping to change at page 29, line 14
pending_message pending_message
Variable (flag) that indicates whether there is a pending ICMP Variable (flag) that indicates whether there is a pending ICMP
"Packet Too Big" message to be processed. "Packet Too Big" message to be processed.
save_message() save_message()
Function that records the ICMP "Packet Too Big" message that has Function that records the ICMP "Packet Too Big" message that has
just been received. just been received.
MINIMUM_MTU MINIMUM_MTU
Constant holding the minimum MTU for the internet protocol in use Constant holding the minimum MTU for the Internet Protocol in use
(68 for IPv4, and 1280 for IPv6). (68 for IPv4, and 1280 for IPv6).
MAXSEGRTO MAXSEGRTO
Constant holding the number of times a given segment must timeout Constant holding the number of times a given segment must time out
before an ICMP "Packet Too Big" error message can be honored. before an ICMP "Packet Too Big" error message can be honored.
EVENT: New TCP connection EVENT: New TCP connection
current_mtu = initial_mtu; current_mtu = initial_mtu;
maxsizesent = MINIMUM_MTU; maxsizesent = MINIMUM_MTU;
maxsizeacked = MINIMUM_MTU; maxsizeacked = MINIMUM_MTU;
nsegrto = 0; nsegrto = 0;
pending_message = 0; pending_message = 0;
EVENT: Segment is sent EVENT: Segment is sent
if (packet_size > maxsizesent)
maxsizesent = packet_size; if (packet_size > maxsizesent)
maxsizesent = packet_size;
EVENT: Segment is received EVENT: Segment is received
if (acked_packet_size > maxsizeacked) if (acked_packet_size > maxsizeacked)
maxsizeacked = acked_packet_size; maxsizeacked = acked_packet_size;
if (pending_message) if (pending_message)
if (ack > claimedtcpseq){ if (ack > claimedtcpseq){
pending_message = 0; pending_message = 0;
nsegrto = 0; nsegrto = 0;
} }
EVENT: ICMP "Packet Too Big" message is received EVENT: ICMP "Packet Too Big" message is received
if (claimedmtu <= MINIMUM_MTU)
drop_message();
if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >= SND.NXT){ if (claimedmtu <= MINIMUM_MTU)
drop_message(); drop_message();
}
else { if (claimedtcpseq < SND.UNA || claimedtcpseq >= SND.NXT)
if (claimedmtu > maxsizesent || claimedmtu >= current_mtu) drop_message();
drop_message();
else { else {
if (claimedmtu > maxsizeacked){ if (claimedmtu > maxsizesent || claimedmtu >= current_mtu)
adjust_mtu(); drop_message();
current_mtu = claimedmtu;
maxsizesent = MINIMUM_MTU;
}
else { else {
pending_message = 1; if (claimedmtu > maxsizeacked){
save_message(); adjust_mtu();
} current_mtu = claimedmtu;
} maxsizesent = MINIMUM_MTU;
} }
else {
pending_message = 1;
save_message();
}
}
}
EVENT: Segment times out EVENT: Segment times out
nsegrto++; nsegrto++;
if (pending_message && nsegrto >= MAXSEGRTO){ if (pending_message && nsegrto >= MAXSEGRTO){
adjust_mtu(); adjust_mtu();
nsegrto = 0; nsegrto = 0;
pending_message = 0; pending_message = 0;
maxsizeacked = claimedmtu; maxsizeacked = claimedmtu;
maxsizesent = MINIMUM_MTU; maxsizesent = MINIMUM_MTU;
current_mtu = claimedmtu; current_mtu = claimedmtu;
} }
Notes: Notes:
All comparisons between sequence numbers must be performed using All comparisons between sequence numbers must be performed using
sequence number arithmetic. sequence number arithmetic.
The pseudo-code implements the mechanism described in Section 7.2, The pseudo-code implements the mechanism described in Section 7.2,
the TCP sequence number checking described in Section 4.1, and the the TCP sequence number checking described in Section 4.1, and the
validation check on the advertised Next-Hop MTU described in validation check on the advertised Next-Hop MTU described in
[RFC1191] and [RFC1981]. [RFC1191] and [RFC1981].
8. Security Considerations 8. Security Considerations
This document describes the use of ICMP error messages to perform a This document describes the use of ICMP error messages to perform a
number of attacks against the TCP protocol, and describes a number of number of attacks against TCP, and describes a number of widely
widely-implemented counter-measures that either eliminate or reduce implemented counter-measures that either eliminate or reduce the
the impact of these attacks when they are performed by off-path impact of these attacks when they are performed by off-path
attackers. attackers.
Section 4.1 describes a validation check that could be enforced on Section 4.1 describes a validation check that could be enforced on
ICMP error messages, such that TCP reacts only to those ICMP error ICMP error messages, such that TCP reacts only to those ICMP error
messages that appear to relate to segments currently "in-flight" to messages that appear to relate to segments currently "in flight" to
the destination system. This requires more effort on the side of an the destination system. This requires more effort on the side of an
off-path attacker at the expense of possible reduced responsiveness off-path attacker at the expense of possible reduced responsiveness
to network errors. to network errors.
Section 4.2 describes how obfuscation of TCP ephemeral ports require Section 4.2 describes how randomization of TCP ephemeral ports
more effort on the side of the attacker to successfully exploit any requires more effort on the side of the attacker to successfully
of the attacks described in this document. exploit any of the attacks described in this document.
Section 4.3 describes how ICMP error messages could possibly be Section 4.3 describes how ICMP error messages could possibly be
filtered based on their payload, to prevent users of the local filtered based on their payload, to prevent users of the local
network from successfully performing attacks against third-party network from successfully performing attacks against third-party
connections. This is analogous to ingress filtering and egress connections. This is analogous to ingress filtering and egress
filtering of IP packets [IP-filtering]. filtering of IP packets [IP-filtering].
Section 5.2 describes an attack-specific counter-measure for the Section 5.2 describes an attack-specific counter-measure for the
blind connection-reset attack. It describes the processing of ICMP blind connection-reset attack. It describes the processing of ICMP
"hard errors" as "soft errors" when they are received for connections "hard errors" as "soft errors" when they are received for connections
in any of the synchronized states. This countermeasure eliminates in any of the synchronized states. This counter-measure eliminates
the aforementioned vulnerability in synchronized connections at the the aforementioned vulnerability in synchronized connections at the
expense of a possible reduced responsiveness in some network expense of possible reduced responsiveness in some network scenarios.
scenarios.
Section 6.2 describes an attack-specific counter-measure for the Section 6.2 describes an attack-specific counter-measure for the
blind throughput-reduction attack. It suggests that the blind throughput-reduction attack. It suggests that the
aforementioned vulnerability can be eliminated by ignoring ICMP aforementioned vulnerability can be eliminated by ignoring ICMPv4
Source Quench messages meant for TCP connections. This is in Source Quench messages meant for TCP connections. This is in
accordance with research results that indicate that ICMP Source accordance with research results that indicate that ICMPv4 Source
Quench messages are ineffective and unfair antidote for congestion. Quench messages are ineffective and are an unfair antidote for
congestion.
Finally, Section 7.2 describes an attack-specific countermeasure for Finally, Section 7.2 describes an attack-specific counter-measure for
the blind performance-degrading attack. It consists of the the blind performance-degrading attack. It consists of the
validation check described in Section 4.1, with a modification that validation check described in Section 4.1, with a modification that
makes TCP react to ICMP "Packet Too Big" error messages such that makes TCP react to ICMP "Packet Too Big" error messages such that
they are processed when an outstanding TCP segment times out. This they are processed when an outstanding TCP segment times out. This
countermeasures parallels the Packetization Layer Path MTU Discovery counter-measure parallels the Packetization Layer Path MTU Discovery
(PLPMTUD) mechanism [RFC4821]. It should be noted that if this (PLPMTUD) mechanism [RFC4821]. It should be noted that if this
counter-measure is implemented, in some scenarios TCP may respond counter-measure is implemented, in some scenarios TCP may respond
more slowly to valid ICMP "Packet Too Big" error messages. more slowly to valid ICMP "Packet Too Big" error messages.
A discussion of these and other attack vectors for performing similar A discussion of these and other attack vectors for performing similar
attacks against TCP (along with possible counter-measures) can be attacks against TCP (along with possible counter-measures) can be
found in [CPNI-TCP] and [I-D.ietf-tcpm-tcp-security]. found in [CPNI-TCP] and [TCP-SECURITY].
9. IANA Considerations
This document has no actions for IANA. The RFC-Editor can remove
this section before publication of this document as an RFC.
10. Acknowledgements 9. Acknowledgements
This document was inspired by Mika Liljeberg, while discussing some This document was inspired by Mika Liljeberg, while discussing some
issues related to [RFC5461] by private e-mail. The author would like issues related to [RFC5461] by private e-mail. The author would like
to thank (in alphabetical order): Bora Akyol, Mark Allman, Ran to thank (in alphabetical order): Bora Akyol, Mark Allman, Ran
Atkinson, James Carlson, Alan Cox, Theo de Raadt, Wesley Eddy, Lars Atkinson, James Carlson, Alan Cox, Theo de Raadt, Wesley Eddy, Lars
Eggert, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo Gont, Eggert, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo Gont,
John Heffner, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, Mika John Heffner, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, Mika
Liljeberg, Matt Mathis, David Miller, Toby Moncaster, Miles Nordin, Liljeberg, Matt Mathis, David Miller, Toby Moncaster, Miles Nordin,
Eloy Paris, Kacheong Poon, Andrew Powell, Pekka Savola, Donald Smith, Eloy Paris, Kacheong Poon, Andrew Powell, Pekka Savola, Donald Smith,
Pyda Srisuresh, Fred Templin, and Joe Touch for contributing many Pyda Srisuresh, Fred Templin, and Joe Touch for contributing many
valuable comments. valuable comments.
Juan Fraschini and the author of this document implemented freely- Juan Fraschini and the author of this document implemented freely
available audit tools to help vendors audit their systems by available audit tools to help vendors audit their systems by
reproducing the attacks discussed in this document. This tools are reproducing the attacks discussed in this document. These tools are
available at http://www.gont.com.ar/tools/index.html . available at http://www.gont.com.ar/tools/index.html.
Markus Friedl, Chad Loder, and the author of this document, produced Markus Friedl, Chad Loder, and the author of this document produced
and tested in OpenBSD [OpenBSD] the first implementation of the and tested in OpenBSD [OpenBSD] the first implementation of the
counter-measure described in Section 7.2. This first implementation counter-measure described in Section 7.2. This first implementation
helped to test the effectiveness of the ideas introduced in this helped to test the effectiveness of the ideas introduced in this
document, and has served as a reference implementation for other document, and has served as a reference implementation for other
operating systems. operating systems.
The author would like to thank the UK's Centre for the Protection of The author would like to thank the UK's Centre for the Protection of
National Infrastructure (CPNI) -- formerly National Infrastructure National Infrastructure (CPNI) -- formerly the National
Security Co-ordination Centre (NISCC) -- for coordinating the Infrastructure Security Co-ordination Centre (NISCC) -- for
disclosure of these issues with a large number of vendors and CSIRTs coordinating the disclosure of these issues with a large number of
(Computer Security Incident Response Teams). vendors and CSIRTs (Computer Security Incident Response Teams).
The author wishes to express deep and heartfelt gratitude to Jorge The author wishes to express deep and heartfelt gratitude to Jorge
Oscar Gont and Nelida Garcia, for their precious motivation and Oscar Gont and Nelida Garcia, for their precious motivation and
guidance. guidance.
11. References 10. References
11.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
April 2007.
11.2. Informative References
[CPNI-TCP]
CPNI, "Security Assessment of the Transmission Control
Protocol (TCP)", http://www.cpni.gov.uk/Docs/
tn-03-09-security-assessment-TCP.pdf, 2009.
[DClark] Clark, D., "The Design Philosophy of the DARPA Internet
Protocols", Computer Communication Review Vol. 18, No. 4,
1988.
[FreeBSD] The FreeBSD Project, "http://www.freebsd.org".
[I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-11
(work in progress), March 2010.
[I-D.ietf-tcpm-tcp-security]
Gont, F., "Security Assessment of the Transmission Control
Protocol (TCP)", draft-ietf-tcpm-tcp-security-01 (work in
progress), February 2010.
[I-D.ietf-tcpm-tcpsecure]
Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks",
draft-ietf-tcpm-tcpsecure-12 (work in progress),
September 2009.
[I-D.ietf-tsvwg-port-randomization]
Larsen, M. and F. Gont, "Transport Protocol Port
Randomization Recommendations",
draft-ietf-tsvwg-port-randomization-06 (work in progress),
February 2010.
[ICMP-Filtering]
Gont, F., "Filtering of ICMP error messages", http://
www.gont.com.ar/papers/
filtering-of-icmp-error-messages.pdf.
[IP-filtering]
NISCC, "NISCC Technical Note 01/2006: Egress and Ingress
Filtering", http://www.niscc.gov.uk/niscc/docs/
re-20060420-00294.pdf?lang=en, 2006.
[Linux] The Linux Project, "http://www.kernel.org".
[McKusick]
McKusick, M., Bostic, K., Karels, M., and J. Quarterman,
"The Design and Implementation of the 4.4BSD Operating
System", Addison-Wesley , 1996.
[NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP:
Vulnerability Issues in ICMP packets with TCP payloads",
http://www.niscc.gov.uk/niscc/docs/
al-20050412-00308.html?lang=en, 2005.
[NetBSD] The NetBSD Project, "http://www.netbsd.org".
[OpenBSD] The OpenBSD Project, "http://www.openbsd.org".
[OpenBSD-PF]
The OpenBSD Packet Filter,
"http://www.openbsd.org/faq/pf/".
[RFC0816] Clark, D., "Fault isolation and recovery", RFC 816,
July 1982.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, September 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[RFC4907] Aboba, B., "Architectural Implications of Link
Indications", RFC 4907, June 2007.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
February 2009.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009.
[US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP
Implementations do not adequately validate ICMP error
messages", http://www.kb.cert.org/vuls/id/222750, 2005.
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks",
2004 CanSecWest Conference , 2004.
[Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
The Implementation", Addison-Wesley , 1994.
Appendix A. Changes from previous versions of the draft (to be removed
by the RFC Editor before publishing this document as an
RFC)
A.1. Changes from draft-ietf-tcpm-icmp-attacks-10
o Addresses IESG review comments by Magnus Westerlund and
(partially) addresses IESG review comments by Tim Polk.
A.2. Changes from draft-ietf-tcpm-icmp-attacks-09
o Addresses AD review comments by Lars Eggert (hopefully :-) ).
A.3. Changes from draft-ietf-tcpm-icmp-attacks-08
o Fixes a couple of nits found by... Alfred!. Thanks! (again, and
again, and again....).
A.4. Changes from draft-ietf-tcpm-icmp-attacks-07
o Addresses some remaining WGLC feedback sent off-list by Donald
Smith and Guillermo Gont.
A.5. Changes from draft-ietf-tcpm-icmp-attacks-06
o Addresses WGLC feedback by Joe Touch and Donald Smith.
A.6. Changes from draft-ietf-tcpm-icmp-attacks-05
o Addresses feedback submitted by Wes Eddy
(http://www.ietf.org/mail-archive/web/tcpm/current/msg04573.html
and
http://www.ietf.org/mail-archive/web/tcpm/current/msg04574.html)
and Joe Touch (on June 8th... couldn't find online ref, sorry) on
the TCPM WG mailing-list.
A.7. Changes from draft-ietf-tcpm-icmp-attacks-04
o The draft had expired and thus is resubmitted with no further
changes. Currently working on a rev of the document (Please send
feedback!).
A.8. Changes from draft-ietf-tcpm-icmp-attacks-03
o The draft had expired and thus is resubmitted with no further
changes.
A.9. Changes from draft-ietf-tcpm-icmp-attacks-02
o Added a disclaimer to indicate that this document does not update
the current specifications.
o Addresses feedback sent off-list by Alfred Hoenes.
o The text (particularly that which describes the counter-measures)
was reworded to document what current implementations are doing,
rather than "proposing" the implementation of the counter-
measures.
o Some text has been removed: we're just documenting the problem,
and what existing implementations have done.
o Miscellaneous editorial changes.
A.10. Changes from draft-ietf-tcpm-icmp-attacks-01 10.1. Normative References
o Fixed references to the antispoof documents (were hardcoded and [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
missing in the References Section). September 1981.
o The draft had expired and thus is resubmitted with only a minor [RFC0792] Postel, J., "Internet Control Message Protocol",
editorial change. STD 5, RFC 792, September 1981.
A.11. Changes from draft-ietf-tcpm-icmp-attacks-00 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
o Added references to the specific sections of each of the [RFC1122] Braden, R., "Requirements for Internet Hosts -
referenced specifications Communication Layers", STD 3, RFC 1122,
October 1989.
o Corrected the threat analysis [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery",
RFC 1191, November 1990.
o Added clarification about whether the counter-measures violate the [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
current specifications or not. RFC 1812, June 1995.
o Changed text so that the document fits better in the Informational [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
path Discovery for IP version 6", RFC 1981, August 1996.
o Added a specific section on IPsec (Section 2.3) [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
o Added clarification and references on the use of ICMP filtering [RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
based on the ICMP payload Version 6 (IPv6) Specification", RFC 2460,
December 1998.
o Updated references to obsoleted RFCs [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
o Added a discussion of multipath scenarios, and possible lose in [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet
responsiveness resulting from the reaction to hard errors as soft Control Message Protocol (ICMPv6) for the Internet
errors Protocol Version 6 (IPv6) Specification", RFC 4443,
March 2006.
o Miscellaneous editorial changes [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages",
RFC 4884, April 2007.
A.12. Changes from draft-gont-tcpm-icmp-attacks-05 10.2. Informative References
o Removed RFC 2119 wording to make the draft suitable for [CPNI-TCP] CPNI, "Security Assessment of the Transmission
publication as an Informational RFC. Control Protocol (TCP)", http://www.cpni.gov.uk/
Docs/tn-03-09-security-assessment-TCP.pdf, 2009.
o Added additional checks that should be performed on ICMP error [DClark] Clark, D., "The Design Philosophy of the DARPA
messages (checksum of the IP header in the ICMP payload, and Internet Protocols", Computer Communication
others). Review Vol. 18, No. 4, 1988.
o Added clarification of the rationale behind each the TCP SEQ check [FreeBSD] The FreeBSD Project, http://www.freebsd.org.
o Miscellaneous editorial changes [ICMP-Filtering] Gont, F., "Filtering of ICMP error messages", http
://www.gont.com.ar/papers/
filtering-of-icmp-error-messages.pdf.
A.13. Changes from draft-gont-tcpm-icmp-attacks-04 [IP-filtering] NISCC, "NISCC Technical Note 01/2006: Egress and
Ingress Filtering",
http://www.cpni.gov.uk/Docs/re-20060420-00294.pdf,
2006.
o Added section on additional considerations for validating ICMP [Linux] The Linux Project, "http://www.kernel.org".
error messages
o Added reference to (draft) [RFC4907] [McKusick] McKusick, M., Bostic, K., Karels, M., and J.
Quarterman, "The Design and Implementation of the
4.4 BSD Operating System", Addison-Wesley, 1996.
o Added stress on the fact that ICMP error messages are unreliable [NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/
o Miscellaneous editorial changes ICMP: Vulnerability Issues in ICMP packets with TCP
payloads", http://www.cpni.gov.uk/docs/
re-20050412-00303.pdf?lang=en, 2005.
A.14. Changes from draft-gont-tcpm-icmp-attacks-03 [NetBSD] The NetBSD Project, "http://www.netbsd.org".
o Added references to existing implementations of the described [OpenBSD] The OpenBSD Project, "http://www.openbsd.org".
counter-measures
o The discussion in Section 4 was improved [OpenBSD-PF] The OpenBSD Packet Filter,
"http://www.openbsd.org/faq/pf/".
o The discussion of the blind connection-reset vulnerability was [PORT-RANDOM] Larsen, M. and F. Gont, "Transport Protocol Port
expanded and improved Randomization Recommendations", Work in Progress,
April 2010.
o The counter-measure for the attack against the PMTUD was improved [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816,
and simplified July 1982.
o Section 7.4 was added [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
o Miscellaneous editorial changes [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP
Extensions for High Performance", RFC 1323,
May 1992.
A.15. Changes from draft-gont-tcpm-icmp-attacks-02 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the
TCP MD5 Signature Option", RFC 2385, August 1998.
o Fixed errors in in the discussion of the blind connection-reset [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
attack Masinter, L., Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2616, June 1999.
o The counter-measure for the attack against the PMTUD mechanism was [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
refined to allow quick discovery of the Path-MTU RFC 2923, September 2000.
o Section 7.3 was added so as to clarify the operation of the [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
counter-measure for the attack against the PMTUD mechanism Addition of Explicit Congestion Notification (ECN)
to IP", RFC 3168, September 2001.
o Added CPNI contact information. [RFC3390] Allman, M., Floyd, S., and C. Partridge,
"Increasing TCP's Initial Window", RFC 3390,
October 2002.
o Miscellaneous editorial changes [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border
Gateway Protocol 4 (BGP-4)", RFC 4271,
January 2006.
A.16. Changes from draft-gont-tcpm-icmp-attacks-01 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer
Path MTU Discovery", RFC 4821, March 2007.
o The document was restructured for easier reading [RFC4907] Aboba, B., "Architectural Implications of Link
Indications", RFC 4907, June 2007.
o A discussion of ICMPv6 was added in several sections of the [RFC4953] Touch, J., "Defending TCP Against Spoofing
document Attacks", RFC 4953, July 2007.
o Added Section on Acknowledgement number checking [RFC5321] Klensin, J., "Simple Mail Transfer Protocol",
RFC 5321, October 2008.
o Added Section 4.3 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors",
RFC 5461, February 2009.
o Added Section 7 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP
o Fixed typo in the ICMP types, in several places Congestion Control", RFC 5681, September 2009.
o Fixed typo in the TCP sequence number check formula [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
o Miscellaneous editorial changes [TCP-SECURITY] Gont, F., "Security Assessment of the Transmission
Control Protocol (TCP)", Work in Progress,
February 2010.
A.17. Changes from draft-gont-tcpm-icmp-attacks-00 [TCPM-TCPSECURE] Ramaiah, A., Stewart, R., and M. Dalal, "Improving
TCP's Robustness to Blind In-Window Attacks", Work
in Progress, May 2010.
o Added a proposal to change the handling of the so-called ICMP hard [US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750:
errors during the synchronized states TCP/IP Implementations do not adequately validate
ICMP error messages",
http://www.kb.cert.org/vuls/id/222750, 2005.
o Added a summary of the relevant RFCs in several sections [Watson] Watson, P., "Slipping in the Window: TCP Reset
Attacks", CanSecWest Conference, 2004.
o Miscellaneous editorial changes [Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated,
Volume 2: The Implementation", Addison-
Wesley, 1994.
Author's Address Author's Address
Fernando Gont Fernando 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: fernando@gont.com.ar EMail: fernando@gont.com.ar
URI: http://www.gont.com.ar URI: http://www.gont.com.ar
 End of changes. 237 change blocks. 
806 lines changed or deleted 598 lines changed or added

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