draft-ietf-tcpm-icmp-attacks-00.txt   draft-ietf-tcpm-icmp-attacks-01.txt 
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UTN/FRH Extensions (tcpm) UTN/FRH
Expires: August 27, 2006 Intended status: Informational
Expires: April 26, 2007
ICMP attacks against TCP ICMP attacks against TCP
draft-ietf-tcpm-icmp-attacks-00.txt draft-ietf-tcpm-icmp-attacks-01.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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 35
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 August 27, 2006. This Internet-Draft will expire on April 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
of these attacks. of these attacks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5 2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5
2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 5 2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 5
2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6 2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6
2.2. Handling of ICMP error messages . . . . . . . . . . . . . 6 2.2. Handling of ICMP error messages . . . . . . . . . . . . . 6
3. Constraints in the possible solutions . . . . . . . . . . . . 7 2.3. Handling of ICMP error messages in the context of IPSec . 7
4. General counter-measures against ICMP attacks . . . . . . . . 8 3. Constraints in the possible solutions . . . . . . . . . . . . 8
4.1. TCP sequence number checking . . . . . . . . . . . . . . . 8 4. General counter-measures against ICMP attacks . . . . . . . . 9
4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 9 4.1. TCP sequence number checking . . . . . . . . . . . . . . . 9
4.3. Filtering ICMP error messages based on the ICMP payload . 9 4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 10
5. Blind connection-reset attack . . . . . . . . . . . . . . . . 10 4.3. Filtering ICMP error messages based on the ICMP payload . 10
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 10 5. Blind connection-reset attack . . . . . . . . . . . . . . . . 11
5.2. Attack-specific counter-measures . . . . . . . . . . . . . 11 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.1. Changing the reaction to hard errors . . . . . . . . . 11 5.2. Attack-specific counter-measures . . . . . . . . . . . . . 12
5.2.2. Delaying the connection-reset . . . . . . . . . . . . 13 5.2.1. Changing the reaction to hard errors . . . . . . . . . 12
6. Blind throughput-reduction attack . . . . . . . . . . . . . . 14 5.2.2. Delaying the connection-reset . . . . . . . . . . . . 15
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.3. Possible drawbacks of the described solutions . . . . 16
6.2. Attack-specific counter-measures . . . . . . . . . . . . . 14 6. Blind throughput-reduction attack . . . . . . . . . . . . . . 16
7. Blind performance-degrading attack . . . . . . . . . . . . . . 14 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 17
7.2. Attack-specific counter-measures . . . . . . . . . . . . . 16 7. Blind performance-degrading attack . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Attack-specific counter-measures . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. The counter-measure for the PMTUD attack in action . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
A.1. Normal operation for bulk transfers . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 24
A.2. Operation during Path-MTU changes . . . . . . . . . . . . 25 Appendix A. The counter-measure for the PMTUD attack in action . 26
A.3. Idle connection being attacked . . . . . . . . . . . . . . 26 A.1. Normal operation for bulk transfers . . . . . . . . . . . 26
A.2. Operation during Path-MTU changes . . . . . . . . . . . . 28
A.3. Idle connection being attacked . . . . . . . . . . . . . . 29
A.4. Active connection being attacked after discovery of A.4. Active connection being attacked after discovery of
the Path-MTU . . . . . . . . . . . . . . . . . . . . . . . 27 the Path-MTU . . . . . . . . . . . . . . . . . . . . . . . 30
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 . . . . . . . . . . . . . . 27 after the three-way handshake . . . . . . . . . . . . . . 30
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 . . . . . . . . . . . . 28 performance-degrading attack . . . . . . . . . . . . 31
Appendix C. Additional considerations for the validation of Appendix C. Additional considerations for the validation of
ICMP error messages . . . . . . . . . . . . . . . . . 32 ICMP error messages . . . . . . . . . . . . . . . . . 35
Appendix D. Advice and guidance to vendors . . . . . . . . . . . 32 Appendix D. Advice and guidance to vendors . . . . . . . . . . . 35
Appendix E. Changes from previous versions of the draft . . . . . 33 Appendix E. Changes from previous versions of the draft . . . . . 36
E.1. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 33 E.1. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 36
E.2. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 33 E.2. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 36
E.3. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 33 E.3. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 36
E.4. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 33 E.4. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 37
E.5. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 34 E.5. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 37
E.6. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 34 E.6. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 E.7. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 39
1. Introduction 1. Introduction
ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite,
and is used mainly for reporting network error conditions. However, and is used mainly for reporting network error conditions. However,
the current specifications do not recommend any kind of validation the current specifications do not recommend any kind of validation
checks on the received ICMP error messages, thus leaving the door checks on the received ICMP error messages, thus allowing variety of
open to a variety of attacks that can be performed against TCP attacks against TCP [RFC0793] by means of ICMP, which include blind
[RFC0793] by means of ICMP, which include blind connection-reset, connection-reset, blind throughput-reduction, and blind performance-
blind throughput-reduction, and blind performance-degrading attacks. degrading attacks. All of these attacks can be performed even being
All of these attacks can be performed even being off-path, without off-path, without the need to sniff the packets that correspond to
the need to sniff the packets that correspond to the attacked TCP the attacked TCP connection.
connection.
While the security implications of ICMP have been known in the While the possible security implications of ICMP have been known in
research community for a long time, there has never been an official the research community for a long time, there has never been an
proposal on how to deal with these vulnerabiliies. Thus, only a few official proposal on how to deal with these vulnerabiliies. Thus,
implementations have implemented validation checks on the received only a few implementations have implemented validation checks on the
ICMP error messages to minimize the impact of these attacks. received 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 [NISCC][US- or a subset of the attacks discussed in this document
CERT]. The affected systems ranged from TCP/IP implementations meant [NISCC][US-CERT]. The affected systems ranged from TCP/IP
for desktop computers, to TCP/IP implementations meant for core implementations meant for desktop computers, to TCP/IP
Internet routers. implementations meant for core Internet routers.
It is clear that implementations should be more cautious when It is clear that implementations should be more cautious when
processing ICMP error messages, to eliminate or mitigate the use of processing ICMP error messages, to eliminate or mitigate the use of
ICMP to perform attacks against TCP [I-D.iab-link-indications]. 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 discusses several counter-
that eliminate or minimize the impact of these attacks. measures that eliminate or minimize the impact of these attacks.
Most of the these counter-measures can be implemented while still
remaining compliant with the current specifications, as they simply
suggest reasons for not taking the advice provided in the
specifications in terms of "SHOULDs", but still comply with the
requirements stated as "MUSTs". Section 5.2, Section 6.2, and
Section 7.2 include an explanation of the current requirements and
advice relevant to each of the attack-specific counter-measures
described in this document.
Section 2 provides background information on ICMP. Section 3 Section 2 provides background information on ICMP. Section 3
discusses the constraints in the general counter-measures that can be discusses the constraints in the general counter-measures that can be
implemented against the attacks described in this document. implemented against the attacks described in this document.
Section 4 proposes several general validation checks and counter- Section 4 proposes several general validation checks and counter-
measures that can be implemented to mitigate any ICMP-based attack. measures that can be implemented to mitigate any ICMP-based attack.
Finally, Section 5, Section 6, and Section 7, discuss a variety of Finally, Section 5, Section 6, and Section 7, discuss a variety of
ICMP attacks that can be performed against TCP, and propose attack- ICMP attacks that can be performed against TCP, and propose attack-
specific counter-measures that eliminate or greatly mitigate their specific counter-measures that eliminate or greatly 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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Background 2. Background
skipping to change at page 5, line 17 skipping to change at page 5, line 25
2.1. The Internet Control Message Protocol (ICMP) 2.1. The Internet Control Message Protocol (ICMP)
The Internet Control Message Protocol (ICMP) is used in the Internet The Internet Control Message Protocol (ICMP) is used in the Internet
Architecture mainly to perform the fault-isolation function, that is, Architecture mainly to perform the fault-isolation function, that is,
the group of actions that hosts and routers take to determine that the group of actions that hosts and routers take to determine that
there is some network failure [RFC0816] there is some network failure [RFC0816]
When an intermediate router detects a network problem while trying to When an intermediate router detects a network problem while trying to
forward an IP packet, it will usually send an ICMP error message to forward an IP packet, it will usually send an ICMP error message to
the source host, to raise awareness of the network problem taking the source system, 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 handed 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 It is important to note that ICMP error messages are unreliable, and
may be discarded due to data corruption, network congestion and rate- may be discarded due to data corruption, network congestion or rate-
limiting. Thus, while they provide useful information, upper layer limiting. Thus, while they provide useful information, upper layer
protocols cannot depend on ICMP for correct operation. 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)
[RFC0792] specifies the Internet Control Message Protocol (ICMP) to [RFC0792] specifies the Internet Control Message Protocol (ICMP) to
be used with the Internet Protocol version 4 (IPv4). It defines, be used with the Internet Protocol version 4 (IPv4). It defines,
among other things, a number of error messages that can be used by among other things, a number of error messages that can be used by
end-systems and intermediate systems to report network errors to the end-systems and intermediate systems to report errors to the sending
sending host. The Host Requirements RFC [RFC1122] classifies ICMP system. The Host Requirements RFC [RFC1122] classifies ICMP error
error messages into those that indicate "soft errors", and those that messages into those that indicate "soft errors", and those that
indicate "hard errors", thus roughly defining the semantics of them. indicate "hard errors", thus roughly defining the semantics of them.
The ICMP specification [RFC0792] 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.
[RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD), [RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD),
which makes use of ICMP error messages of type 3 (Destination which makes use of ICMP error messages of type 3 (Destination
Unreachable), code 4 (fragmentation needed and DF bit set) to allow Unreachable), code 4 (fragmentation needed and DF bit set) to allow
hosts to determine the MTU of an arbitrary internet path. systems to determine the MTU of an arbitrary internet path.
Appendix D of [RFC2401] provides information about which ICMP error Appendix D of [RFC4301] 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)
[RFC2463] specifies the Internet Control Message Protocol (ICMPv6) to [RFC4443] specifies the Internet Control Message Protocol (ICMPv6) to
be used with the Internet Protocol version 6 (IPv6) [RFC2460]. be used with the Internet Protocol version 6 (IPv6) [RFC2460].
[RFC2463] defines the "Packet Too Big" (type 2, code 0) error [RFC4443] defines the "Packet Too Big" (type 2, code 0) error
message, that is analogous to the ICMP "fragmentation needed and DF message, that is analogous to the ICMP "fragmentation needed and DF
bit set" (type 3, code 4) error message. [RFC1981] defines the Path bit set" (type 3, code 4) error message. [RFC1981] defines the Path
MTU Discovery mechanism for IP Version 6, that makes use of these MTU Discovery mechanism for IP Version 6, that makes use of these
messages to determine the MTU of an arbitrary internet path. messages to determine the MTU of an arbitrary internet path.
Appendix D of [RFC2401] provides information about which ICMPv6 error Appendix D of [RFC4301] provides information about which ICMPv6 error
messages are produced by hosts, intermediate routers, or both. messages are produced by hosts, intermediate routers, or both.
2.2. Handling of ICMP error messages 2.2. Handling of ICMP error messages
The Host Requirements RFC [RFC1122] states that a TCP MUST act on an The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that a
ICMP error message passed up from the IP layer, directing it to the TCP MUST act on an ICMP error message passed up from the IP layer,
connection that elicited the error. directing it to the 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 system, 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 system 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 [RFC1122] nor the original TCP Neither the Host Requirements RFC [RFC1122] nor the original TCP
specification [RFC0793] recommend any validation checks on the specification [RFC0793] recommend any validation checks on the
received ICMP messages. Thus, as long as the ICMP payload contains received ICMP messages. Thus, as long as the ICMP payload contains
the information that identifies an existing communication instance, the information that identifies an existing communication instance,
it will be processed by the corresponding transport-protocol it will be processed by the corresponding transport-protocol
instance, and the corresponding action will be performed. instance, and the corresponding action will be performed.
Therefore, in the case of TCP, an attacker could send a 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 system, and, as long as he is able to guess
four-tuple that identifies the communication instance to be attacked, the four-tuple (i.e., Source IP Address, Source TCP port, Destination
he will be able to use ICMP to perform a variety of attacks. IP Address, and Destination TCP port) that identifies the
communication instance to be attacked, he will be able to use ICMP to
perform a variety of attacks.
As discussed in [Watson], there are a number of scenarios in which an Generally, the four-tuple required to perform these attacks is not
attacker may be able to know or guess the four-tuple that identifies known. However, as discussed in [Watson] and [Touch-antispoof],
a TCP connection. If we assume the attacker knows the two systems there are a number of scenarios (notably that of TCP connections
involved in the TCP connection to be attacked, both the client-side established between two BGP routers), in which an attacker may be
and the server-side IP addresses will be known. Furthermore, as most able to know or guess the four-tuple that identifies a TCP
connection. In such a case, if we assume the attacker knows the two
systems involved in the TCP connection to be attacked, both the
client-side and the server-side IP addresses could be known or be
within a reasonable number of possibilities. 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 might need to be guessed. In such a scenario, 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, as
systems choose the port numbers they use for outgoing connections most systems choose the port numbers they use for outgoing
from a subset of the whole port number space. Thus, in practice, connections from a subset of the whole port number space, the amount
fewer packets are needed to perform any of the attacks discussed in of packets needed to successfully perform any of the attacks
this document. discussed in this document could be further reduced.
It is clear that TCP should be more cautious when processing received It is clear that TCP should be more cautious when processing received
ICMP error messages, in order to mitigate or eliminate the impact of ICMP error messages, in order to mitigate or eliminate the impact of
the attacks described in this document [I-D.iab-link-indications]. the attacks described in this document [I-D.iab-link-indications].
2.3. Handling of ICMP error messages in the context of IPSec
Section 5.2 of [RFC4301] describes the processing inbound IP Traffic
in the case of "unprotected-to-protected". In the case of ICMP, when
an unprotected ICMP error message is received, it is matched to the
corresponding security association by means of the SPI (Security
Parameters Index) included in the payload of the ICMP error message.
Then, local policy is applied to determine whether to accept or
reject the message and, if accepted, what action to take as a result.
For example, if an ICMP unreachable message is received, the
implementation must decide whether to act on it, reject it, or act on
it with constraints. Section 8 ("Path MTU/DF processing") discusses
the processing of unauthenticated ICMP "fragmentation needed and DF
bit set" (type 3, code 3) and ICMPv6 "Packet Too Big" (type 2, code
0) messages when an IPsec implementation receives is configured to
process (vs. ignore) such messages.
Section 6.1.1 of [RFC4301] notes that processing of unauthenticated
ICMP error messages may result in denial or degradation of service,
and therefore it would be desirable to ignore such messages.
However, it also notes that in many cases ignoring these ICMP
messages can degrade service, e.g., because of a failure to process
PMTU message and redirection messages, and therefore there is also a
motivation for accepting and acting upon them. It finally states
that to accommodate both ends of this spectrum, a compliant IPsec
implementation MUST permit a local administrator to configure an
IPsec implementation to accept or reject unauthenticated ICMP
traffic, and that this control MUST be at the granularity of ICMP
type and MAY be at the granularity of ICMP type and code.
Additionally, an implementation SHOULD incorporate mechanisms and
parameters for dealing with such traffic.
Thus, the policy to apply for the processing of unprotected ICMP
error messages is left up to the implementation and administrator.
3. Constraints in the possible solutions 3. Constraints in the possible solutions
For ICMPv4, [RFC0792] states that the internet header plus the first For ICMPv4, [RFC0792] states that the internet header plus the first
64 bits of the packet that elicited the ICMP message are to be 64 bits of the packet that elicited the ICMP message are to be
included in the payload of the ICMP error message. Thus, it is included in the payload of the ICMP error message. Thus, it is
assumed that all data needed to identify a transport protocol assumed that all data needed to identify a transport protocol
instance and process the ICMP error message is contained in the first instance and process the ICMP error message is contained in the first
64 bits of the transport protocol header. [RFC1122] states that "the 64 bits of the transport protocol header. Section 3.2.2 of [RFC1122]
Internet header and at least the first 8 data octets of the datagram states that "the Internet header and at least the first 8 data octets
that triggered the error" are to be included in the payload of ICMP of the datagram that triggered the error" are to be included in the
error messages, and that "more than 8 octets MAY be sent", thus payload of ICMP error messages, and that "more than 8 octets MAY be
allowing implementations to include more data from the original sent", thus allowing implementations to include more data from the
packet than those required by the original ICMP specification. The original packet than those required by the original ICMP
Requirements for IP Version 4 Routers RFC [RFC1812] states that ICMP specification. The Requirements for IP Version 4 Routers RFC
error messages "SHOULD contain as much of the original datagram as [RFC1812] states that ICMP error messages "SHOULD contain as much of
possible without the length of the ICMP datagram exceeding 576 the original datagram as possible without the length of the ICMP
bytes". 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 [RFC2385], this mechanism by means of the TCP MD5 signature option [RFC2385], this mechanism
could not be used as a counter-measure against ICMP-based attacks, could not be used as a counter-measure against ICMP-based attacks,
because, as ICMP messages include only a piece of the TCP segment because, as ICMP messages include only a piece of the TCP segment
that elicited the error, the MD5 [RFC1321] signature could not be that elicited the error, the MD5 [RFC1321] signature could not be
recalculated. In the same way, even if the attacked peer were recalculated. In the same way, even if the attacked peer were
authenticating its packets at the IP layer [RFC2401], because only a authenticating its packets at the IP layer [RFC4301], because only a
part of the original IP packet would be available, the signature used part of the original IP packet would be available, the signature used
for authentication could not be recalculated, and thus this mechanism for authentication could not be recalculated, and thus this mechanism
could not be used as a counter-measure aganist ICMP-based attacks could not be used as a counter-measure aganist ICMP-based attacks
against TCP. 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) [RFC2463]. Thus, more information is minimum IPv6 MTU (1280 octets) [RFC4443]. 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 Hosts could require ICMP error messages to be authenticated
[RFC2401], in order to act upon them. However, while this [RFC4301], in order to act upon them. However, while this
requirement could make sense for those ICMP error messages sent by requirement could make sense for those ICMP error messages sent by
hosts, it would not be feasible for those ICMP error messages hosts, it would not be feasible for those ICMP error messages
generated by routers, as this would imply either that the attacked generated by routers, as this would imply either that the attacked
host should have a security association [RFC2401] with every existing system should have a security association [RFC4301] with every
intermediate system, or that it should be able to establish one existing intermediate system, or that it should be able to establish
dynamically. Current levels of deployment of protocols for dynamic one dynamically. Current levels of protocol deployment for dynamic
establishment of security associations makes this unfeasible. Also, establishment of security associations makes this unfeasible. Also,
there may be some cases, such as embedded devices, in which the there may be some cases, such as embedded devices, in which the
processing power requirements of authentication could not allow IPSec processing power requirements of authentication could not allow IPSec
authentication to be implemented effectively. authentication to be implemented effectively.
Additional considerations for the validation of ICMP error messages Additional considerations for the validation of ICMP error messages
can be found in Appendix C can be found in Appendix C
4. General counter-measures against ICMP attacks 4. General counter-measures against ICMP attacks
skipping to change at page 8, line 41 skipping to change at page 9, line 41
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.
4.1. TCP sequence number checking 4.1. TCP sequence number checking
The current specifications do not impose any validity checks on the The current specifications do not impose any validity checks on the
TCP segment that is contained in the ICMP payload. For instance, no TCP segment that is contained in the ICMP payload. For instance, no
checks are performed to verify that a received ICMP error message has checks are performed to verify that a received ICMP error message has
been elicited by a segment that was "in flight" to destination. been elicited by a segment that was "in flight" to the destination.
Thus, even stale ICMP error messages will be acted upon. Thus, even stale ICMP error messages will be acted upon.
TCP should check that the TCP sequence number contained in the TCP should check that the TCP sequence number contained in the
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
skipping to change at page 9, line 24 skipping to change at page 10, line 24
years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and
NetBSD [NetBSD] since 2005. NetBSD [NetBSD] since 2005.
It is important to note that while this check greatly increases the It is important to note that while this check greatly increases the
number of packets required to perform any of the attacks discussed in number of packets required to perform any of the attacks discussed in
this document, this may not be enough in those scenarios in which this document, this may not be enough in those scenarios in which
bandwidth is easily available, and/or large TCP windows [RFC1323] are bandwidth is easily available, and/or large TCP windows [RFC1323] are
in use. 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.
A TCP that implements the TCP sequence number checking as the only
validation of ICMP error messages will have the same susceptibility
to attacks as the one TCP currently has in the case of TCP-based
attacks. Further information on this issue can be found in [Touch-
antispoof].
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.
[I-D.larsen-tsvwg-port-randomisation] discusses a number of [I-D.larsen-tsvwg-port-randomisation] discusses a number of
algorithms to randomize the ephemeral 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 middlebox devices
counter-measure. Firewalls implementing such advanced filtering such as firewalls and NATs as a counter-measure. Middleboxes
would look at the payload of the ICMP error messages, and would implementing such advanced filtering would look at the payload of the
perform ingress and egress packet filtering based on the source IP ICMP error messages, and would perform ingress and egress packet
address of the IP header contained in the payload of the ICMP error filtering based on the source IP address of the IP header contained
message. As the source IP address contained in the payload of the in the payload of the ICMP error message. As the source IP address
ICMP error message does need to be spoofed to perform the attacks contained in the payload of the ICMP error message does need to be
described in this document, this kind of advanced filtering would spoofed to perform the attacks described in this document, this kind
serve as a counter-measure against these attacks. of advanced filtering would serve as a counter-measure against these
attacks. As with traditional egress filtering [IP-filtering], egress
filtering based on the ICMP payload can help to prevent users of the
network being protected by the firewall from successfully performing
ICMP attacks against TCP connections established between external
systems. Additionally, ingress filtering based on the ICMP payload
can prevent TCP connections established between internal systems from
attacks performed by external systems. [ICMP-Filtering] provides
examples of ICMP filtering based on the ICMP payload.
This filtering has been implemented in OpenBSD's Packet Filter
[OpenBSD-PF], which has in turn been ported to a number of systems,
including FreeBSD [FreeBSD].
5. Blind connection-reset attack 5. Blind connection-reset attack
5.1. Description 5.1. Description
When TCP is handled an ICMP error message, it will perform its fault When TCP is handed an ICMP error message, it will perform its fault
recovery function, as follows: recovery function, as follows:
o If the network problem being reported is a hard error, TCP will o If the network problem being reported is a hard error, TCP will
abort the corresponding connection. abort the corresponding connection.
o If the network problem being reported is a soft error, TCP will o If the network problem being reported is a soft error, TCP will
just record this information, and repeatedly retransmit its data just record this information, and repeatedly retransmit its data
until they either get acknowledged, or the connection times out. until they either get acknowledged, or the connection times out.
The Host Requirements RFC [RFC1122] states that a host SHOULD abort The Host Requirements RFC [RFC1122] states (in Section 4.2.3.9) that
the corresponding connection when receiving an ICMP error message a host SHOULD abort the corresponding connection when receiving an
that indicates a "hard error", and states that ICMP error messages of ICMP error message that indicates a "hard error", and states that
type 3 (Destination Unreachable) codes 2 (protocol unreachable), 3 ICMP error messages of type 3 (Destination Unreachable) codes 2
(port unreachable), and 4 (fragmentation needed and DF bit set) (protocol unreachable), 3 (port unreachable), and 4 (fragmentation
should be considered to indicate hard errors. While [RFC2463] did needed and DF bit set) should be considered to indicate hard errors.
not exist when [RFC1122] was published, one could extrapolate the In the case of ICMP port unreachables, the specifications are
concept of "hard errors" to ICMPv6 error messages of type 1 ambiguous, as Section 4.2.3.9 of [RFC1122] states that TCP SHOULD
(Destination unreachable) codes 1 (communication with destination abort the corresponding connection in response to them, but Section
administratively prohibited), and 4 (port unreachable). 3.2.2.1 of the same RFC ([RFC1122] states that TCP MUST abort the
connection in response to them.
While [RFC4443] did not exist when [RFC1122] was published, one could
extrapolate the concept of "hard errors" to ICMPv6 error messages of
type 1 (Destination unreachable) codes 1 (communication with
destination administratively prohibited), and 4 (port unreachable).
Thus, an attacker could use ICMP to perform a blind connection-reset Thus, an attacker could use ICMP to perform a blind connection-reset
attack. That is, even being off-path, an attacker could reset any attack by sending any ICMP error message that indicates a "hard
TCP connection taking place. In order to perform such an attack, an
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 Some stacks are known to extrapolate ICMP hard errors across TCP
such an attack is the socket pair that identifies the TCP connection
to be attacked. In some scenarios, the IP addresses and port numbers
in use may be easily guessed or known to the attacker [Watson].
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 [Watson] and against the blind connection-reset attack described in [Watson] and
[I-D.ietf-tcpm-tcpsecure], by means authentication at the network [I-D.ietf-tcpm-tcpsecure], by means authentication at the network
layer [RFC2401], by means of the TCP MD5 signature option [RFC2385], layer [RFC4301], by means of the TCP MD5 signature option [RFC2385],
or by means of the mechanism proposed in [I-D.ietf-tcpm-tcpsecure], or by means of the mechanism proposed in [I-D.ietf-tcpm-tcpsecure],
the blind connection-reset attack described in this document would the blind connection-reset attack described in this document would
still succeed. still succeed.
5.2. Attack-specific counter-measures 5.2. Attack-specific counter-measures
The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that
TCP SHOULD abort the corresponding connection in response to ICMP
messages of type 3, codes 2 (protocol unreachable), 3 (port
unreachable), and 4 (fragmentation needed and DF bit set). However,
Section 3.2.2.1 states that TCP MUST accept an ICMP port unreachable
(type 3, code 3) for the same purpose as an RST. Therefore, for ICMP
messages of type 3 codes 2 and 4 there is room to go against the
advice provided in the existing specifications, while in the case of
ICMP messages of type 3 code 3 the ambiguity in the specification
also allows us to go against the advice provided by the existing
specifications, while still remaining compliant with them. Given the
hostile environments in which TCP currently operates in, and that
advice ICMP provides an attack vector that is easier to exploit than
others (such as those discussed in [I-D.ietf-tcpm-tcpsecure]), we
believe that the improvements in TCP's resistance to these attacks
justify not taking the advice provided by the "SHOULDs" in [RFC1122].
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)
This ICMP error message indicates that the host sending the ICMP This ICMP error message indicates that the host sending the ICMP
error message received a packet meant for a transport protocol it error message received a packet meant for a transport protocol it
does not support. For connection-oriented protocols such as TCP, does not support. For connection-oriented protocols such as TCP,
one could expect to receive such an error as the result of a one could expect to receive such an error as the result of a
connection-establishment attempt. However, it would be strange to connection-establishment attempt. However, it would be strange to
get such an error during the life of a connection, as this would get such an error during the life of a connection, as this would
indicate that support for that transport protocol has been removed indicate that support for that transport protocol has been removed
from the host sending the error message during the life of the from the system sending the error message during the life of the
corresponding connection. Thus, it would be fair to treat ICMP corresponding connection. Thus, it would be fair to treat ICMP
protocol unreachable error messages as soft errors (or completely protocol unreachable error messages as soft errors if they are
ignore them) if they are meant for connections that are in meant for connections that are in synchronized states. For TCP,
synchronized states. For TCP, this means TCP should treat ICMP this means TCP would treat ICMP protocol unreachable error
protocol unreachable error messages as soft errors (or completely messages as soft errors if they are meant for connections that are
ignore them) if they are meant for connections that are in the in any of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-
ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT).
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 system sending the ICMP
message received a packet meant for a socket (IP address, port error message received a packet meant for a socket (IP address,
number) on which there is no process listening. Those transport port number) on which there is no process listening. Those
protocols which have their own mechanisms for notifying this transport protocols which have their own mechanisms for notifying
condition should not be receiving these error messages. However, this condition should not be receiving these error messages, as
the Host Requirements RFC [RFC1122] states that even those the protocol would signal the port unreachable condition by means
transport protocols that have their own mechanism for notifying of its own messages. Assuming that once a connection is
the sender that a port is unreachable MUST nevertheless accept an established it is not usual for the transport protocol to change
ICMP Port Unreachable for the same purpose. For security reasons, (or be reloaded), it would be fair to treat ICMP port unreachable
it would be fair to treat ICMP port unreachable messages as soft messages as soft errors when they are meant for a TCP that is in
errors (or completely ignore them) when they are meant for any of the synchronized states (ESTABLISHED, FIN-WAIT-1,
protocols that have their own mechanism for reporting this error FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT).
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. It is considered a soft error when TCP implements
mechanism should not be sending their IP packets with the DF bit PMTUD, and a hard error if TCP does not implement PMTUD. Those
set, and thus should not be receiving these ICMP error messages. systems that do not implement the PMTUD mechanism should not be
Thus, it would be fair for them to treat this ICMP error message sending their IP packets with the DF bit set, and thus should not
as indicating a soft error, therefore not aborting the be receiving these ICMP error messages. Thus, it would be fair
corresponding connection when such an error message is received. for TCPs in any of the synchronized states to treat this ICMP
On the other hand, and for obvious reasons, those systems error message as indicating a soft error, therefore not aborting
implementing the Path-MTU Discovery (PMTUD) mechanism [RFC1191] the corresponding connection when such an error message is
should not abort the corresponding connection when such an ICMP received. For obvious reasons, those systems implementing the
error message is received. Path-MTU Discovery (PMTUD) mechanism [RFC1191] should not abort
the corresponding connection when such an ICMP 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
of the connection. Therefore, while it would be possible for a of the connection. However, there is no reason to think that in
the same way this error condition appeared, it will not get solved
in the near term. Therefore, while it would be possible for a
firewall to be reconfigured during the life of a connection, it firewall to be reconfigured during the life of a connection, it
would be fair, for security reasons, to ignore these messages for would be fair, for security reasons, to treat these messages as
connections that are in the ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, soft errors when they are meant for connections that are in any of
CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT states. the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2,
CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT states).
ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable) ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable)
This error message is analogous to the ICMP type 3 (Destination This error message is analogous to the ICMP type 3 (Destination
Unreachable), code 3 (Port unreachable) error message discussed Unreachable), code 3 (Port unreachable) error message discussed
above. Therefore, the same considerations apply. above. Therefore, the same considerations apply.
Therefore, TCP should treat all of the above messages as indicating Therefore, when following the reasoning explained above, TCPs in
"soft errors", rather than "hard errors", and thus should not abort synchronized states would treat all of the above messages as
the corresponding connection upon receipt of them. This is policy is indicating "soft errors", rather than "hard errors", and thus would
based on the premise that TCP should be as robust as possible. Also, not abort the corresponding connection upon receipt of them. This is
as discussed in Section 5.1, hosts should not extrapolate ICMP errors policy is based on the premise that TCP should be as robust as
across TCP connections. possible. Reaction to these messages when they are meant for
connections in non-synchronized states could still remain as adviced
by [RFC1122], as we consider the attack window for connections in the
non-synchronized states is very small, and error messages received in
these states are more likely indicate that the connection was opened
improperly [RFC0816]. Additionally, for the sake of robustness and
security, those implementations following the reasoning explained in
this section would not extrapolate ICMP errors 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. error condition appeared during the life of the corresponding
However, there is no reason to think that in the same way this error connection. However, in many scenarios there is no reason to think
condition appeared, it won't get solved in the near term. Therefore, that in the same way this error condition appeared, it will not get
treating the received ICMP error messages as "soft errors" would make solved in the near term. Therefore, treating the received ICMP error
TCP more robust, and could avoid TCP from aborting a TCP connection messages as "soft errors" would make TCP more robust, and could avoid
unnecesarily. Aborting the connection would be to ignore the TCP from aborting a TCP connection unnecesarily. Aborting the
valuable feature of the Internet that for many internal failures it connection would be to ignore the valuable feature of the Internet
reconstructs its function without any disruption of the end points that for many internal failures it reconstructs its function without
[RFC0816]. any disruption of the end points [RFC0816].
Also, it is important to note that the "Host Requirements RFC"
[RFC1122] allows this alternative processing of ICMP error messages.
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 [DClark]. there is still a working path to the destination system [DClark].
Thus, 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 would eventually time out. Also, corresponding connection would eventually time out. Also,
applications may still be notified asynchronously about the received applications may still be notified asynchronously about the received
error messages, and thus may still abort their connections on their error messages, and thus may still abort their connections on their
own if they consider it appropriate. own if they consider it appropriate.
This counter-measure has been implemented in BSD-derived TCP/IP This counter-measure has been implemented in BSD-derived TCP/IP
implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more
than ten years [Wright][McKusick]. The Linux kernel has implemented than ten years [Wright][McKusick]. The Linux kernel has also
this policy for more than ten years, too [Linux]. implemented this policy for more than ten years [Linux].
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 would be, in the case of connections
reset. Rather than immediately aborting a connection, a TCP would in any of the synchronized states, to honor the ICMP error messages
abort a connection only after an ICMP error message indicating a hard only if there is no progress on the connection. Rather than
error has been received, and the corresponding data have already been immediately aborting a connection, a TCP would abort a connection
retransmitted more than some specified number of times. only after an ICMP error message indicating a hard error has been
received, and the corresponding data have already been 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
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.
5.2.3. Possible drawbacks of the described solutions
In scenarios such as that in which an intermediate system sets the DF
bit in the segments transmitted by a TCP that does not implement
PMTUD, or the TCP at one of the endpoints of the connection is
dynamically disabled, TCP would only abort the connection after a
USER TIMEOUT [RFC0793], losing responsiveness. However, we consider
these senarios very unlikely in production environments, and consider
that it is preferebable to potentially lose responsiveness for the
sake of robustness. It should also be noted that 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.
In scenarios of multipath routing or route changes, failures in some
(but not all) of the paths may elicit ICMP error messages that would
likely not cause a connection abort if any of the counter-measures
described in this section were implemented. However, as explained
above, 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]. Additionally, 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.
6. Blind throughput-reduction attack 6. Blind throughput-reduction attack
6.1. Description 6.1. Description
The Host requirements RFC [RFC1122] states that hosts MUST react to The Host requirements RFC [RFC1122] states that hosts MUST react to
ICMP Source Quench messages by slowing transmission on the ICMP Source Quench messages by slowing transmission on the
connection. Thus, an attacker could send ICMP Source Quench (type 4, connection. Thus, an attacker could send ICMP Source Quench (type 4,
code 0) messages to a TCP endpoint to make it reduce the rate at code 0) messages to a TCP endpoint to make it reduce the rate at
which it sends data to the other end-point of the connection. which it sends data to the other end-point of the connection.
[RFC1122] further adds that the RECOMMENDED procedure is to put the [RFC1122] further adds that the RECOMMENDED procedure is to put the
skipping to change at page 14, line 27 skipping to change at page 17, line 7
control algorithm [RFC2581]. In the case of those implementations control algorithm [RFC2581]. In the case of those implementations
that use an initial congestion window of one segment, a sustained that use an initial congestion window of one segment, a sustained
attack would reduce the throughput of the attacked connection to attack would reduce the throughput of the attacked connection to
about SMSS (Sender Maximum Segment Size) [RFC2581] bytes per RTT about SMSS (Sender Maximum Segment Size) [RFC2581] bytes per RTT
(round-trip time). The throughput achieved during attack might be a (round-trip time). The throughput achieved during attack might be a
little higher if a larger initial congestion window is in use little higher if a larger initial congestion window is in use
[RFC3390]. [RFC3390].
6.2. Attack-specific counter-measures 6.2. Attack-specific counter-measures
The Host Requirements RFC [RFC1122] states that hosts MUST react to The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that
ICMP Source Quench messages by slowing transmission on the hosts MUST react to ICMP Source Quench messages by slowing
connection. However, as discussed in the Requirements for IP Version transmission on the connection. Therefore, the only counter-measures
4 Routers RFC [RFC1812], research seems to suggest ICMP Source Quench for this attack that can be implemented while still remaining
is an ineffective (and unfair) antidote for congestion. [RFC1812] compliant with the existing specifications are the ones discussed in
further states that routers SHOULD NOT send ICMP Source Quench Section 4.
messages in response to congestion. On the other hand, TCP
implements its own congestion control mechanisms [RFC2581] [RFC3168],
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 [Linux] since 2004, and Nevertheless, it must be noted that, as discussed in the Requirements
in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] since for IP Version 4 Routers RFC [RFC1812], research seems to suggest
2005. that ICMP Source Quench is an ineffective (and unfair) antidote for
congestion. [RFC1812] further states that routers SHOULD NOT send
ICMP Source Quench messages in response to congestion. On the other
hand, TCP implements its own congestion control mechanisms [RFC2581]
[RFC3168], that do not depend on ICMP Source Quench messages.
Based on this reasoning, a large number of implementations completely
ignore ICMP Source Quench messages meant for TCP connections. This
behavior has been implemented in, at least, Linux [Linux] since 2004,
and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD]
since 2005. However, as explained earlier in this section, this
behaviour violates the requirement in [RFC1122] to react to ICMP
Source Quench messages by slowing transmission on the connection.
7. Blind performance-degrading attack 7. Blind performance-degrading attack
7.1. Description 7.1. Description
When one IP host has a large amount of data to send to another host, When one IP system has a large amount of data to send to another
the data will be transmitted as a series of IP datagrams. It is system, the data will be transmitted as a series of IP datagrams. It
usually preferable that these datagrams be of the largest size that is usually preferable that these datagrams be of the largest size
does not require fragmentation anywhere along the path from the that does not require fragmentation anywhere along the path from the
source to the destination. This datagram size is referred to as the source to the destination. This datagram size is referred to as the
Path MTU (PMTU), and is equal to the minimum of the MTUs of each hop Path MTU (PMTU), and is equal to the minimum of the MTUs of each hop
in the path [RFC1191]. in the path. A technique called "Path MTU Discovery" (PMTUD) lets IP
systems determine the Path MTU of an arbitrary internet path.
A technique called "Path MTU Discovery" (PMTUD) mechanism lets IP
hosts determine the Path MTU of an arbitrary internet path.
[RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and [RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and
IPv6, respectively. IPv6, respectively.
The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the
IP header to dynamically discover the Path MTU. The basic idea IP header to dynamically discover the Path MTU. The basic idea
behind the PMTUD mechanism is that a source host assumes that the MTU behind the PMTUD mechanism is that a source system assumes that the
of the path is that of the first hop, and sends all its datagrams MTU of the path is that of the first hop, and sends all its datagrams
with the DF bit set. If any of the datagrams is too large to be with the DF bit set. If any of the datagrams is too large to be
forwarded without fragmentation by some intermediate router, the forwarded without fragmentation by some intermediate router, the
router will discard the corresponding datagram, and will return an router will discard the corresponding datagram, and will return an
ICMP "Destination Unreachable" (type 3) "fragmentation 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 the sending system. This message will
report the MTU of the constricting hop, so that the sending host can report the MTU of the constricting hop, so that the sending system
reduce the assumed Path-MTU accordingly. can reduce the assumed Path-MTU accordingly.
For IPv6, intermediate systems do not fragment packets. Thus, For IPv6, intermediate systems do not fragment packets. Thus,
there's an "implicit" DF bit set in every packet sent on a network. there's an "implicit" DF bit set in every packet sent on a network.
If any of the datagrams is too large to be forwarded without If any of the datagrams is too large to be forwarded without
fragmentation by some intermediate router, the router will discard fragmentation by some intermediate router, the router will discard
the corresponding datagram, and will return an ICMPv6 "Packet Too the corresponding datagram, and will return an ICMPv6 "Packet Too
Big" (type 2, code 0) error message to sending host. This message Big" (type 2, code 0) error message to sending system. 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
can reduce the assumed Path-MTU accordingly. system can reduce the assumed Path-MTU accordingly.
As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery
mechanism can be used to attack TCP. An attacker could send a forged mechanism can be used to attack TCP. An attacker could send a forged
ICMP "Destination Unreachable, fragmentation needed and DF set" ICMP "Destination Unreachable, fragmentation needed and DF set"
packet (or their ICMPv6 counterpart) to the sending host, advertising packet (or their ICMPv6 counterpart) to the sending system,
a small Next-Hop MTU. As a result, the attacked system would reduce advertising a small Next-Hop MTU. As a result, the attacked system
the size of the packets it sends for the corresponding connection would reduce the size of the packets it sends for the corresponding
accordingly. connection accordingly.
The effect of this attack is two-fold. On one hand, it will increase The effect of this attack is two-fold. On one hand, it will increase
the headers/data ratio, thus increasing the overhead needed to send the headers/data ratio, thus increasing the overhead needed to send
data to the remote TCP end-point. On the other hand, if the attacked data to the remote TCP 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 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 attacker reports a Next-Hop MTU smaller than or equal to the amount
of bytes needed for headers (IP header, plus TCP header). For 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 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 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 larger than 68 bytes, the assumed Path-MTU will not even allow the
attacked host to send a single byte of application data without attacked system to send a single byte of application data without
fragmentation. This particular scenario might lead to unpredictable fragmentation. This particular scenario might lead to unpredictable
results. Another posible scenario is that in which a TCP connection 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 is being secured by means of IPSec. If the Next-Hop MTU reported by
the attacker is smaller than the amount of bytes needed for headers the attacker is smaller than the amount of bytes needed for headers
(IP and IPSec, in this case), the assumed Path-MTU will not even (IP and IPSec, in this case), the assumed Path-MTU will not even
allow the attacked host to send a single byte of the TCP header allow the attacked system to send a single byte of the TCP header
without fragmentation. This is another scenario that may lead to without fragmentation. This is another scenario that may lead to
unpredictable results. unpredictable results.
For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as
[RFC0791] requires every internet module to be able to forward a [RFC0791] requires every internet module to be able to forward a
datagram of 68 octets without further fragmentation. For IPv6, the datagram of 68 octets without further fragmentation. For IPv6, the
reported Next-Hop MTU could be as low as 1280 octets (the minimum reported Next-Hop MTU could be as low as 1280 octets (the minimum
IPv6 MTU) [RFC2460]. IPv6 MTU) [RFC2460].
7.2. Attack-specific counter-measures 7.2. Attack-specific counter-measures
This section describes a modification to the PMTUD mechanism
specified in [RFC1191] and [RFC1981] that has been implemented in a
variety of TCP implementations to improve TCP's resistance to the
blind performance-degrading attack described in Section 7.1. The
described mechanism basically disregards ICMP messages when a
connection makes progress. This modification does not violate any of
the requirements stated in [RFC1191] and [RFC1981].
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.
This would mean that upon receipt of an ICMP "Packet Too Big" error This would mean that upon receipt of an ICMP "Packet Too Big" error
message, TCP would just record this information, and would honor it message, TCP would just record this information, and would honor it
skipping to change at page 19, line 43 skipping to change at page 22, line 34
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 [I-D.gont-tcpm-tcp-soft-errors] by private e-mail. issues related to [I-D.ietf-tcpm-tcp-soft-errors] by private e-mail.
The author would like to thank Ran Atkinson, James Carlson, Alan Cox, The author would like to thank Bora Akyol, Mark Allman, Ran Atkinson,
Theo de Raadt, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo James Carlson, Alan Cox, Theo de Raadt, Ted Faber, Juan Fraschini,
Gont, John Heffner, Vivek Kakkar, Michael Kerrisk, Mika Liljeberg, Markus Friedl, Guillermo Gont, John Heffner, Vivek Kakkar, Michael
Matt Mathis, David Miller, Miles Nordin, Eloy Paris, Kacheong Poon, Kerrisk, Mika Liljeberg, Matt Mathis, David Miller, Miles Nordin,
Andrew Powell, Pekka Savola, Joe Touch, and Andres Trapanotto, for Eloy Paris, Kacheong Poon, Andrew Powell, Pekka Savola, Pyda
Srisuresh, Fred Templin, Joe Touch, and Andres Trapanotto, for
contributing many valuable comments. contributing many valuable comments.
Juan Fraschini and the author of this document implemented freely- Juan Fraschini and the author of this document implemented freely-
available audit tools to help vendors audit their systems by available audit tools to help vendors audit their systems by
reproducing the attacks discussed in this document. reproducing the attacks discussed in this document.
Markus Friedl, Chad Loder, and the author of this document, produced Markus Friedl, Chad Loder, and the author of this document, produced
and tested in OpenBSD [OpenBSD] the first implementation of the and tested in OpenBSD [OpenBSD] the first implementation of the
counter-measure described in Section 7.2. This first implementation counter-measure described in Section 7.2. This first implementation
helped to test the effectiveness of the ideas introduced in this helped to test the effectiveness of the ideas introduced in this
skipping to change at page 21, line 5 skipping to change at page 23, line 44
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995. RFC 1812, June 1995.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2463] Conta, A. and S. Deering, "Internet Control Message [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Protocol (ICMPv6) for the Internet Protocol Version 6 Internet Protocol", RFC 4301, December 2005.
(IPv6) Specification", RFC 2463, December 1998.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
10.2. Informative References 10.2. Informative References
[DClark] Clark, D., "The Design Philosophy of the DARPA Internet [DClark] Clark, D., "The Design Philosophy of the DARPA Internet
Protocols", Computer Communication Review Vol. 18, No. 4, Protocols", Computer Communication Review Vol. 18, No. 4,
1988. 1988.
[FreeBSD] The FreeBSD Project, "http://www.freebsd.org". [FreeBSD] The FreeBSD Project, "http://www.freebsd.org".
[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.
[I-D.iab-link-indications] [I-D.iab-link-indications]
Aboba, B., "Architectural Implications of Link Aboba, B., "Architectural Implications of Link
Indications", draft-iab-link-indications-04 (work in Indications", draft-iab-link-indications-05 (work in
progress), December 2005. progress), July 2006.
[I-D.ietf-pmtud-method] [I-D.ietf-pmtud-method]
Mathis, M. and J. Heffner, "Path MTU Discovery", Mathis, M. and J. Heffner, "Packetization Layer Path MTU
draft-ietf-pmtud-method-05 (work in progress), Discovery", draft-ietf-pmtud-method-10 (work in progress),
October 2005. September 2006.
[I-D.ietf-tcpm-tcp-soft-errors]
Gont, F., "TCP's Reaction to Soft Errors",
draft-ietf-tcpm-tcp-soft-errors-02 (work in progress),
October 2006.
[I-D.ietf-tcpm-tcpsecure] [I-D.ietf-tcpm-tcpsecure]
Dalal, M., "Improving TCP's Robustness to Blind In-Window Stewart, R. and M. Dalal, "Improving TCP's Robustness to
Attacks", draft-ietf-tcpm-tcpsecure-03 (work in progress), Blind In-Window Attacks", draft-ietf-tcpm-tcpsecure-05
May 2005. (work in progress), June 2006.
[I-D.larsen-tsvwg-port-randomisation] [I-D.larsen-tsvwg-port-randomisation]
Larsen, M., "Port Randomisation", Larsen, M., "Port Randomisation",
draft-larsen-tsvwg-port-randomisation-00 (work in draft-larsen-tsvwg-port-randomisation-00 (work in
progress), October 2004. progress), October 2004.
[ICMP-Filtering]
Gont, F., "Filtering of ICMP error messages", http://
www.gont.com.ar/papers/filtering-icmp-error-messages.pdf.
[IP-filtering]
NISCC, "NISCC Technical Note 01/2006: Egress and Ingress
Filtering", http://www.niscc.gov.uk/niscc/docs/
re-20060420-00294.pdf?lang=en, 2006.
[Linux] The Linux Project, "http://www.kernel.org". [Linux] The Linux Project, "http://www.kernel.org".
[McKusick] [McKusick]
McKusick, M., Bostic, K., Karels, M., and J. Quarterman, McKusick, M., Bostic, K., Karels, M., and J. Quarterman,
"The Design and Implementation of the 4.4BSD Operating "The Design and Implementation of the 4.4BSD Operating
System", Addison-Wesley , 1996. System", Addison-Wesley , 1996.
[NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: [NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP:
Vulnerability Issues in ICMP packets with TCP payloads", Vulnerability Issues in ICMP packets with TCP payloads",
http://www.niscc.gov.uk/niscc/docs/ http://www.niscc.gov.uk/niscc/docs/
al-20050412-00308.html?lang=en, 2005. al-20050412-00308.html?lang=en, 2005.
[NetBSD] The NetBSD Project, "http://www.netbsd.org". [NetBSD] The NetBSD Project, "http://www.netbsd.org".
[OpenBSD] The OpenBSD Project, "http://www.openbsd.org". [OpenBSD] The OpenBSD Project, "http://www.openbsd.org".
[OpenBSD-PF]
The OpenBSD Packet Filter,
"http://www.openbsd.org/faq/pf/".
[RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816,
July 1982. July 1982.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
skipping to change at page 29, line 42 skipping to change at page 32, line 45
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 Variable holding the MTU for new connections, as explained in
[RFC1191] and [RFC1981]. [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 far 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 far this connection, as explained in
Section 7.2 Section 7.2
nsegrto nsegrto
Variable holding the number of times this segment has timed out, Variable holding the number of times this segment has timed out,
as explained in Section 7.2 as explained in Section 7.2
packet_size packet_size
Variable holding the size of the IP datagram being sent Variable holding the size of the IP datagram being sent
pending_message pending_message
Variable (flag) that indicates whether there is a pending ICMP Variable (flag) that indicates whether there is a pending ICMP
"Packet Too Big" message to be processed. "Packet Too Big" message to be processed.
save_message() save_message()
Function that records the ICMP "Packet Too Big" message that has Function that records the ICMP "Packet Too Big" message that has
just been received. just been received.
MINIMUM_MTU MINIMUM_MTU
Constant holding the minimum MTU for the internet protocol in use Constant holding the minimum MTU for the internet protocol in use
(68 for IPv4, and 1280 for IPv6. (68 for IPv4, and 1280 for IPv6).
MAXSEGRTO MAXSEGRTO
Constant holding the number of times a given segment must timeout Constant holding the number of times a given segment must 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 32, line 13 skipping to change at page 35, line 13
[RFC1191] and [RFC1981]. [RFC1191] and [RFC1981].
Appendix C. Additional considerations for the validation of ICMP error Appendix C. Additional considerations for the validation of ICMP error
messages messages
The checksum of the IP datagram contained in the ICMP payload should The checksum of the IP datagram contained in the ICMP payload should
be checked to be valid. In case it is invalid, the ICMP error be checked to be valid. In case it is invalid, the ICMP error
message should be silently dropped. message should be silently dropped.
If a full IP datagram is contained in the ICMP payload, and the IP If a full IP datagram is contained in the ICMP payload, and the IP
datagram is authenticated [RFC2401], the signature should be datagram is authenticated [RFC4301], the signature should be
recalculated for that packet. If it doesn't match the one already recalculated for that packet. If it doesn't match the one already
included in the ICMP payload, the ICMP error message should be included in the ICMP payload, the ICMP error message should be
silently dropped. silently dropped.
If a full TCP segment is contained in the payload of the ICMP error If a full TCP segment is contained in the payload of the ICMP error
message, then the first check that should be performed is that the message, then the first check that should be performed is that the
TCP checksum is valid. Then, if a TCP MD5 option is present, the MD5 TCP checksum is valid. Then, if a TCP MD5 option is present, the MD5
signature should be recalculated for the encapsulated packet, and if signature should be recalculated for the encapsulated packet, and if
it doesn't match the one contained in the TCP MD5 option, the ICMP it doesn't match the one contained in the TCP MD5 option, the ICMP
error message should be silently dropped. error message should be silently dropped.
skipping to change at page 33, line 20 skipping to change at page 36, line 20
publication as an Informational RFC. publication as an Informational RFC.
o Added additional checks that should be performed on ICMP error o Added additional checks that should be performed on ICMP error
messages (checksum of the IP header in the ICMP payload, and messages (checksum of the IP header in the ICMP payload, and
others). others).
o Added clarification of the rationale behind each the TCP SEQ check o Added clarification of the rationale behind each the TCP SEQ check
o Miscellaneous editorial changes o Miscellaneous editorial changes
E.2. Changes from draft-gont-tcpm-icmp-attacks-04 E.2. Changes from draft-ietf-tcpm-icmp-attacks-00
o Added references to the specific sections of each of the
referenced specifications
o Corrected the threat analysys
o Added clarification about whether the counter-measures violate the
current specifications or not.
o Changed text so that the document fits better in the Informational
path
o Added an specific section on IPsec (Section 2.3)
o Added clarification and references on the use of ICMP filtering
based on the ICMP payload
o Updated references to obsoleted RFCs
o Added a discussion of multipath scenarios, and possible lose in
responsiveness resulting from the reaction to hard errors as soft
errors (in Section 5.2.3)
o Miscellaneous editorial changes
E.3. Changes from draft-gont-tcpm-icmp-attacks-04
o Added Appendix C o Added Appendix C
o Added reference to [I-D.iab-link-indications] o Added reference to [I-D.iab-link-indications]
o Added stress on the fact that ICMP error messages are unreliable o Added stress on the fact that ICMP error messages are unreliable
o Miscellaneous editorial changes o Miscellaneous editorial changes
E.3. Changes from draft-gont-tcpm-icmp-attacks-03 E.4. 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
E.4. Changes from draft-gont-tcpm-icmp-attacks-02 E.5. 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 D o Added Appendix D
o Miscellaneous editorial changes o Miscellaneous editorial changes
E.5. Changes from draft-gont-tcpm-icmp-attacks-01 E.6. 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 34, line 23 skipping to change at page 38, 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
E.6. Changes from draft-gont-tcpm-icmp-attacks-00 E.7. 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
Fernando Gont Fernando Gont
Universidad Tecnologica Nacional Universidad Tecnologica Nacional / Facultad Regional Haedo
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fernando@gont.com.ar Email: fernando@gont.com.ar
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 36, line 29 skipping to change at page 39, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 92 change blocks. 
288 lines changed or deleted 462 lines changed or added

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