< draft-gont-tcpm-icmp-attacks-04.txt   draft-gont-tcpm-icmp-attacks-05.txt >
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UTN/FRH Extensions (tcpm) UTN/FRH
Internet-Draft September 5, 2005 Internet-Draft October 24, 2005
Expires: March 9, 2006 Expires: April 27, 2006
ICMP attacks against TCP ICMP attacks against TCP
draft-gont-tcpm-icmp-attacks-04.txt draft-gont-tcpm-icmp-attacks-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
This document may not be modified, and derivative works of it may not This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into be created, except to publish it as an RFC and to translate it into
languages other than English. languages other than English.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 9, 2006. This Internet-Draft will expire on April 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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) and other similar protocols. It Transmission Control Protocol (TCP) and other similar protocols. It
proposes several counter-measures to eliminate or minimize the impact proposes several counter-measures to eliminate or minimize the impact
of these attacks. of these attacks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 4 2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5
2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 4 2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 5
2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 4 2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6
2.2. Handling of ICMP error messages . . . . . . . . . . . . . 5 2.2. Handling of ICMP error messages . . . . . . . . . . . . . 6
3. Constraints in the possible solutions . . . . . . . . . . . . 5 3. Constraints in the possible solutions . . . . . . . . . . . . 7
4. General counter-measures against ICMP attacks . . . . . . . . 7 4. General counter-measures against ICMP attacks . . . . . . . . 8
4.1. TCP sequence number checking . . . . . . . . . . . . . . . 7 4.1. TCP sequence number checking . . . . . . . . . . . . . . . 8
4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 8 4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 9
4.3. Filtering ICMP error messages based on the ICMP payload . 8 4.3. Filtering ICMP error messages based on the ICMP payload . 9
5. Blind connection-reset attack . . . . . . . . . . . . . . . . 8 5. Blind connection-reset attack . . . . . . . . . . . . . . . . 9
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Attack-specific counter-measures . . . . . . . . . . . . . 9 5.2. Attack-specific counter-measures . . . . . . . . . . . . . 11
5.2.1. Changing the reaction to hard errors . . . . . . . . . 9 5.2.1. Changing the reaction to hard errors . . . . . . . . . 11
5.2.2. Delaying the connection-reset . . . . . . . . . . . . 12 5.2.2. Delaying the connection-reset . . . . . . . . . . . . 13
6. Blind throughput-reduction attack . . . . . . . . . . . . . . 12 6. Blind throughput-reduction attack . . . . . . . . . . . . . . 13
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Attack-specific counter-measures . . . . . . . . . . . . . 12 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 14
7. Blind performance-degrading attack . . . . . . . . . . . . . . 13 7. Blind performance-degrading attack . . . . . . . . . . . . . . 14
7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Attack-specific counter-measures . . . . . . . . . . . . . 14 7.2. Attack-specific counter-measures . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. The counter-measure for the PMTUD attack in action . 20 Appendix A. The counter-measure for the PMTUD attack in action . 22
A.1. Normal operation for bulk transfers . . . . . . . . . . . 21 A.1. Normal operation for bulk transfers . . . . . . . . . . . 23
A.2. Operation during Path-MTU changes . . . . . . . . . . . . 22 A.2. Operation during Path-MTU changes . . . . . . . . . . . . 25
A.3. Idle connection being attacked . . . . . . . . . . . . . . 24 A.3. Idle connection being attacked . . . . . . . . . . . . . . 26
A.4. Active connection being attacked after discovery of A.4. Active connection being attacked after discovery of
the Path-MTU . . . . . . . . . . . . . . . . . . . . . . . 24 the Path-MTU . . . . . . . . . . . . . . . . . . . . . . . 27
A.5. TCP peer attacked when sending small packets just A.5. TCP peer attacked when sending small packets just
after the three-way handshake . . . . . . . . . . . . . . 25 after the three-way handshake . . . . . . . . . . . . . . 27
Appendix B. Pseudo-code for the counter-measure for the blind Appendix B. Pseudo-code for the counter-measure for the blind
performance-degrading attack . . . . . . . . . . . . 26 performance-degrading attack . . . . . . . . . . . . 28
Appendix C. Advice and guidance to vendors . . . . . . . . . . . 30 Appendix C. Additional considerations for the validation of
Appendix D. Changes from previous versions of the draft . . . . . 30 ICMP error messages . . . . . . . . . . . . . . . . . 32
D.1. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 30 Appendix D. Advice and guidance to vendors . . . . . . . . . . . 32
D.2. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 30 Appendix E. Changes from previous versions of the draft . . . . . 32
D.3. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 31 E.1. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 32
D.4. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 31 E.2. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 E.3. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 33 E.4. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 33
E.5. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 34
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 36
1. Introduction 1. Introduction
ICMP [1] is a fundamental part of the TCP/IP protocol suite, and is ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite,
used mainly for reporting network error conditions. However, the and is used mainly for reporting network error conditions. However,
current specifications do not recommend any kind of validation checks the current specifications do not recommend any kind of validation
on the received ICMP error messages, thus leaving the door open to a checks on the received ICMP error messages, thus leaving the door
variety of attacks that can be performed against TCP [2] by means of open to a variety of attacks that can be performed against TCP
ICMP, which include blind connection-reset, blind throughput- [RFC0793] by means of ICMP, which include blind connection-reset,
reduction, and blind performance-degrading attacks. All these blind throughput-reduction, and blind performance-degrading attacks.
attacks can be performed even being off-path, without the need to All of these attacks can be performed even being off-path, without
sniff the packets that correspond to the attacked TCP connection. the need to sniff the packets that correspond to the attacked TCP
connection.
While the security implications of ICMP have been known in the While the security implications of ICMP have been known in the
research community for a long time, there has never been an official research community for a long time, there has never been an official
proposal on how to deal with these attacks. Thus, only a few proposal on how to deal with these vulnerabiliies. Thus, only a few
implementations have implemented validation checks on the received implementations have implemented validation checks on the received
ICMP error messages to minimize the impact of these attacks. ICMP error messages to minimize the impact of these attacks.
Recently, a disclosure process has been carried out by the UK's Recently, a disclosure process has been carried out by the UK's
National Infrastructure Security Co-ordination Centre (NISCC), with National Infrastructure Security Co-ordination Centre (NISCC), with
the collaboration of other computer emergency response teams. A the collaboration of other computer emergency response teams. A
large number of implementations were found vulnerable to either all large number of implementations were found vulnerable to either all
or a subset of the attacks discussed in this document [12][13]. The or a subset of the attacks discussed in this document [NISCC][US-
affected systems ranged from TCP/IP implementations meant for desktop CERT]. The affected systems ranged from TCP/IP implementations meant
computers, to TCP/IP implementations meant for core Internet routers. for desktop computers, to TCP/IP implementations meant for core
Internet routers.
It is clear that implementations should be more cautious when
processing ICMP error messages, to eliminate or mitigate the use of
ICMP to perform attacks against TCP [I-D.iab-link-indications].
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 proposes several counter-measures variety of attacks against TCP, and proposes several counter-measures
that eliminate or minimize the impact of these attacks. that eliminate or minimize the impact of these attacks.
Section 2 provides background information on ICMP. Section 3 of this Section 2 provides background information on ICMP. Section 3
document discusses the constraints in the general counter-measures discusses the constraints in the general counter-measures that can be
that can be implemented against the attacks described in this implemented against the attacks described in this document.
document. Section 4 proposes several general validation checks and Section 4 proposes several general validation checks and counter-
counter-measures that can be implemented to mitigate any ICMP-based measures that can be implemented to mitigate any ICMP-based attack.
attack. Finally, Section 5, Section 6, and Section 7, discuss a Finally, Section 5, Section 6, and Section 7, discuss a variety of
variety of ICMP attacks that can be performed against TCP, and ICMP attacks that can be performed against TCP, and propose attack-
propose attack-specific counter-measures that eliminate or greatly specific counter-measures that eliminate or greatly mitigate their
mitigate their impact. impact.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Background 2. Background
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 [14]. 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 host, to raise awareness of the network problem taking the source host, to raise awareness of the network problem taking
place. In the same way, there are a number of scenarios in which an place. In the same way, there are a number of scenarios in which an
end-system may generate an ICMP error message if it finds a problem end-system may generate an ICMP error message if it finds a problem
while processing a datagram. The received ICMP errors are handled to while processing a datagram. The received ICMP errors are handled to
the corresponding transport-protocol instance, which will usually the corresponding transport-protocol instance, which will usually
perform a fault recovery function. perform a fault recovery function.
It is important to note that ICMP error messages are unreliable, and
may be discarded due to data corruption, network congestion and rate-
limiting. Thus, while they provide useful information, upper layer
protocols cannot depend on ICMP for correct operation.
2.1.1. ICMP for IP version 4 (ICMP) 2.1.1. ICMP for IP version 4 (ICMP)
[1] specifies the Internet Control Message Protocol (ICMP) to be used [RFC0792] specifies the Internet Control Message Protocol (ICMP) to
with the Internet Protocol version 4 (IPv4). It defines, among other be used with the Internet Protocol version 4 (IPv4). It defines,
things, a number of error messages that can be used by end-systems among other things, a number of error messages that can be used by
and intermediate systems to report network errors to the sending end-systems and intermediate systems to report network errors to the
host. The Host Requirements RFC [4] classifies ICMP error messages sending host. The Host Requirements RFC [RFC1122] classifies ICMP
into those that indicate "soft errors", and those that indicate "hard error messages into those that indicate "soft errors", and those that
errors", thus roughly defining the semantics of them. indicate "hard errors", thus roughly defining the semantics of them.
The ICMP specification [1] also defines the ICMP Source Quench The ICMP specification [RFC0792] also defines the ICMP Source Quench
message (type 4, code 0), which is meant to provide a mechanism for message (type 4, code 0), which is meant to provide a mechanism for
flow control and congestion control. flow control and congestion control.
[5] defines a mechanism called "Path MTU Discovery" (PMTUD), which [RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD),
makes use of ICMP error messages of type 3 (Destination Unreachable), which makes use of ICMP error messages of type 3 (Destination
code 4 (fragmentation needed and DF bit set) to allow hosts to Unreachable), code 4 (fragmentation needed and DF bit set) to allow
determine the MTU of an arbitrary internet path. hosts to determine the MTU of an arbitrary internet path.
Appendix D of [6] provides information about which ICMP error Appendix D of [RFC2401] provides information about which ICMP 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)
[7] specifies the Internet Control Message Protocol (ICMPv6) to be [RFC2463] specifies the Internet Control Message Protocol (ICMPv6) to
used with the Internet Protocol version 6 (IPv6) [8]. be used with the Internet Protocol version 6 (IPv6) [RFC2460].
ICMPv6 defines the "Packet Too Big" (type 2, code 0) error message, [RFC2463] defines the "Packet Too Big" (type 2, code 0) error
that is analogous to the ICMP "fragmentation needed and DF bit set" message, that is analogous to the ICMP "fragmentation needed and DF
(type 3, code 4) error message. [9] defines the Path MTU Discovery bit set" (type 3, code 4) error message. [RFC1981] defines the Path
mechanism for IP Version 6, that makes use of these messages to MTU Discovery mechanism for IP Version 6, that makes use of these
determined the MTU of an arbitrary internet path. messages to determine the MTU of an arbitrary internet path.
Appendix D of [6] provides information about which ICMPv6 error Appendix D of [RFC2401] 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 [4] states that a TCP MUST act on an ICMP The Host Requirements RFC [RFC1122] states that a TCP MUST act on an
error message passed up from the IP layer, directing it to the ICMP error message passed up from the IP layer, directing it to the
connection that elicited the error. connection that elicited 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
host, part of the original packet that elicited the message is host, part of the original packet that elicited 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 host can use that information to match the ICMP error to receiving host can use that information to match the ICMP error to
the transport protocol instance that elicited it. the transport protocol instance that elicited it.
Neither the Host Requirements RFC [4] nor the original TCP Neither the Host Requirements RFC [RFC1122] nor the original TCP
specification [2] recommend any validation checks on the received specification [RFC0793] recommend any validation checks on the
ICMP messages. Thus, as long as the ICMP payload contains the received ICMP messages. Thus, as long as the ICMP payload contains
information that identifies an existing communication instance, it the information that identifies an existing communication instance,
will be processed by the corresponding transport-protocol instance, it will be processed by the corresponding transport-protocol
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 forged ICMP Therefore, in the case of TCP, an attacker could send a forged ICMP
message to the attacked host, and, as long as he is able to guess the message to the attacked host, and, as long as he is able to guess the
four-tuple that identifies the communication instance to be attacked, four-tuple that identifies the communication instance to be attacked,
he will be able to use ICMP to perform a variety of attacks. he will be able to use ICMP to perform a variety of attacks.
As discussed in [15], there are a number of scenarios in which an As discussed in [Watson], there are a number of scenarios in which an
attacker may be able to know or guess the four-tuple that identifies attacker may be able to know or guess the four-tuple that identifies
a TCP connection. If we assume the attacker knows the two systems a TCP connection. If we assume the attacker knows the two systems
involved in the TCP connection to be attacked, both the client-side involved in the TCP connection to be attacked, both the client-side
and the server-side IP addresses will be known. Furthermore, as most and the server-side IP addresses will be known. Furthermore, as most
Internet services use the so-called "well-known" ports, only the Internet services use the so-called "well-known" ports, only the
client port number would need to be guessed. This means that an client port number would need to be guessed. This means that an
attacker would need to send, in principle, at most 65536 packets to attacker would need to send, in principle, at most 65536 packets to
perform any of the attacks described in this document. However, most perform any of the attacks described in this document. However, most
systems choose the port numbers they use for outgoing connections systems choose the port numbers they use for outgoing connections
from a subset of the whole port number space. Thus, in practice, from a subset of the whole port number space. Thus, in practice,
fewer packets are needed to perform any of the attacks discussed in fewer packets are needed to perform any of the attacks discussed in
this document. this document.
It is clear that security checks should be performed on the received It is clear that TCP should be more cautious when processing received
ICMP error messages, to mitigate or eliminate the impact of the ICMP error messages, in order to mitigate or eliminate the impact of
attacks described in this document. the attacks described in this document [I-D.iab-link-indications].
3. Constraints in the possible solutions 3. Constraints in the possible solutions
For ICMPv4, [1] states that the internet header plus the first 64
bits of the packet that elicited the ICMP message are to be included For ICMPv4, [RFC0792] states that the internet header plus the first
in the payload of the ICMP error message. Thus, it is assumed that 64 bits of the packet that elicited the ICMP message are to be
all data needed to identify a transport protocol instance and process included in the payload of the ICMP error message. Thus, it is
the ICMP error message is contained in the first 64 bits of the assumed that all data needed to identify a transport protocol
transport protocol header. [4] states that "the Internet header and instance and process the ICMP error message is contained in the first
at least the first 8 data octets of the datagram that triggered the 64 bits of the transport protocol header. [RFC1122] states that "the
error" are to be included in the payload of ICMP error messages, and Internet header and at least the first 8 data octets of the datagram
that "more than 8 octets MAY be sent", thus allowing implementations that triggered the error" are to be included in the payload of ICMP
to include more data from the original packet than those required by error messages, and that "more than 8 octets MAY be sent", thus
the original ICMP specification. The Requirements for IP Version 4 allowing implementations to include more data from the original
Routers RFC [10] states that ICMP error messages "SHOULD contain as packet than those required by the original ICMP specification. The
much of the original datagram as possible without the length of the Requirements for IP Version 4 Routers RFC [RFC1812] states that ICMP
ICMP datagram exceeding 576 bytes". error messages "SHOULD contain as much of the original datagram as
possible without the length of the ICMP datagram exceeding 576
bytes".
Thus, for ICMP messages generated by hosts, we can only expect to get Thus, for ICMP messages generated by hosts, we can only expect to get
the entire IP header of the original packet, plus the first 64 bits the entire IP header of the original packet, plus the first 64 bits
of its payload. For TCP, this means that the only fields that will of its payload. For TCP, this means that the only fields that will
be included in the ICMP payload are: the source port number, the be included in the ICMP payload are: the source port number, the
destination port number, and the 32-bit TCP sequence number. This destination port number, and the 32-bit TCP sequence number. This
clearly imposes a constraint on the possible validation checks that clearly imposes a constraint on the possible validation checks that
can be performed, as there is not much information avalable on which can be performed, as there is not much information avalable on which
to perform them. 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 [16], this mechanism could by means of the TCP MD5 signature option [RFC2385], this mechanism
not be used as a counter-measure against ICMP-based attacks, because, could not be used as a counter-measure against ICMP-based attacks,
as ICMP messages include only a piece of the TCP segment that because, as ICMP messages include only a piece of the TCP segment
elicited the error, the MD5 [17] signature could not be recalculated. that elicited the error, the MD5 [RFC1321] signature could not be
In the same way, even if the attacked peer were authenticating its recalculated. In the same way, even if the attacked peer were
packets at the IP layer [6], because only a part of the original IP authenticating its packets at the IP layer [RFC2401], because only a
packet would be available, the signature used for authentication part of the original IP packet would be available, the signature used
could not be recalculated, and thus this mechanism could not be used for authentication could not be recalculated, and thus this mechanism
as a counter-measure aganist ICMP-based attacks against TCP. could not be used as a counter-measure aganist ICMP-based attacks
against TCP.
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 elicited the ICMPv6 error message as octets from the IPv6 packet that elicited the ICMPv6 error message as
will fit without making the resulting ICMPv6 packet exceed the will fit without making the resulting ICMPv6 packet exceed the
minimum IPv6 MTU (1280 octets) [7]. Thus, more information is minimum IPv6 MTU (1280 octets) [RFC2463]. Thus, more information is
available than in the IPv4 case. available than in the IPv4 case.
Hosts could require ICMP error messages to be authenticated [6], in Hosts could require ICMP error messages to be authenticated
order to act upon them. However, while this requirement could make [RFC2401], in order to act upon them. However, while this
sense for those ICMP error messages sent by hosts, it would not be requirement could make sense for those ICMP error messages sent by
feasible for those ICMP error messages generated by routers, as this hosts, it would not be feasible for those ICMP error messages
would imply either that the attacked host should have a security generated by routers, as this would imply either that the attacked
asociation [6] with every existing intermediate system, or that it host should have a security asociation [RFC2401] with every existing
should be able to establish one dynamically. Current levels of intermediate system, or that it should be able to establish one
deployment of protocols for dynamic establishment of security dynamically. Current levels of deployment of protocols for dynamic
associations makes this unfeasible. Also, there may be some cases, establishment of security associations makes this unfeasible. Also,
such as embedded devices, in which the processing power requirements there may be some cases, such as embedded devices, in which the
of authentication could not allow IPSec authentication to be processing power requirements of authentication could not allow IPSec
implemented effectively. authentication to be implemented effectively.
Additional considerations for the validation of ICMP error messages
can be found in Appendix C
4. General counter-measures against ICMP attacks 4. General counter-measures against ICMP attacks
There are a number of counter-measures that can be implemented to There are a number of counter-measures that can be implemented to
eliminate or mitigate the impact of the attacks discussed in this eliminate or mitigate the impact of the attacks discussed in this
document. Rather than being alternative counter-measures, they can document. Rather than being alternative counter-measures, they can
be implemented together to increase the protection against these be implemented together to increase the protection against these
attacks. In particular, all TCP implementations SHOULD perform the attacks. In particular, all TCP implementations SHOULD perform the
TCP sequence number checking described in Section 4.1. TCP sequence number checking described in Section 4.1.
skipping to change at page 7, line 32 skipping to change at page 8, line 49
payload of the ICMP error message is within the range SND.UNA =< payload of the ICMP error message is within the range SND.UNA =<
SEG.SEQ < SND.NXT. This means that the sequence number should be SEG.SEQ < SND.NXT. This means that the sequence number should be
within the range of the data already sent but not yet acknowledged. within the range of the data already sent but not yet acknowledged.
If an ICMP error message does not pass this check, it SHOULD be If an ICMP error message does not pass this check, it SHOULD be
discarded. 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 [18]). For already sent to the remote peer, but not yet acknowledged [RFC2581]).
connections in the SYN-SENT or SYN-RECEIVED states, this would reduce For connections in the SYN-SENT or SYN-RECEIVED states, this would
the possibility of considering a spoofed ICMP packet as valid to reduce the possibility of considering a spoofed ICMP packet as valid
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 counter-measure has been implemented in Linux [19] for many This validation check has been implemented in Linux [Linux] for many
years, in OpenBSD [20] since 2004, and in FreeBSD [21] and NetBSD years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and
[22] 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 [23] are bandwidth is easily available, and/or large TCP windows [RFC1323] are
used. Therefore, implementation of the attack-specific counter- in use. Therefore, implementation of the attack-specific counter-
measures discussed in this document is strongly RECOMMENDED. measures discussed in this document is strongly RECOMMENDED.
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 conenctions would make it harder for an attacker to perform any TCP conenctions would make it harder for an attacker to perform any
of the attacks discussed in this document. of the attacks discussed in this document.
[24] discusses a number of algorithms to randomize the ephemeral [I-D.larsen-tsvwg-port-randomisation] discusses a number of
ports used by clients. algorithms to randomize the ephemeral ports used by clients.
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. Therefore, simple to perform the attacks described in this document. Therefore, simple
filtering based on the source address of ICMP error messages does not filtering based on the source address of ICMP error messages does not
serve as a counter-measure against these attacks. However, a more serve as a counter-measure against these attacks. However, a more
advanced packet filtering could be implemented in firewalls as a advanced packet filtering could be implemented in firewalls as a
counter-measure. Firewalls implementing such advanced filtering counter-measure. Firewalls implementing such advanced filtering
would look at the payload of the ICMP error messages, and would would look at the payload of the ICMP error messages, and would
skipping to change at page 8, line 48 skipping to change at page 10, line 16
When TCP is handled an ICMP error message, it will perform its fault When TCP is handled 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 [4] states that a host SHOULD abort the The Host Requirements RFC [RFC1122] states that a host SHOULD abort
corresponding connection when receiving an ICMP error message that the corresponding connection when receiving an ICMP error message
indicates a "hard error", and states that ICMP error messages of type that indicates a "hard error", and states that ICMP error messages of
3 (Destination Unreachable) codes 2 (protocol unreachable), 3 (port type 3 (Destination Unreachable) codes 2 (protocol unreachable), 3
unreachable), and 4 (fragmentation needed and DF bit set) should be (port unreachable), and 4 (fragmentation needed and DF bit set)
considered to indicate hard errors. While [7] did not exist when [4] should be considered to indicate hard errors. While [RFC2463] did
was published, one could extrapolate the concept of "hard errors" to not exist when [RFC1122] was published, one could extrapolate the
ICMPv6 error messages of type 1 (Destination unreachable) codes 1 concept of "hard errors" to ICMPv6 error messages of type 1
(communication with destination administratively prohibited), and 4 (Destination unreachable) codes 1 (communication with destination
(port unreachable). 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. That is, even being off-path, an attacker could reset any attack. That is, even being off-path, an attacker could reset any
TCP connection taking place. In order to perform such an attack, an TCP connection taking place. In order to perform such an attack, an
attacker would send any ICMP error message that indicates a "hard attacker would send 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 of TCP's fault recovery policy, the connection would be Because of TCP's fault recovery policy, the connection would be
immediately aborted. immediately aborted.
As discussed in Section 2.2, all an attacker needs to know to perform As discussed in Section 2.2, all an attacker needs to know to perform
such an attack is the socket pair that identifies the TCP connection such an attack is the socket pair that identifies the TCP connection
to be attacked. In some scenarios, the IP addresses and port numbers to be attacked. In some scenarios, the IP addresses and port numbers
in use may be easily guessed or known to the attacker [15]. in use may be easily guessed or known to the attacker [Watson].
Some stacks are known to extrapolate ICMP errors across TCP Some stacks are known to extrapolate ICMP 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 [15] and [25], against the blind connection-reset attack described in [Watson] and
by means authentication at the network layer [6], by means of the TCP [I-D.ietf-tcpm-tcpsecure], by means authentication at the network
MD5 signature option [16], or by means of the mechanism proposed in layer [RFC2401], by means of the TCP MD5 signature option [RFC2385],
[25], the blind connection-reset attack described in this document or by means of the mechanism proposed in [I-D.ietf-tcpm-tcpsecure],
would still succeed. the blind connection-reset attack described in this document would
still succeed.
5.2. Attack-specific counter-measures 5.2. Attack-specific counter-measures
5.2.1. Changing the reaction to hard errors 5.2.1. Changing the reaction to hard errors
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 eliminate the hard errors may be received can shed some light to eliminate the
impact of ICMP-based blind connection-reset attacks. impact of ICMP-based blind connection-reset attacks.
ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable) ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable)
skipping to change at page 10, line 22 skipping to change at page 11, line 39
ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK
or TIME-WAIT states. or TIME-WAIT states.
ICMP type 3 (Destination Unreachable), code 3 (port unreachable) ICMP type 3 (Destination Unreachable), code 3 (port unreachable)
This error message indicates that the host sending the ICMP error This error message indicates that the host sending the ICMP error
message received a packet meant for a socket (IP address, port message received a packet meant for a socket (IP address, port
number) on which there is no process listening. Those transport number) on which there is no process listening. Those transport
protocols which have their own mechanisms for notifying this protocols which have their own mechanisms for notifying this
condition should not be receiving these error messages. However, condition should not be receiving these error messages. However,
the Host Requirements RFC [4] states that even those transport the Host Requirements RFC [RFC1122] states that even those
protocols that have their own mechanism for notifying the sender transport protocols that have their own mechanism for notifying
that a port is unreachable MUST nevertheless accept an ICMP Port the sender that a port is unreachable MUST nevertheless accept an
Unreachable for the same purpose. For security reasons, it would ICMP Port Unreachable for the same purpose. For security reasons,
be fair to treat ICMP port unreachable messages as soft errors (or it would be fair to treat ICMP port unreachable messages as soft
completely ignore them) when they are meant for protocols that errors (or completely ignore them) when they are meant for
have their own mechanism for reporting this error condition. protocols that have their own mechanism for reporting this error
condition.
ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed ICMP 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. Those systems that do not implement the PMTUD header was set. Those systems that do not implement the PMTUD
mechanism should not be sending their IP packets with the DF bit mechanism should not be sending their IP packets with the DF bit
set, and thus should not be receiving these ICMP error messages. set, and thus should not be receiving these ICMP error messages.
Thus, it would be fair for them to treat this ICMP error message Thus, it would be fair for them to treat this ICMP error message
as indicating a soft error, therefore not aborting the as indicating a soft error, therefore not aborting the
corresponding connection when such an error message is received. corresponding connection when such an error message is received.
On the other hand, and for obvious reasons, those systems On the other hand, and for obvious reasons, those systems
implementing the Path-MTU Discovery (PMTUD) mechanism [5] should implementing the Path-MTU Discovery (PMTUD) mechanism [RFC1191]
not abort the corresponding connection when such an ICMP error should not abort the corresponding connection when such an ICMP
message is received. error message is received.
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
skipping to change at page 11, line 32 skipping to change at page 12, line 49
based on the premise that TCP should be as robust as possible. Also, based on the premise that TCP should be as robust as possible. Also,
as discussed in Section 5.1, hosts SHOULD NOT extrapolate ICMP errors as discussed in Section 5.1, hosts SHOULD NOT extrapolate ICMP errors
across TCP connections. across TCP connections.
In case the received message were legitimate, it would mean that the In case the received message were legitimate, it would mean that the
"hard error" condition appeared during the life of the connection. "hard error" condition appeared during the life of the connection.
However, there is no reason to think that in the same way this error However, there is no reason to think that in the same way this error
condition appeared, it won't get solved in the near term. Therefore, condition appeared, it won't get solved in the near term. Therefore,
treating the received ICMP error messages as "soft errors" would make treating the received ICMP error messages as "soft errors" would make
TCP more robust, and could avoid TCP from aborting a TCP connection TCP more robust, and could avoid TCP from aborting a TCP connection
unnecesarily. unnecesarily. Aborting the connection would be to ignore the
valuable feature of the Internet that for many internal failures it
reconstructs its function without any disruption of the end points
[RFC0816].
Also, it is important to note that the current specifications allow
this recommended counter-measure.
One scenario in which a host would benefit from treating the so- One scenario in which a host would benefit from treating the so-
called ICMP "hard errors" as "soft errors" would be that in which the called ICMP "hard errors" as "soft errors" would be that in which the
packets that correspond to a given TCP connection are routed along packets that correspond to a given TCP connection are routed along
multiple different paths. Some (but not all) of these paths may be multiple different paths. Some (but not all) of these paths may be
experiencing an error condition, and therefore generating the so- experiencing an error condition, and therefore generating the so-
called ICMP hard errors. However, communication should survive if called ICMP hard errors. However, communication should survive if
there is still a working path to the destination host [26]. Thus, there is still a working path to the destination host [DClark].
treating the so-called "hard errors" as "soft errors" when a Thus, treating the so-called "hard errors" as "soft errors" when a
connection is in any of the synchronized states would make TCP connection is in any of the synchronized states would make TCP
achieve this goal. achieve this goal.
It is interesting to note that, as ICMP error messages are It is interesting to note that, as ICMP error messages are
unreliable, transport protocols should not depend on them for correct unreliable, transport protocols should not depend on them for correct
functioning. In the event one of these messages were legitimate, the functioning. In the event one of these messages were legitimate, the
corresponding connection should eventually time out. corresponding connection would eventually time out. Also,
applications may still be notified asynchronously about the received
error messages, and thus may still abort 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., [21], [22], and [20]) for more than ten years implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more
than ten years [TCPv2][McKusick]. The Linux kernel has implemented
[27][28]. The Linux kernel has implemented this policy for more than this policy for more than ten years, too [Linux].
ten years, too [19].
5.2.2. Delaying the connection-reset 5.2.2. Delaying the connection-reset
An alternative counter-measure could be to delay the connection An alternative counter-measure could be to delay the connection
reset. Rather than immediately aborting a connection, a TCP would reset. Rather than immediately aborting a connection, a TCP would
abort a connection only after an ICMP error message indicating a hard abort a connection only after an ICMP error message indicating a hard
error has been received, and the corresponding data have already been error has been received, and the corresponding data have already been
retransmitted more than some specified number of times. retransmitted more than some specified number of times.
The rationale behind this proposed fix is that if a host can make The rationale behind this proposed fix is that if a host can make
skipping to change at page 12, line 25 skipping to change at page 14, line 4
The rationale behind this proposed fix is that if a host can make The rationale behind this proposed fix is that if a host can make
forward progress on a connection, it can completely disregard the forward progress on a connection, it can completely disregard the
"hard errors" being indicated by the received ICMP error messages. "hard errors" being indicated by the received ICMP error messages.
While this counter-measure could be useful, we think that the While this counter-measure could be useful, we think that the
counter-measure discussed in Section 5.2.1 is easier to implement, counter-measure discussed in Section 5.2.1 is easier to implement,
and provides increased protection against this type of attack. and provides increased protection against this type of attack.
6. Blind throughput-reduction attack 6. Blind throughput-reduction attack
6.1. Description 6.1. Description
The Host requirements RFC [4] states that hosts MUST react to ICMP The Host requirements RFC [RFC1122] states that hosts MUST react to
Source Quench messages by slowing transmission on the connection. ICMP Source Quench messages by slowing transmission on the
Thus, an attacker could send ICMP Source Quench (type 4, code 0) connection. Thus, an attacker could send ICMP Source Quench (type 4,
messages to a TCP endpoint to make it reduce the rate at which it code 0) messages to a TCP endpoint to make it reduce the rate at
sends data to the other end-point of the connection. [4] further adds which it sends data to the other end-point of the connection.
that the RECOMMENDED procedure is to put the corresponding connection [RFC1122] further adds that the RECOMMENDED procedure is to put the
in the slow-start phase of TCP's congestion control algorithm [18]. corresponding connection in the slow-start phase of TCP's congestion
In the case of those implementations that use an initial congestion control algorithm [RFC2581]. In the case of those implementations
window of one segment, a sustained attack would reduce the throughput that use an initial congestion window of one segment, a sustained
of the attacked connection to about SMSS (Sender Maximum Segment attack would reduce the throughput of the attacked connection to
Size) [18] bytes per RTT (round-trip time). The throughput achieved about SMSS (Sender Maximum Segment Size) [RFC2581] bytes per RTT
during attack might be a little higher if a larger initial congestion (round-trip time). The throughput achieved during attack might be a
window is in use [29]. little higher if a larger initial congestion window is in use
[RFC3390].
6.2. Attack-specific counter-measures 6.2. Attack-specific counter-measures
The Host Requirements RFC [4] states that hosts MUST react to ICMP The Host Requirements RFC [RFC1122] states that hosts MUST react to
Source Quench messages by slowing transmission on the connection. ICMP Source Quench messages by slowing transmission on the
However, as discussed in the Requirements for IP Version 4 Routers connection. However, as discussed in the Requirements for IP Version
RFC [10], research seems to suggest ICMP Source Quench is an 4 Routers RFC [RFC1812], research seems to suggest ICMP Source Quench
ineffective (and unfair) antidote for congestion. [10] further states is an ineffective (and unfair) antidote for congestion. [RFC1812]
that routers SHOULD NOT send ICMP Source Quench messages in response further states that routers SHOULD NOT send ICMP Source Quench
to congestion. On the other hand, TCP implements its own congestion messages in response to congestion. On the other hand, TCP
control mechanisms [18] [30]. Thus, hosts SHOULD completely ignore implements its own congestion control mechanisms [RFC2581] [RFC3168],
ICMP Source Quench messages meant for TCP connections. that do not depend on ICMP Source Quench messages. Thus, hosts
SHOULD completely ignore ICMP Source Quench messages meant for TCP
connections.
This behavior has been implemented in Linux [19] since 2004, and in This behavior has been implemented in Linux [Linux] since 2004, and
FreeBSD [21], NetBSD [22], and OpenBSD [20] since 2005. in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] since
2005.
7. Blind performance-degrading attack 7. Blind performance-degrading attack
7.1. Description 7.1. Description
When one IP host has a large amount of data to send to another host, When one IP host has a large amount of data to send to another host,
the data will be transmitted as a series of IP datagrams. It is the data will be transmitted as a series of IP datagrams. It is
usually preferable that these datagrams be of the largest size that usually preferable that these datagrams be of the largest size that
does not require fragmentation anywhere along the path from the 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 [5]. in the path [RFC1191].
A technique called "Path MTU Discovery" (PMTUD) mechanism lets IP A technique called "Path MTU Discovery" (PMTUD) mechanism lets IP
hosts determine the Path MTU of an arbitrary internet path. [5] and hosts determine the Path MTU of an arbitrary internet path.
[9] specify the PMTUD mechanism for IPv4 and IPv6, respectively. [RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and
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 host assumes that the MTU behind the PMTUD mechanism is that a source host assumes that the MTU
of the path is that of the first hop, and sends all its datagrams 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 neeed and DF ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF
set" (code 4) error message to sending host. This message will set" (code 4) error message to sending host. This message will
report the MTU of the constricting hop, so that the sending host report the MTU of the constricting hop, so that the sending host can
reduces the assumed Path-MTU accordingly. 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 host. This message Big" (type 2, code 0) error message to sending host. This message
will report the MTU of the constricting hop, so that the sending host will report the MTU of the constricting hop, so that the sending host
can reduce the assumed Path-MTU accordingly. can reduce the assumed Path-MTU accordingly.
As discussed in both [5] and [9], the Path-MTU Discovery mechanism As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery
can be used to attack TCP. An attacker could send a forged ICMP mechanism can be used to attack TCP. An attacker could send a forged
"Destination Unreachable, fragmentation needed and DF set" packet (or ICMP "Destination Unreachable, fragmentation needed and DF set"
their IPv6 counterpart) to the sending host, making it advertise a packet (or their ICMPv6 counterpart) to the sending host, advertising
low Next-Hop MTU. As a result, the attacked system would reduce the a small Next-Hop MTU. As a result, the attacked system would reduce
size of the packets it sends for the corresponding connection the size of the packets it sends for the corresponding connection
accordingly. 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 end-point. 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 increase in the IRQ virtually all systems this will lead to an increase in the IRQ
(Interrrupt ReQuest) rate, thus increasing processor utilization, and (Interrrupt ReQuest) rate, thus increasing processor utilization, and
degrading the overall system performance. degrading the overall system performance.
A particular scenario that may take place is that in which an
attacker reports a Next-Hop MTU smaller than or equal to the amount
of bytes needed for headers (IP header, plus TCP header). For
example, if the attacker reports a Next-Hop MTU of 68 bytes, and the
amount of bytes used for headers (IP header, plus TCP header) is
larger than 68 bytes, the assumed Path-MTU will not even allow the
attacked host to send a single byte of application data without
fragmentation. This particular scenario might lead to unpredictable
results. Another posible scenario is that in which a TCP connection
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
(IP and IPSec, in this case), the assumed Path-MTU will not even
allow the attacked host to send a single byte of the TCP header
without fragmentation. This is another scenario that may lead to
unpredictable results.
For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as
[11] requires every internet module to be able to forward a datagram [RFC0791] requires every internet module to be able to forward a
of 68 octets without further fragmentation. For IPv6, the reported datagram of 68 octets without further fragmentation. For IPv6, the
Next-Hop MTU could be as low as 1280 octets (the minimum IPv6 MTU) reported Next-Hop MTU could be as low as 1280 octets (the minimum
[8]. IPv6 MTU) [RFC2460].
7.2. Attack-specific counter-measures 7.2. Attack-specific counter-measures
Henceforth, we will refer to both ICMP "fragmentation needed and DF Henceforth, we will refer to both ICMP "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,
a counter-measure similar to that described in Section 5.2.2 could be a counter-measure similar to that described in Section 5.2.2 could be
implemented to greatly minimize the impact of this attack. implemented to greatly minimize the impact of this attack.
skipping to change at page 16, line 43 skipping to change at page 18, line 43
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 should be cleared. "pending error" condition should be 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.
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 [5] and [9]. A MAXSEGRTO of 1 traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A
should provide enough protection for most cases. In any case, MAXSEGRTO of 1 should provide enough protection for most cases. In
implementations are free to choose higher values for this constant. any case, implementations are free to choose higher values for this
MAXSEGRTO could be a function of the Next-Hop MTU claimed in the constant. MAXSEGRTO could be a function of the Next-Hop MTU claimed
received ICMP "Packet Too Big" message. That is, higher values for in the received ICMP "Packet Too Big" message. That is, higher
MAXSEGRTO could be imposed when the received ICMP "Packet Too Big" values for MAXSEGRTO could be imposed when the received ICMP "Packet
message claims a Next-Hop MTU that is smaller than some specified Too Big" message claims a Next-Hop MTU that is smaller than some
value. specified value.
In the event a higher level of protection is desired at the expense In the event a higher level of protection is desired at the expense
of a higher delay in the discovery of the Path-MTU, an implementation of a higher delay in the discovery of the Path-MTU, an implementation
could consider TCP to always be in the Path-MTU Update stage, thus could consider TCP to always be in the Path-MTU Update stage, thus
always delaying the update of the assumed Path-MTU. always delaying the update of the assumed Path-MTU.
Appendix B shows the proposed counter-measure in pseudo-code. Appendix A shows the proposed counter-measure in action. Appendix B
Appendix A shows the proposed counter-measure in action. shows the proposed counter-measure in pseudo-code.
This behavior has been implemented in NetBSD [22] and OpenBSD [20] This behavior has been implemented in NetBSD [NetBSD] and OpenBSD
since 2005. [OpenBSD] since 2005.
It is important to note that the mechanism proposed in this section It is important to note that the mechanism proposed 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 [5] and [9], still suffers from some functionality specified by [RFC1191] and [RFC1981], still suffers from some
problems [31] that this document does not aim to address. Thus, it functionality problems [RFC2923] that this document does not aim to
does not aleviate the need for other improvements to the current address. Thus, it does not aleviate the need for other improvements
PMTUD mechanism or the introduction of an alternative PMTUD that to the current PMTUD mechanism or the introduction of an alternative
replaces the current one, to solve the remaining issues. PMTUD that replaces the current one, to solve the remaining issues.
A mechanism that aims to address those remaining issues is described A mechanism that aims to address those remaining issues is described
in [32]. in [I-D.ietf-pmtud-method].
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 proposes a number of number of attacks against the TCP protocol, and proposes a number of
counter-measures that either eliminate or reduce the impact of these counter-measures that either eliminate or reduce the impact of these
attacks. attacks.
9. 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 [33] by private e-mail. The author would like to issues related to [I-D.gont-tcpm-tcp-soft-errors] by private e-mail.
thank James Carlson, Alan Cox, Theo de Raadt, Ted Faber, Juan The author would like to thank Ran Atkinson, James Carlson, Alan Cox,
Fraschini, Markus Friedl, Guillermo Gont, Vivek Kakkar, Michael Theo de Raadt, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo
Kerrisk, Mika Liljeberg, David Miller, Miles Nordin, Eloy Paris, Gont, John Heffner, Vivek Kakkar, Michael Kerrisk, Mika Liljeberg,
Kacheong Poon, Andrew Powell, Pekka Savola, and Joe Touch, for David Miller, Miles Nordin, Eloy Paris, Kacheong Poon, Andrew Powell,
contributing many valuable comments. Pekka Savola, Joe Touch, and Andres Trapanotto, for contributing many
valuable comments.
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 [20] the first implementation of the counter- and tested in OpenBSD [OpenBSD] the first implementation of the
measure described in Section 7.2. This first implementation helped counter-measure described in Section 7.2. This first implementation
to test the effectiveness of the ideas introduced in this document, helped to test the effectiveness of the ideas introduced in this
and has served as a reference implementation for other operating document, and has served as a reference implementation for other
systems. operating systems.
The author would like to thank the UK's National Infrastructure The author would like to thank the UK's National Infrastructure
Security Co-ordination Centre (NISCC) for coordinating the disclosure Security Co-ordination Centre (NISCC) for coordinating the disclosure
of these issues with a large number of vendors and CSIRTs (Computer of these issues with a large number of vendors and CSIRTs (Computer
Security Incident Response Teams). 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.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
RFC 792, September 1981. September 1981.
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
September 1981. RFC 792, September 1981.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
Levels", BCP 14, RFC 2119, March 1997. RFC 793, September 1981.
[4] Braden, R., "Requirements for Internet Hosts - Communication [RFC1122] Braden, R., "Requirements for Internet Hosts -
Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[5] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[6] Kent, S. and R. Atkinson, "Security Architecture for the [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
Internet Protocol", RFC 2401, November 1998. RFC 1812, June 1995.
[7] Conta, A. and S. Deering, "Internet Control Message Protocol [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
(ICMPv6) for the Internet Protocol Version 6 (IPv6) for IP version 6", RFC 1981, August 1996.
Specification", RFC 2463, December 1998.
[8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Specification", RFC 2460, December 1998. Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
IP version 6", RFC 1981, August 1996. Internet Protocol", RFC 2401, November 1998.
[10] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
June 1995. (IPv6) Specification", RFC 2460, December 1998.
[11] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC2463] Conta, A. and S. Deering, "Internet Control Message
September 1981. Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
10.2. Informative References 10.2. Informative References
[12] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: [DClark] Clark, D., "The Design Philosophy of the DARPA Internet
Vulnerability Issues in ICMP packets with TCP payloads", http: Protocols", Computer Communication Review Vol. 18, No. 4,
//www.niscc.gov.uk/niscc/docs/al-20050412-00308.html?lang=en, 1988.
2005.
[13] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP [FreeBSD] The FreeBSD Project, "http://www.freebsd.org".
Implementations do not adequately validate ICMP error
messages", http://www.kb.cert.org/vuls/id/222750, 2005.
[14] Clark, D., "Fault isolation and recovery", RFC 816, July 1982. [I-D.gont-tcpm-tcp-soft-errors]
Gont, F., "TCP's Reaction to Soft Errors",
draft-gont-tcpm-tcp-soft-errors-02 (work in progress),
September 2005.
[15] Watson, P., "Slipping in the Window: TCP Reset Attacks", 2004 [I-D.iab-link-indications]
CanSecWest Conference , 2004. Aboba, B., "Architectural Implications of Link
Indications", draft-iab-link-indications-03 (work in
progress), August 2005.
[16] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [I-D.ietf-pmtud-method]
Signature Option", RFC 2385, August 1998. Mathis, M., "Path MTU Discovery",
draft-ietf-pmtud-method-04 (work in progress),
February 2005.
[17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [I-D.ietf-tcpm-tcpsecure]
April 1992. Dalal, M., "Improving TCP's Robustness to Blind In-Window
Attacks", draft-ietf-tcpm-tcpsecure-03 (work in progress),
May 2005.
[18] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion [I-D.larsen-tsvwg-port-randomisation]
Control", RFC 2581, April 1999. Larsen, M., "Port Randomisation",
draft-larsen-tsvwg-port-randomisation-00 (work in
progress), October 2004.
[19] The Linux Project, "http://www.kernel.org". [Linux] The Linux Project, "http://www.kernel.org".
[20] The OpenBSD Project, "http://www.openbsd.org". [McKusick]
McKusick, M., Bostic, K., Karels, M., and J. Quarterman,
"The Design and Implementation of the 4.4BSD Operating
System", Addison-Wesley , 1996.
[21] The FreeBSD Project, "http://www.freebsd.org". [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.
[22] The NetBSD Project, "http://www.netbsd.org". [NetBSD] The NetBSD Project, "http://www.netbsd.org".
[23] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for [OpenBSD] The OpenBSD Project, "http://www.openbsd.org".
High Performance", RFC 1323, May 1992.
[24] Larsen, M., "Port Randomisation", [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816,
draft-larsen-tsvwg-port-randomisation-00 (work in progress), July 1982.
October 2004.
[25] Dalal, M., "Improving TCP's Robustness to Blind In-Window [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
Attacks", draft-ietf-tcpm-tcpsecure-03 (work in progress), April 1992.
May 2005.
[26] Clark, D., "The Design Philosophy of the DARPA Internet [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
Protocols", Computer Communication Review Vol. 18, No. 4, 1988. for High Performance", RFC 1323, May 1992.
[27] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Implementation", Addison-Wesley , 1994. Signature Option", RFC 2385, August 1998.
[28] McKusick, M., Bostic, K., Karels, M., and J. Quarterman, "The [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Design and Implementation of the 4.4BSD Operating System", Control", RFC 2581, April 1999.
Addison-Wesley , 1996.
[29] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Initial Window", RFC 3390, October 2002. Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[30] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
Explicit Congestion Notification (ECN) to IP", RFC 3168, April 2001.
September 2001.
[31] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
September 2000. RFC 2923, September 2000.
[32] Mathis, M., "Path MTU Discovery", draft-ietf-pmtud-method-04 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
(work in progress), February 2005. of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[33] Gont, F., "TCP's Reaction to Soft Errors", [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
draft-gont-tcpm-tcp-soft-errors-01 (work in progress), Initial Window", RFC 3390, October 2002.
October 2004.
[34] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [TCPv2] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
April 2001. The Implementation", Addison-Wesley , 1994.
[35] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Implementations do not adequately validate ICMP error
HTTP/1.1", RFC 2616, June 1999. messages", http://www.kb.cert.org/vuls/id/222750, 2005.
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks",
2004 CanSecWest Conference , 2004.
Appendix A. The counter-measure for the PMTUD attack in action Appendix A. The counter-measure for the PMTUD attack in action
This appendix shows the proposed counter-measure for the ICMP attack This appendix shows the proposed counter-measure for the ICMP attack
against the PMTUD mechanism in action. It shows both how the fix against the PMTUD mechanism in action. It shows both how the fix
protects TCP from being attacked and how the counter-measure works in protects TCP from being attacked and how the counter-measure works in
normal scenarios. As discussed in Section 7.2, this Appendix assumes normal scenarios. As discussed in Section 7.2, this Appendix assumes
the PMTUD-specific counter-measure is implemented in addition to the the PMTUD-specific counter-measure is implemented in addition to the
TCP sequence number checking described in Section 4.1. TCP sequence number checking described in Section 4.1.
skipping to change at page 21, line 46 skipping to change at page 24, line 25
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 nsegrto is initialized to zero. Both maxsizeacked and maxsizesent
are initialized to the minimum MTU for the internet protocol being are initialized to the minimum MTU for the internet protocol being
used (68 for IPv4, and 1280 for IPv6). 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 [5] and [9], in this case TCP will try TCP segment. As described by [RFC1191] and [RFC1981], in this case
to send a segment with 4424 bytes of data, which will result in an IP TCP will try to send a segment with 4424 bytes of data, which will
packet of 4464 octets. Therefore, maxsizesent is set to 4464. When result in an IP packet of 4464 octets. Therefore, maxsizesent is set
the packet reaches R1, it elicits an ICMP "Packet Too Big" error to 4464. When the packet reaches R1, it elicits an ICMP "Packet Too
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. maxsizesent
skipping to change at page 25, line 39 skipping to change at page 27, line 48
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.
A.5. TCP peer attacked when sending small packets just after the three- A.5. TCP peer attacked when sending small packets just after the three-
way handshake way handshake
This section analyzes an scenario in which a TCP peer that is sending This section analyzes an 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 being used by protocols such as
SMTP [34] and HTTP [35], for example, which usually behave like this. SMTP [RFC2821] and HTTP [RFC2616], for example, which usually behave
like this.
Figure 6 shows a possible packet exchange for such scenario. Figure 6 shows a possible packet exchange for such 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> <--
skipping to change at page 27, line 34 skipping to change at page 29, line 37
or was last recorded. or was last recorded.
current_mtu current_mtu
Variable holding the assumed Path-MTU for this connection. Variable holding the assumed Path-MTU for this connection.
drop_message() drop_message()
Function that performs the necessary actions to drop the ICMP Function that performs the necessary actions to drop the ICMP
message being processed. message being processed.
initial_mtu initial_mtu
Variable holding the MTU for new connections, as explained in [5] Variable holding the MTU for new connections, as explained in
and [9]. [RFC1191] and [RFC1981].
maxsizeacked maxsizeacked
Variable holding the largest packet size (data, plus headers) that Variable holding the largest packet size (data, plus headers) that
has so for been acked for this connection, as explained in has so for been acked for this connection, as explained in
Section 7.2 Section 7.2
maxsizesent maxsizesent
Variable holding the largest packet size (data, plus headers) that Variable holding the largest packet size (data, plus headers) that
has so for been sent for this connection, as explained in has so for been sent for this connection, as explained in
Section 7.2 Section 7.2
skipping to change at page 28, line 18 skipping to change at page 30, line 22
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, ad 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 timeout
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;
skipping to change at page 29, line 44 skipping to change at page 31, line 47
maxsizeacked = claimedmtu; maxsizeacked = claimedmtu;
maxsizesent = MINIMUM_MTU; maxsizesent = MINIMUM_MTU;
current_mtu = claimedmtu; current_mtu = claimedmtu;
} }
Notes: Notes:
All comparisions between sequence numbers must be performed using All comparisions between sequence numbers must be performed using
sequence number arithmethic. sequence number arithmethic.
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 [5] validation check on the advertised Next-Hop MTU described in
and [9]. [RFC1191] and [RFC1981].
Appendix C. Advice and guidance to vendors Appendix C. Additional considerations for the validation of ICMP error
messages
If a full TCP segment is contained in the payload of the ICMP error
message, then the first check that must be performed is that the TCP
checksum is valid. Then, if a TCP MD5 option is present, the MD5
signature should be recalculated for the encapsulated packet, and if
doesn't match the one contained in the TCP MD5 option, the packet
should be dropped.
Regardless of whether the received ICMP error message contains a full
packet or not, if a TCP timestamp option is present, it should be
used to validate the error message according to the rules specified
in [RFC1323].
It must be noted that all the checks discussed in this appendix imply
that the ICMP error message contains more data than just the full IP
header and the first 64 bits of the payload of the original datagram
that elicited the error message. As discussed in Section 3, for
obvious reasons one should not expect an attacker to include in the
packets it sends more information than that required to by the
current specifications.
Appendix D. Advice and guidance to vendors
Vendors are urged to contact NISCC (vulteam@niscc.gov.uk) if they Vendors are urged to contact NISCC (vulteam@niscc.gov.uk) if they
think they may be affected by the issues described in this document. think they may be affected by the issues described in this document.
As the lead coordination center for these issues, NISCC is well As the lead coordination center for these issues, NISCC is well
placed to give advice and guidance as required. placed to give advice and guidance as required.
NISCC works extensively with government departments and agencies, NISCC works extensively with government departments and agencies,
commercial organizations and the academic community to research commercial organizations and the academic community to research
vulnerabilities and potential threats to IT systems especially where vulnerabilities and potential threats to IT systems especially where
they may have an impact on Critical National Infrastructure's (CNI). they may have an impact on Critical National Infrastructure's (CNI).
Other ways to contact NISCC, plus NISCC's PGP public key, are Other ways to contact NISCC, plus NISCC's PGP public key, are
available at http://www.uniras.gov.uk/vuls/ . available at http://www.uniras.gov.uk/vuls/ .
Appendix D. Changes from previous versions of the draft Appendix E. Changes from previous versions of the draft
D.1. Changes from draft-gont-tcpm-icmp-attacks-03 E.1. Changes from draft-gont-tcpm-icmp-attacks-04
o Added Appendix C
o Added reference to [I-D.iab-link-indications]
o Added stress on the fact that ICMP error messages are unreliable
o Miscellaneous editorial changes
E.2. Changes from draft-gont-tcpm-icmp-attacks-03
o Added references to existing implementations of the proposed o Added references to existing implementations of the proposed
counter-measures counter-measures
o The discussion in Section 4 was improved o The discussion in Section 4 was improved
o The discussion in Section 5.2.1 was expanded and improved o The discussion in Section 5.2.1 was expanded and improved
o The proposed counter-measure for the attack against the PMTUD was o The proposed counter-measure for the attack against the PMTUD was
improved and simplified improved and simplified
o Appendix B was added o Appendix B was added
o Miscellaneous editorial changes o Miscellaneous editorial changes
D.2. Changes from draft-gont-tcpm-icmp-attacks-02 E.3. Changes from draft-gont-tcpm-icmp-attacks-02
o Fixed errors in Section 5.2.1 o Fixed errors in Section 5.2.1
o The proposed counter-measure for the attack against the PMTUD o The proposed counter-measure for the attack against the PMTUD
mechanism was refined to allow quick discovery of the Path-MTU mechanism was refined to allow quick discovery of the Path-MTU
o Appendix A was added so as to clarify the operation of the o Appendix A was added so as to clarify the operation of the
counter-measure for the attack against the PMTUD mechanism counter-measure for the attack against the PMTUD mechanism
o Added Appendix C o Added Appendix D
o Miscellaneous editorial changes o Miscellaneous editorial changes
D.3. Changes from draft-gont-tcpm-icmp-attacks-01 E.4. Changes from draft-gont-tcpm-icmp-attacks-01
o The document was restructured for easier reading o The document was restructured for easier reading
o A discussion of ICMPv6 was added in several sections of the o A discussion of ICMPv6 was added in several sections of the
document document
o Added Section on Acknowledgement number checking"/> o Added Section on Acknowledgement number checking"/>
o Added Section 4.3 o Added Section 4.3
skipping to change at page 31, line 17 skipping to change at page 34, line 4
o The document was restructured for easier reading o The document was restructured for easier reading
o A discussion of ICMPv6 was added in several sections of the o A discussion of ICMPv6 was added in several sections of the
document document
o Added Section on Acknowledgement number checking"/> o Added Section on Acknowledgement number checking"/>
o Added Section 4.3 o Added Section 4.3
o Added Section 7 o Added Section 7
o Fixed typo in the ICMP types, in several places o Fixed typo in the ICMP types, in several places
o Fixed typo in the TCP sequence number check formula o Fixed typo in the TCP sequence number check formula
o Miscellaneous editorial changes o Miscellaneous editorial changes
D.4. Changes from draft-gont-tcpm-icmp-attacks-00 E.5. Changes from draft-gont-tcpm-icmp-attacks-00
o Added a proposal to change the handling of the so-called ICMP hard o Added a proposal to change the handling of the so-called ICMP hard
errors during the synchronized states errors during the synchronized states
o Added a summary of the relevant RFCs in several sections o Added a summary of the relevant RFCs in several sections
o Miscellaneous editorial changes o Miscellaneous editorial changes
Author's Address Author's Address
 End of changes. 108 change blocks. 
347 lines changed or deleted 446 lines changed or added

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