draft-ietf-tcpm-icmp-attacks-02.txt   draft-ietf-tcpm-icmp-attacks-03.txt 
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UTN/FRH Extensions (tcpm) UTN/FRH
Intended status: Informational Intended status: Informational
Expires: November 5, 2007 Expires: September 15, 2008
ICMP attacks against TCP ICMP attacks against TCP
draft-ietf-tcpm-icmp-attacks-02.txt draft-ietf-tcpm-icmp-attacks-03.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 35 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 November 5, 2007. This Internet-Draft will expire on September 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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.
proposes several counter-measures to eliminate or minimize the impact Additionally, describes a number of widely implemented modifications
of these attacks. to TCP's handling of ICMP error messages that help to mitigate these
issues.
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
2.3. Handling of ICMP error messages in the context of IPSec . 7 2.3. Handling of ICMP error messages in the context of IPsec . 7
3. Constraints in the possible solutions . . . . . . . . . . . . 8 3. Constraints in the possible solutions . . . . . . . . . . . . 8
4. General counter-measures against ICMP attacks . . . . . . . . 9 4. General counter-measures against ICMP attacks . . . . . . . . 9
4.1. TCP sequence number checking . . . . . . . . . . . . . . . 9 4.1. TCP sequence number checking . . . . . . . . . . . . . . . 9
4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 10 4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 10
4.3. Filtering ICMP error messages based on the ICMP payload . 10 4.3. Filtering ICMP error messages based on the ICMP payload . 10
5. Blind connection-reset attack . . . . . . . . . . . . . . . . 11 5. Blind connection-reset attack . . . . . . . . . . . . . . . . 11
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Attack-specific counter-measures . . . . . . . . . . . . . 12 5.2. Attack-specific counter-measures . . . . . . . . . . . . . 12
5.2.1. Changing the reaction to hard errors . . . . . . . . . 12 6. Blind throughput-reduction attack . . . . . . . . . . . . . . 13
5.2.2. Delaying the connection-reset . . . . . . . . . . . . 15 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.3. Possible drawbacks of the described solutions . . . . 16 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . 15
7. Blind performance-degrading attack . . . . . . . . . . . . . . 17 7.3. The counter-measure for the PMTUD attack in action . . . . 19
7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 17 7.3.1. Normal operation for bulk transfers . . . . . . . . . 19
7.2. Attack-specific counter-measures . . . . . . . . . . . . . 19 7.3.2. Operation during Path-MTU changes . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7.3.3. Idle connection being attacked . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 7.3.4. Active connection being attacked after discovery
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 of the Path-MTU . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 7.3.5. TCP peer attacked when sending small packets just
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 after the three-way handshake . . . . . . . . . . . . 23
Appendix A. The counter-measure for the PMTUD attack in action . 26 7.4. Pseudo-code for the counter-measure for the blind
A.1. Normal operation for bulk transfers . . . . . . . . . . . 27 performance-degrading attack . . . . . . . . . . . . . . . 24
A.2. Operation during Path-MTU changes . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
A.3. Idle connection being attacked . . . . . . . . . . . . . . 29 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
A.4. Active connection being attacked after discovery of 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
the Path-MTU . . . . . . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
A.5. TCP peer attacked when sending small packets just 10.2. Informative References . . . . . . . . . . . . . . . . . . 29
after the three-way handshake . . . . . . . . . . . . . . 31 Appendix A. An analysis of ICMP hard errors . . . . . . . . . . . 32
Appendix B. Pseudo-code for the counter-measure for the blind Appendix B. Advice and guidance to vendors . . . . . . . . . . . 33
performance-degrading attack . . . . . . . . . . . . 32 Appendix C. Changes from previous versions of the draft (to
Appendix C. Additional considerations for the validation of
ICMP error messages . . . . . . . . . . . . . . . . . 35
Appendix D. Advice and guidance to vendors . . . . . . . . . . . 36
Appendix E. Changes from previous versions of the draft (to
be removed by the RFC Editor before publishing be removed by the RFC Editor before publishing
this document as an RFC) . . . . . . . . . . . . . . 36 this document as an RFC) . . . . . . . . . . . . . . 33
E.1. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 36 C.1. Changes from draft-ietf-tcpm-icmp-attacks-02 . . . . . . . 33
E.2. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 36 C.2. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 34
E.3. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 37 C.3. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 34
E.4. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 37 C.4. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 35
E.5. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 37 C.5. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 35
E.6. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 38 C.6. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 35
E.7. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 38 C.7. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 35
E.8. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 38 C.8. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 C.9. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 40 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 38
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 allowing variety of checks on the received ICMP error messages, thus allowing variety of
attacks against TCP [RFC0793] by means of ICMP, which include blind attacks against TCP [RFC0793] by means of ICMP, which include blind
connection-reset, blind throughput-reduction, and blind performance- connection-reset, blind throughput-reduction, and blind performance-
degrading attacks. All of these attacks can be performed even being degrading attacks. All of these attacks can be performed even being
off-path, without the need to sniff the packets that correspond to off-path, without the need to sniff the packets that correspond to
the attacked TCP connection. the attacked TCP connection.
While the possible security implications of ICMP have been known in While the possible security implications of ICMP have been known in
the research community for a long time, there has never been an the research community for a long time, there has never been an
official proposal on how to deal with these vulnerabiliies. Thus, official proposal on how to deal with these vulnerabiliies. In 2005,
only a few implementations have implemented validation checks on the a disclosure process was carried out by the UK's National
received ICMP error messages to minimize the impact of these attacks. Infrastructure Security Co-ordination Centre (NISCC) (now CPNI,
Centre for the Protection of National Infrastructure), with the
Recently, a disclosure process has been carried out by the UK's collaboration of other computer emergency response teams. A large
National Infrastructure Security Co-ordination Centre (NISCC), with number of implementations were found vulnerable to either all or a
the collaboration of other computer emergency response teams. A subset of the attacks discussed in this document [NISCC][US-CERT].
large number of implementations were found vulnerable to either all The affected systems ranged from TCP/IP implementations meant for
or a subset of the attacks discussed in this document desktop computers, to TCP/IP implementations meant for core Internet
[NISCC][US-CERT]. The affected systems ranged from TCP/IP routers.
implementations meant for desktop computers, to TCP/IP
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 [RFC4907].
This document aims to raise awareness of the use of ICMP to perform a This document aims to raise awareness of the use of ICMP to perform a
variety of attacks against TCP, and discusses several counter- variety of attacks against TCP, and discusses several counter-
measures that eliminate or minimize the impact of these attacks. measures that eliminate or minimize the impact of these attacks.
Most of the these counter-measures can be implemented while still Most of the these counter-measures can be implemented while still
remaining compliant with the current specifications, as they simply remaining compliant with the current specifications, as they simply
suggest reasons for not taking the advice provided in the suggest reasons for not taking the advice provided in the
specifications in terms of "SHOULDs", but still comply with the specifications in terms of "SHOULDs", but still comply with the
requirements stated as "MUSTs". Section 5.2, Section 6.2, and requirements stated as "MUSTs".
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 that can be
measures that can be implemented to mitigate any ICMP-based attack. implemented to mitigate any ICMP-based attack. Finally, Section 5,
Section 6, and Section 7, discuss a variety of ICMP attacks that can
Finally, Section 5, Section 6, and Section 7, discuss a variety of be performed against TCP, and propose attack-specific counter-
ICMP attacks that can be performed against TCP, and propose attack- measures that eliminate or greatly mitigate their impact.
specific counter-measures that eliminate or greatly mitigate their
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
2.1. The Internet Control Message Protocol (ICMP) 2.1. The Internet Control Message Protocol (ICMP)
The Internet Control Message Protocol (ICMP) is used in the Internet The Internet Control Message Protocol (ICMP) is used in the Internet
Architecture mainly to perform the fault-isolation function, that is, Architecture mainly to perform the fault-isolation function, that is,
the group of actions that hosts and routers take to determine that the group of actions that hosts and routers take to determine that
there is some network failure [RFC0816] there is some network failure [RFC0816].
When an intermediate router detects a network problem while trying to When an intermediate router detects a network problem while trying to
forward an IP packet, it will usually send an ICMP error message to forward an IP packet, it will usually send an ICMP error message to
the source system, to 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 handed 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.
skipping to change at page 7, line 4 skipping to change at page 6, line 46
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 system, and, as long as he is able to guess message to the attacked system, and, as long as he is able to guess
the four-tuple (i.e., Source IP Address, Source TCP port, Destination the four-tuple (i.e., Source IP Address, Source TCP port, Destination
IP Address, and Destination TCP port) that identifies the IP Address, and Destination TCP port) that identifies the
communication instance to be attacked, he will be able to use ICMP to communication instance to be attacked, he will be able to use ICMP to
perform a variety of attacks. perform a variety of attacks.
Generally, the four-tuple required to perform these attacks is not Generally, the four-tuple required to perform these attacks is not
known. However, as discussed in [Watson] and known. However, as discussed in [Watson] and [RFC4953], there are a
[I-D.ietf-tcpm-tcp-antispoof], there are a number of scenarios number of scenarios (notably that of TCP connections established
(notably that of TCP connections established between two BGP routers between two BGP routers [RFC4271]), in which an attacker may be able
[RFC4271]), in which an attacker may be able to know or guess the to know or guess the four-tuple that identifies a TCP connection. In
four-tuple that identifies a TCP connection. In such a case, if we such a case, if we assume the attacker knows the two systems involved
assume the attacker knows the two systems involved in the TCP in the TCP connection to be attacked, both the client-side and the
connection to be attacked, both the client-side and the server-side server-side IP addresses could be known or be within a reasonable
IP addresses could be known or be within a reasonable number of number of possibilities. Furthermore, as most Internet services use
possibilities. Furthermore, as most Internet services use the so- the so-called "well-known" ports, only the client port number might
called "well-known" ports, only the client port number might need to need to be guessed. In such a scenario, an attacker would need to
be guessed. In such a scenario, an attacker would need to send, in send, in principle, at most 65536 packets to perform any of the
principle, at most 65536 packets to perform any of the attacks attacks described in this document. These issues are exacerbated by
described in this document. However, as most systems choose the port the fact that most systems choose the port numbers they use for
numbers they use for outgoing connections from a subset of the whole outgoing connections from a subset of the whole port number space,
port number space, the amount of packets needed to successfully thus reducing the amount of work needed to successfully perform these
perform any of the attacks discussed in this document could be attacks.
further reduced.
It is clear that TCP should be more cautious when processing received The need to be more more cautious when processing received ICMP error
ICMP error messages, in order to mitigate or eliminate the impact of messages in order to mitigate or eliminate the impact of the attacks
the attacks described in this document [I-D.iab-link-indications]. described in this document has been documented by the Internet
Architecture Board (IAB) in [RFC4907].
2.3. Handling of ICMP error messages in the context of IPSec 2.3. Handling of ICMP error messages in the context of IPsec
Section 5.2 of [RFC4301] describes the processing inbound IP Traffic Section 5.2 of [RFC4301] describes the processing of inbound IP
in the case of "unprotected-to-protected". In the case of ICMP, when Traffic in the case of "unprotected-to-protected". In the case of
an unprotected ICMP error message is received, it is matched to the ICMP, when an unprotected ICMP error message is received, it is
corresponding security association by means of the SPI (Security matched to the corresponding security association by means of the SPI
Parameters Index) included in the payload of the ICMP error message. (Security Parameters Index) included in the payload of the ICMP error
Then, local policy is applied to determine whether to accept or message. Then, local policy is applied to determine whether to
reject the message and, if accepted, what action to take as a result. accept or reject the message and, if accepted, what action to take as
For example, if an ICMP unreachable message is received, the a result. For example, if an ICMP unreachable message is received,
implementation must decide whether to act on it, reject it, or act on the implementation must decide whether to act on it, reject it, or
it with constraints. Section 8 ("Path MTU/DF processing") discusses act on it with constraints. Section 8 ("Path MTU/DF processing")
the processing of unauthenticated ICMP "fragmentation needed and DF discusses the processing of unauthenticated ICMP "fragmentation
bit set" (type 3, code 3) and ICMPv6 "Packet Too Big" (type 2, code needed and DF bit set" (type 3, code 3) and ICMPv6 "Packet Too Big"
0) messages when an IPsec implementation receives is configured to (type 2, code 0) messages when an IPsec implementation is configured
process (vs. ignore) such messages. to process (vs. ignore) such messages.
Section 6.1.1 of [RFC4301] notes that processing of unauthenticated Section 6.1.1 of [RFC4301] notes that processing of unauthenticated
ICMP error messages may result in denial or degradation of service, ICMP error messages may result in denial or degradation of service,
and therefore it would be desirable to ignore such messages. and therefore it would be desirable to ignore such messages.
However, it also notes that in many cases ignoring these ICMP However, it also notes that in many cases ignoring these ICMP
messages can degrade service, e.g., because of a failure to process messages can degrade service, e.g., because of a failure to process
PMTU message and redirection messages, and therefore there is also a PMTUD and redirection messages, and therefore there is also a
motivation for accepting and acting upon them. It finally states motivation for accepting and acting upon them. It finally states
that to accommodate both ends of this spectrum, a compliant IPsec that to accommodate both ends of this spectrum, a compliant IPsec
implementation MUST permit a local administrator to configure an implementation MUST permit a local administrator to configure an
IPsec implementation to accept or reject unauthenticated ICMP IPsec implementation to accept or reject unauthenticated ICMP
traffic, and that this control MUST be at the granularity of ICMP traffic, and that this control MUST be at the granularity of ICMP
type and MAY be at the granularity of ICMP type and code. type and MAY be at the granularity of ICMP type and code.
Additionally, an implementation SHOULD incorporate mechanisms and Additionally, an implementation SHOULD incorporate mechanisms and
parameters for dealing with such traffic. parameters for dealing with such traffic.
Thus, the policy to apply for the processing of unprotected ICMP Thus, the policy to apply for the processing of unprotected ICMP
skipping to change at page 8, line 48 skipping to change at page 8, line 41
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 [RFC4301], because only a authenticating its packets at the IP layer [RFC4301], because only a
part of the original IP packet would be available, the signature used part of the original IP packet would be available, the signature used
for authentication could not be recalculated, and thus this mechanism for authentication could not be recalculated, and thus the
could not be used as a counter-measure aganist ICMP-based attacks authentication header in the original packet could not be used as a
against TCP. counter-measure for ICMP-based attacks against TCP.
For IPv6, the payload of ICMPv6 error messages includes as many For IPv6, the payload of ICMPv6 error messages includes as many
octets from the IPv6 packet that elicited the ICMPv6 error message as octets from the IPv6 packet that elicited the ICMPv6 error message as
will fit without making the resulting ICMPv6 packet exceed the will fit without making the resulting ICMPv6 error message exceed the
minimum IPv6 MTU (1280 octets) [RFC4443]. 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
[RFC4301], in order to act upon them. However, while this [RFC4301], in order to act upon them. However, while this
requirement could make sense for those ICMP error messages sent by requirement could make sense for those ICMP error messages sent by
hosts, it would not be feasible for those ICMP error messages hosts, it would not be feasible for those ICMP error messages
generated by routers, as this would imply either that the attacked generated by routers, as this would imply either that the attacked
system should have a security association [RFC4301] with every system should have a security association [RFC4301] with every
existing intermediate system, or that it should be able to establish existing intermediate system, or that it should be able to establish
one dynamically. Current levels of protocol deployment for dynamic one dynamically. Current levels of deployment of protocols for
establishment of security associations makes this unfeasible. Also, dynamic establishment of security associations makes this unfeasible.
there may be some cases, such as embedded devices, in which the Also, there may be some scenarios, such as embedded devices, in which
processing power requirements of authentication could not allow IPSec the processing power requirements of authentication might not allow
authentication to be implemented effectively. IPSec authentication to be implemented effectively.
Additional considerations for the validation of ICMP error messages
can be found in Appendix C
4. General counter-measures against ICMP attacks 4. General counter-measures against ICMP attacks
There are a number of counter-measures that can be implemented to The following subsections describe a number of mitigation techniques
eliminate or mitigate the impact of the attacks discussed in this that help to eliminate or mitigate the impact of the attacks
document. Rather than being alternative counter-measures, they can discussed in this document. Rather than being alternative counter-
be implemented together to increase the protection against these measures, they can be implemented together to increase the protection
attacks. In particular, all TCP implementations should perform the against these attacks.
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 the 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 Many TCP implementations have incorporated a validation check so
makes TCP react only to those ICMP error messages elicited by
segments that were "in-flight" to the destination system. These
implementations 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 they require that the sequence
within the range of the data already sent but not yet acknowledged. number be within the range of the data already sent but not yet
If an ICMP error message does not pass this check, it should be acknowledged. If an ICMP error message does not pass this check, it
discarded. is discarded.
Even if an attacker were able to guess the four-tuple that identifies Even if an attacker were able to guess the four-tuple that identifies
the TCP connection, this additional check would reduce the the TCP connection, this additional check would reduce the
possibility of considering a spoofed ICMP packet as valid to possibility of considering a spoofed ICMP packet as valid to
Flight_Size/2^^32 (where Flight_Size is the number of data bytes Flight_Size/2^^32 (where Flight_Size is the number of data bytes
already sent to the remote peer, but not yet acknowledged [RFC2581]). already sent to the remote peer, but not yet acknowledged [RFC2581]).
For connections in the SYN-SENT or SYN-RECEIVED states, this would For connections in the SYN-SENT or SYN-RECEIVED states, this would
reduce the possibility of considering a spoofed ICMP packet as valid reduce the possibility of considering a spoofed ICMP packet as valid
to 1/2^^32. For a TCP endpoint with no data "in flight", this would to 1/2^^32. For a TCP endpoint with no data "in flight", this would
completely eliminate the possibility of success of these attacks. completely eliminate the possibility of success of these attacks.
This validation check has been implemented in Linux [Linux] for many This validation check has been implemented in Linux [Linux] for many
years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and
NetBSD [NetBSD] since 2005. NetBSD [NetBSD] since 2005.
It is important to note that while this check greatly increases the It is important to note that while this check greatly increases the
number of packets required to perform any of the attacks discussed in number of packets required to perform any of the attacks discussed in
this document, this may not be enough in those scenarios in which this document, this may not be enough in those scenarios in which
bandwidth is easily available, and/or large TCP windows [RFC1323] are bandwidth is easily available, and/or large TCP windows [RFC1323] are
in use. Therefore, implementation of the attack-specific counter- in use. Additionally, this validation check does not help to prevent
measures discussed in this document is strongly recommended. on-path attacks, that is, attacks performed in scenarios in which the
attacker can sniff the packets that correspond to the target TCP
A TCP that implements the TCP sequence number checking as the only connection.
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
[I-D.ietf-tcpm-tcp-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.ietf-tsvwg-port-randomization] discusses a number of algorithms
algorithms to randomize the ephemeral ports used by clients. 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 middlebox devices advanced packet filtering can be implemented in middlebox devices
such as firewalls and NATs as a counter-measure. Middleboxes such as firewalls and NATs. Middleboxes implementing such advanced
implementing such advanced filtering would look at the payload of the filtering look at the payload of the ICMP error messages, and perform
ICMP error messages, and would perform ingress and egress packet ingress and egress packet filtering based on the source IP address of
filtering based on the source IP address of the IP header contained the IP header contained in the payload of the ICMP error message. As
in the payload of the ICMP error message. As the source IP address the source IP address contained in the payload of the ICMP error
contained in the payload of the ICMP error message does need to be message does need to be spoofed to perform the attacks described in
spoofed to perform the attacks described in this document, this kind this document, this kind of advanced filtering serves as a counter-
of advanced filtering would serve as a counter-measure against these measure against these attacks. As with traditional egress filtering
attacks. As with traditional egress filtering [IP-filtering], egress [IP-filtering], egress filtering based on the ICMP payload can help
filtering based on the ICMP payload can help to prevent users of the to prevent users of the network being protected by the firewall from
network being protected by the firewall from successfully performing successfully performing ICMP attacks against TCP connections
ICMP attacks against TCP connections established between external established between external systems. Additionally, ingress
systems. Additionally, ingress filtering based on the ICMP payload filtering based on the ICMP payload can prevent TCP connections
can prevent TCP connections established between internal systems from established between internal systems from attacks performed by
attacks performed by external systems. [ICMP-Filtering] provides external systems. [ICMP-Filtering] provides examples of ICMP
examples of ICMP filtering based on the ICMP payload. filtering based on the ICMP payload.
This filtering has been implemented in OpenBSD's Packet Filter This filtering technique has been implemented in OpenBSD's Packet
[OpenBSD-PF], which has in turn been ported to a number of systems, Filter [OpenBSD-PF], which has in turn been ported to a number of
including FreeBSD [FreeBSD]. systems, including FreeBSD [FreeBSD].
5. Blind connection-reset attack 5. Blind connection-reset attack
5.1. Description 5.1. Description
When TCP is handed an ICMP error message, it will perform its fault When TCP is handed an ICMP error message, it will perform its fault
recovery function, as follows: recovery function, as follows:
o If the network problem being reported is a hard error, TCP will o If the network problem being reported is a hard error, TCP will
abort the corresponding connection. abort the corresponding connection.
skipping to change at page 12, line 28 skipping to change at page 12, line 17
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 [RFC4301], 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 This section describes a modification to TCP's reaction to ICMP hard
TCP SHOULD abort the corresponding connection in response to ICMP errors that has been incorporated in a large number of TCP
messages of type 3, codes 2 (protocol unreachable), 3 (port implementations. An analysis of each of the different ICMP "hard
unreachable), and 4 (fragmentation needed and DF bit set). However, error" messages is included in Appendix A.
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
An analysis of the circumstances in which ICMP messages that indicate
hard errors may be received can shed some light to eliminate the
impact of ICMP-based blind connection-reset attacks.
ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable)
This ICMP error message indicates that the host sending the ICMP
error message received a packet meant for a transport protocol it
does not support. For connection-oriented protocols such as TCP,
one could expect to receive such an error as the result of a
connection-establishment attempt. However, it would be strange to
get such an error during the life of a connection, as this would
indicate that support for that transport protocol has been removed
from the system sending the error message during the life of the
corresponding connection. Thus, it would be fair to treat ICMP
protocol unreachable error messages as soft errors if they are
meant for connections that are in synchronized states. For TCP,
this means TCP would treat ICMP protocol unreachable error
messages as soft errors if they are meant for connections that are
in any of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-
WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT).
ICMP type 3 (Destination Unreachable), code 3 (port unreachable)
This error message indicates that the system sending the ICMP
error message received a packet meant for a socket (IP address,
port number) on which there is no process listening. Those
transport protocols which have their own mechanisms for notifying
this condition should not be receiving these error messages, as
the protocol would signal the port unreachable condition by means
of its own messages. Assuming that once a connection is
established it is not usual for the transport protocol to change
(or be reloaded), it would be fair to treat ICMP port unreachable
messages as soft errors when they are meant for a TCP that is in
any of the synchronized states (ESTABLISHED, FIN-WAIT-1,
FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT).
ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed
and DF bit set)
This error message indicates that an intermediate node needed to
fragment a datagram, but the DF (Don't Fragment) bit in the IP
header was set. It is considered a soft error when TCP implements
PMTUD, and a hard error if TCP does not implement PMTUD. Those
systems that do not implement the PMTUD mechanism should not be
sending their IP packets with the DF bit set, and thus should not
be receiving these ICMP error messages. Thus, it would be fair
for TCPs in any of the synchronized states to treat this ICMP
error message as indicating a soft error, therefore not aborting
the corresponding connection when such an error message is
received. For obvious reasons, those systems implementing the
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
destination administratively prohibited)
This error message indicates that the destination is unreachable
because of an administrative policy. For connection-oriented
protocols such as TCP, one could expect to receive such an error
as the result of a connection-establishment attempt. Receiving
such an error for a connection in any of the synchronized states
would mean that the administrative policy changed during the life
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
would be fair, for security reasons, to treat these messages as
soft errors when they are meant for connections that are in any of
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)
This error message is analogous to the ICMP type 3 (Destination
Unreachable), code 3 (Port unreachable) error message discussed
above. Therefore, the same considerations apply.
Therefore, when following the reasoning explained above, TCPs in
synchronized states would treat all of the above messages as
indicating "soft errors", rather than "hard errors", and thus would
not abort the corresponding connection upon receipt of them. This is
policy is based on the premise that TCP should be as robust as
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
error condition appeared during the life of the corresponding
connection. However, in many scenarios 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, treating the received ICMP error
messages as "soft errors" would make TCP more robust, and could avoid
TCP from aborting a TCP connection unnecesarily. Aborting the
connection would be to ignore the valuable feature of the Internet
that for many internal failures it reconstructs its function without
any disruption of the end points [RFC0816].
One scenario in which a host would benefit from treating the so- TCPs implementing this modification treat all ICMP "hard errors"
called ICMP "hard errors" as "soft errors" would be that in which the received for connections in any of the synchronized states
packets that correspond to a given TCP connection are routed along (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK
multiple different paths. Some (but not all) of these paths may be or TIME-WAIT)as "soft errors". Therefore, they do not abort the
experiencing an error condition, and therefore generating the so- corresponding connection upon receipt of them. Additionally, they do
called ICMP hard errors. However, communication should survive if not extrapolate ICMP errors across TCP connections. This policy is
there is still a working path to the destination system [DClark]. based on the premise that TCP should be as robust as possible.
Thus, treating the so-called "hard errors" as "soft errors" when a Aborting the connection would be to ignore the valuable feature of
connection is in any of the synchronized states would make TCP the Internet that for many internal failures it reconstructs its
achieve this goal. function without any disruption of the end points [RFC0816].
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 error
error messages, and thus may still abort their connections on their contition, and thus may still abort their connections on their own if
own if they consider it appropriate. they consider it appropriate.
This counter-measure has been implemented in BSD-derived TCP/IP
implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more
than ten years [Wright][McKusick]. The Linux kernel has also
implemented this policy for more than ten years [Linux].
5.2.2. Delaying the connection-reset
An alternative counter-measure would be, in the case of connections
in any of the synchronized states, to honor the ICMP error messages
only if there is no progress on the connection. Rather than
immediately aborting a connection, a TCP would abort a connection
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
forward progress on a connection, it can completely disregard the
"hard errors" being indicated by the received ICMP error messages.
While this counter-measure could be useful, we think that the
counter-measure discussed in Section 5.2.1 is easier to implement,
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 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 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 PMTUD, or the TCP at one of the endpoints of the connection is
dynamically disabled, TCP would only abort the connection after a dynamically disabled, TCP would only abort the connection after a
USER TIMEOUT [RFC0793], losing responsiveness. However, we consider USER TIMEOUT [RFC0793], losing responsiveness. However, these
these senarios very unlikely in production environments, and consider scenarios are very unlikely in production environments, and it is
that it is preferebable to potentially lose responsiveness for the probably preferebable to potentially lose responsiveness for the sake
sake of robustness. It should also be noted that applications may of robustness. It should also be noted that applications may still
still be notified asynchronously about the received error messages, be notified asynchronously about the error condition, and thus may
and thus may still abort their connections on their own if they still abort their connections on their own if they consider it
consider it appropriate. appropriate.
In scenarios of multipath routing or route changes, failures in some In scenarios of multipath routing or route changes, failures in some
(but not all) of the paths may elicit ICMP error messages that would (but not all) of the paths may elicit ICMP error messages that would
likely not cause a connection abort if any of the counter-measures likely not cause a connection abort if any of the counter-measures
described in this section were implemented. However, as explained described in this section were implemented. However, aborting the
above, aborting the connection would be to ignore the valuable connection would be to ignore the valuable feature of the Internet
feature of the Internet that for many internal failures it that for many internal failures it reconstructs its function without
reconstructs its function without any disruption of the end points any disruption of the end points [RFC0816]. That is, communication
[RFC0816]. Additionally, applications may still be notified should survive if there is still a working path to the destination
asynchronously about the received error messages, and thus may still system [DClark]. Additionally, applications may still be notified
abort their connections on their own if they consider it appropriate. asynchronously about the error condition, and thus may still abort
their connections on their own if they consider it appropriate.
This counter-measure has been implemented in BSD-derived TCP/IP
implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more
than ten years [Wright][McKusick]. The Linux kernel has also
implemented this policy for more than ten years [Linux].
6. Blind throughput-reduction attack 6. Blind throughput-reduction attack
6.1. Description 6.1. Description
The Host requirements RFC [RFC1122] states 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. Thus, an attacker could send ICMP Source Quench (type 4, transmission on the connection. Thus, an attacker could send ICMP
code 0) messages to a TCP endpoint to make it reduce the rate at Source Quench (type 4, code 0) messages to a TCP endpoint to make it
which it sends data to the other end-point of the connection. reduce the rate at which it sends data to the other end-point of the
[RFC1122] further adds that the RECOMMENDED procedure is to put the connection. [RFC1122] further adds that the RECOMMENDED procedure is
corresponding connection in the slow-start phase of TCP's congestion to put the corresponding connection in the slow-start phase of TCP's
control algorithm [RFC2581]. In the case of those implementations congestion control algorithm [RFC2581]. In the case of those
that use an initial congestion window of one segment, a sustained implementations that use an initial congestion window of one segment,
attack would reduce the throughput of the attacked connection to a sustained attack would reduce the throughput of the attacked
about SMSS (Sender Maximum Segment Size) [RFC2581] bytes per RTT connection to about SMSS (Sender Maximum Segment Size) [RFC2581]
(round-trip time). The throughput achieved during attack might be a bytes per RTT (round-trip time). The throughput achieved during an
little higher if a larger initial congestion window is in use attack might be a little higher if a larger initial congestion window
[RFC3390]. is in use [RFC3390].
6.2. Attack-specific counter-measures 6.2. Attack-specific counter-measures
The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that As discussed in the Requirements for IP Version 4 Routers RFC
hosts MUST react to ICMP Source Quench messages by slowing [RFC1812], research seems to suggest that ICMP Source Quench is an
transmission on the connection. Therefore, the only counter-measures ineffective (and unfair) antidote for congestion. [RFC1812] further
for this attack that can be implemented while still remaining states that routers SHOULD NOT send ICMP Source Quench messages in
compliant with the existing specifications are the ones discussed in response to congestion. On the other hand, TCP implements its own
Section 4. congestion control mechanisms [RFC2581] [RFC3168], that do not depend
on ICMP Source Quench messages.
Nevertheless, it must be noted that, as discussed in the Requirements
for IP Version 4 Routers RFC [RFC1812], research seems to suggest
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 Based on this reasoning, a large number of implementations completely
ignore ICMP Source Quench messages meant for TCP connections. This ignore ICMP Source Quench messages meant for TCP connections. This
behavior has been implemented in, at least, Linux [Linux] since 2004, behavior has been implemented in, at least, Linux [Linux] since 2004,
and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD]
since 2005. However, as explained earlier in this section, this since 2005. However, it must be noted that this behaviour violates
behaviour violates the requirement in [RFC1122] to react to ICMP the requirement in [RFC1122] to react to ICMP Source Quench messages
Source Quench messages by slowing transmission on the connection. by slowing transmission on the connection.
7. Blind performance-degrading attack 7. Blind performance-degrading attack
7.1. Description 7.1. Description
When one IP system has a large amount of data to send to another When one IP system has a large amount of data to send to another
system, the data will be transmitted as a series of IP datagrams. It system, the data will be transmitted as a series of IP datagrams. It
is usually preferable that these datagrams be of the largest size is usually preferable that these datagrams be of the largest size
that does not require fragmentation anywhere along the path from the that does not require fragmentation anywhere along the path from the
source to the destination. This datagram size is referred to as the source to the destination. This datagram size is referred to as the
skipping to change at page 18, line 32 skipping to change at page 15, line 14
advertising a small Next-Hop MTU. As a result, the attacked system advertising a small Next-Hop MTU. As a result, the attacked system
would reduce the size of the packets it sends for the corresponding would reduce the size of the packets it sends for the corresponding
connection accordingly. connection accordingly.
The effect of this attack is two-fold. On one hand, it will increase The effect of this attack is two-fold. On one hand, it will increase
the headers/data ratio, thus increasing the overhead needed to send the headers/data ratio, thus increasing the overhead needed to send
data to the remote TCP end-point. On the other hand, if the attacked data to the remote TCP 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 and protocol processing time, thus
degrading the overall system performance. increasing processor utilization, and 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 system 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
skipping to change at page 19, line 24 skipping to change at page 16, line 7
blind performance-degrading attack described in Section 7.1. The blind performance-degrading attack described in Section 7.1. The
described mechanism basically disregards ICMP messages when a described mechanism basically disregards ICMP messages when a
connection makes progress. This modification does not violate any of connection makes progress. This modification does not violate any of
the requirements stated in [RFC1191] and [RFC1981]. 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 these implementations include a modification to TCP's reaction to
implemented to greatly minimize the impact of this attack. ICMP "Packet Too Big" error messages that disregards them when a
connection makes progress, and honors them only after the
This would mean that upon receipt of an ICMP "Packet Too Big" error corresponding data have been retransmitted a specified number of
message, TCP would just record this information, and would honor it times. This means that upon receipt of an ICMP "Packet Too Big"
only when the corresponding data had already been retransmitted a error message, TCP just records this information, and honors it only
when the corresponding data have already been retransmitted a
specified number of times. specified number of times.
While this policy would greatly mitigate the impact of the attack While this basic policy would greatly mitigate the impact of the
against the PMTUD mechanism, it would also mean that it might take attack against the PMTUD mechanism, it would also mean that it might
TCP more time to discover the Path-MTU for a TCP connection. This take TCP more time to discover the Path-MTU for a TCP connection.
would be particularly annoying for connections that have just been This would be particularly annoying for connections that have just
established, as it might take TCP several transmission attempts (and been established, as it might take TCP several transmission attempts
the corresponding timeouts) before it discovers the PMTU for the (and the corresponding timeouts) before it discovers the PMTU for the
corresponding connection. Thus, this policy would increase the time corresponding connection. Thus, this policy would increase the time
it takes for data to begin to be received at the destination host. it takes for data to begin to be received at the destination host.
We would like to protect TCP from the attack against the PMTUD In order to protect TCP from the attack against the PMTUD mechanism,
mechanism, while still allowing TCP to quickly determine the initial while still allowing TCP to quickly determine the initial Path-MTU
Path-MTU for a connection. for a connection, the aforementioned implementations have divided the
traditional PMTUD mechanism into two stages: Initial Path-MTU
To achieve both goals, we can divide the traditional PMTUD mechanism Discovery, and Path-MTU Update.
into two stages: Initial Path-MTU Discovery, and Path-MTU Update.
The Initial Path-MTU Discovery stage is when TCP tries to send The Initial Path-MTU Discovery stage is when TCP tries to send
segments that are larger than the ones that have so far been sent and segments that are larger than the ones that have so far been sent and
acknowledged for this connection. That is, in the Initial Path-MTU acknowledged for this connection. That is, in the Initial Path-MTU
Discovery stage TCP has no record of these large segments getting to Discovery stage TCP has no record of these large segments getting to
the destination host, and thus it would be fair to believe the the destination host, and thus these implementations believe the
network when it reports that these packets are too large to reach the network when it reports that these packets are too large to reach the
destination host without being fragmented. destination host without being fragmented.
The Path-MTU Update stage is when TCP tries to send segments that are The Path-MTU Update stage is when TCP tries to send segments that are
equal to or smaller than the ones that have already been sent and equal to or smaller than the ones that have already been sent and
acknowledged for this connection. During the Path-MTU Update stage, acknowledged for this connection. During the Path-MTU Update stage,
TCP already has knowledge of the estimated Path-MTU for the given TCP already has knowledge of the estimated Path-MTU for the given
connection. Thus, it would be fair to be more cautious with the connection. Thus, in this case these implementations are more
errors being reported by the network. cautious with the errors being reported by the network.
In order to allow TCP to distinguish segments between those In order to allow TCP to distinguish segments between those
performing Initial Path-MTU Discovery and those performing Path-MTU performing Initial Path-MTU Discovery and those performing Path-MTU
Update, two new variables should be introduced to TCP: maxsizeacked Update, two new variables are introduced to TCP: maxsizeacked and
and maxsizesent. maxsizesent.
maxsizesent would hold the size (in octets) of the largest packet maxsizesent holds the size (in octets) of the largest packet that has
that has so far been sent for this connection. It would be so far been sent for this connection. It is initialized to 68 (the
initialized to 68 (the minimum IPv4 MTU) when the underlying internet minimum IPv4 MTU) when the underlying internet protocol is IPv4, and
protocol is IPv4, and would be initialized to 1280 (the minimum IPv6 is initialized to 1280 (the minimum IPv6 MTU) when the underlying
MTU) when the underlying internet protocol is IPv6. Whenever a internet protocol is IPv6. Whenever a packet larger than maxsizesent
packet larger than maxsizesent octets is sent, maxsizesent should be octets is sent, maxsizesent is set to that value.
set to that value.
On the other hand, maxsizeacked would hold the size (in octets) of On the other hand, maxsizeacked holds the size (in octets) of the
the largest packet that has so far been acknowledged for this largest packet that has so far been acknowledged for this connection.
connection. It would be initialized to 68 (the minimum IPv4 MTU) It is initialized to 68 (the minimum IPv4 MTU) when the underlying
when the underlying internet protocol is IPv4, and would be internet protocol is IPv4, and is initialized to 1280 (the minimum
initialized to 1280 (the minimum IPv6 MTU) when the underlying IPv6 MTU) when the underlying internet protocol is IPv6. Whenever an
internet protocol is IPv6. Whenever an acknowledgement for a packet acknowledgement for a packet larger than maxsizeacked octets is
larger than maxsizeacked octets is received, maxsizeacked should be received, maxsizeacked is set to the size of that acknowledged
set to the size of that acknowledged packet. packet.
Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop
MTU claimed by the ICMP message (henceforth "claimedmtu") should be MTU claimed by the ICMP message (henceforth "claimedmtu") is compared
compared with maxsizesent. If claimedmtu is equal to or larger than with maxsizesent. If claimedmtu is equal to or larger than
maxsizesent, then the ICMP error message should be silently maxsizesent, then the ICMP error message is silently discarded. The
discarded. The rationale for this is that the ICMP error message rationale for this is that the ICMP error message cannot be
cannot be legitimate if it claims to have been elicited by a packet legitimate if it claims to have been elicited by a packet larger than
larger than the largest packet we have so far sent for this the largest packet we have so far sent for this connection.
connection.
If this check is passed, claimedmtu should be compared with
maxsizeacked. If claimedmtu is equal to or larger than maxsizeacked,
TCP is supposed to be at the Initial Path-MTU Discovery stage, and
thus the ICMP "Packet Too Big" error message should be honored
immediately. That is, the assumed Path-MTU should be updated
according to the Next-Hop MTU claimed in the ICMP error message.
Also, maxsizesent should be reset to the minimum MTU of the internet If this check is passed, claimedmtu is compared with maxsizeacked.
protocol in use (68 for IPv4, and 1280 for IPv6). If claimedmtu is equal to or larger than maxsizeacked, TCP is
supposed to be at the Initial Path-MTU Discovery stage, and thus the
ICMP "Packet Too Big" error message is honored immediately. That is,
the assumed Path-MTU is updated according to the Next-Hop MTU claimed
in the ICMP error message. Also, maxsizesent is reset to the minimum
MTU of the internet protocol in use (68 for IPv4, and 1280 for IPv6).
On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is
supposed to be in the Path-MTU Update stage. At this stage, we supposed to be in the Path-MTU Update stage. At this stage, these
should be more cautious with the errors being reported by the implementations are more cautious with the errors being reported by
network, and should therefore just record the received error message, the network, and therefore just record the received error message,
and delay the update of the assumed Path-MTU. and delay the update of the assumed Path-MTU.
To perform this delay, one new variable and one new parameter should To perform this delay, one new variable and one new parameter is
be introduced to TCP: nsegrto and MAXSEGRTO. nsegrto will hold the introduced to TCP: nsegrto and MAXSEGRTO. nsegrto holds the number of
number of times a specified segment has timed out. It should be times a specified segment has timed out. It is initialized to zero,
initialized to zero, and should be incremented by one everytime the and is incremented by one every time the corresponding segment times
corresponding segment times out. MAXSEGRRTO should specify the out. MAXSEGRRTO specifies the number of times a given segment must
number of times a given segment must timeout before an ICMP "Packet timeout before an ICMP "Packet Too Big" error message can be honored,
Too Big" error message can be honored, and can be set, in principle, and can be set, in principle, to any value greater than or equal to
to any value greater than or equal to 0. 0.
Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a
pending ICMP "Packet Too Big" error message, the correspoing error pending ICMP "Packet Too Big" error message, the corresponding error
message should be processed. At that point, maxsizeacked should be message is processed. At that point, maxsizeacked is set to
set to claimedmtu, and maxsizesent should be set to 68 (for IPv4) or claimedmtu, and maxsizesent is set to 68 (for IPv4) or 1280 (for
1280 (for IPv6). IPv6).
If while there is a pending ICMP "Packet Too Big" error message the If while there is a pending ICMP "Packet Too Big" error message the
TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK
that acknowledges that sequence number is received), then the that acknowledges that sequence number is received), then the
"pending error" condition should be cleared. "pending error" condition is cleared.
The rationale behind performing this delayed processing of ICMP The rationale behind performing this delayed processing of ICMP
"Packet Too Big" messages is that if there is progress on the "Packet Too Big" messages is that if there is progress on the
connection, the ICMP "Packet Too Big" errors must be a false claim. connection, the ICMP "Packet Too Big" errors must be a false claim.
By checking for progress on the connection, rather than just for By checking for progress on the connection, rather than just for
staleness of the received ICMP messages, TCP is protected from attack staleness of the received ICMP messages, TCP is protected from attack
even if the offending ICMP messages are "in window", and as a even if the offending ICMP messages are "in window", and as a
corollary, is made more robust to spurious ICMP messages elicited by, corollary, is made more robust to spurious ICMP messages elicited by,
for example, corrupted TCP segments. for example, corrupted TCP segments.
MAXSEGRTO can be set, in principle, to any value greater than or MAXSEGRTO can be set, in principle, to any value greater than or
equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the
traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A
MAXSEGRTO of 1 should provide enough protection for most cases. In MAXSEGRTO of 1 provides enough protection for most cases. In any
any case, implementations are free to choose higher values for this case, implementations are free to choose higher values for this
constant. MAXSEGRTO could be a function of the Next-Hop MTU claimed constant. MAXSEGRTO could be a function of the Next-Hop MTU claimed
in the received ICMP "Packet Too Big" message. That is, higher in the received ICMP "Packet Too Big" message. That is, higher
values for MAXSEGRTO could be imposed when the received ICMP "Packet values for MAXSEGRTO could be imposed when the received ICMP "Packet
Too Big" message claims a Next-Hop MTU that is smaller than some Too Big" message claims a Next-Hop MTU that is smaller than some
specified value. specified value.
In the event a higher level of protection is desired at the expense In the event a higher level of protection is desired at the expense
of a higher delay in the discovery of the Path-MTU, an implementation of a higher delay in the discovery of the Path-MTU, an implementation
could consider TCP to always be in the Path-MTU Update stage, thus could consider TCP to always be in the Path-MTU Update stage, thus
always delaying the update of the assumed Path-MTU. always delaying the update of the assumed Path-MTU.
Appendix A shows the proposed counter-measure in action. Appendix B Section 7.3 shows the proposed counter-measure in action.
shows the proposed counter-measure in pseudo-code. Section 7.4 shows the proposed counter-measure in pseudo-code.
This behavior has been implemented in NetBSD [NetBSD] and OpenBSD This behavior has been implemented in NetBSD [NetBSD] and OpenBSD
[OpenBSD] since 2005. [OpenBSD] since 2005.
It is important to note that the mechanism proposed in this section It is important to note that the mechanism proposed in this section
is an improvement to the current Path-MTU discovery mechanism, to is an improvement to the current Path-MTU discovery mechanism, to
mitigate its security implications. The current PMTUD mechanism, as mitigate its security implications. The current PMTUD mechanism, as
specified by [RFC1191] and [RFC1981], still suffers from some specified by [RFC1191] and [RFC1981], still suffers from some
functionality problems [RFC2923] that this document does not aim to functionality problems [RFC2923] that this document does not aim to
address. A mechanism that addresses those issues is described in address. A mechanism that addresses those issues is described in
[I-D.ietf-pmtud-method]. [RFC4821].
8. Security Considerations
This document describes the use of ICMP error messages to perform a
number of attacks against the TCP protocol, and proposes a number of
counter-measures that either eliminate or reduce the impact of these
attacks.
9. Acknowledgements
This document was inspired by Mika Liljeberg, while discussing some
issues related to [I-D.ietf-tcpm-tcp-soft-errors] by private e-mail.
The author would like to thank Bora Akyol, Mark Allman, Ran Atkinson,
James Carlson, Alan Cox, Theo de Raadt, Ted Faber, Juan Fraschini,
Markus Friedl, Guillermo Gont, John Heffner, Vivek Kakkar, Michael
Kerrisk, Mika Liljeberg, Matt Mathis, David Miller, Miles Nordin,
Eloy Paris, Kacheong Poon, Andrew Powell, Pekka Savola, Pyda
Srisuresh, Fred Templin, Joe Touch, and Andres Trapanotto, for
contributing many valuable comments.
Juan Fraschini and the author of this document implemented freely-
available audit tools to help vendors audit their systems by
reproducing the attacks discussed in this document.
Markus Friedl, Chad Loder, and the author of this document, produced
and tested in OpenBSD [OpenBSD] the first implementation of the
counter-measure described in Section 7.2. This first implementation
helped to test the effectiveness of the ideas introduced in this
document, and has served as a reference implementation for other
operating systems.
The author would like to thank the UK's National Infrastructure
Security Co-ordination Centre (NISCC) for coordinating the disclosure
of these issues with a large number of vendors and CSIRTs (Computer
Security Incident Response Teams).
The author wishes to express deep and heartfelt gratitude to Jorge
Oscar Gont and Nelida Garcia, for their precious motivation and
guidance.
10. References
10.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
10.2. Informative References
[DClark] Clark, D., "The Design Philosophy of the DARPA Internet
Protocols", Computer Communication Review Vol. 18, No. 4,
1988.
[FreeBSD] The FreeBSD Project, "http://www.freebsd.org".
[I-D.iab-link-indications]
Aboba, B., "Architectural Implications of Link
Indications", draft-iab-link-indications-10 (work in
progress), March 2007.
[I-D.ietf-pmtud-method]
Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", draft-ietf-pmtud-method-11 (work in progress),
December 2006.
[I-D.ietf-tcpm-tcp-antispoof]
Touch, J., "Defending TCP Against Spoofing Attacks",
draft-ietf-tcpm-tcp-antispoof-06 (work in progress),
February 2007.
[I-D.ietf-tcpm-tcp-soft-errors]
Gont, F., "TCP's Reaction to Soft Errors",
draft-ietf-tcpm-tcp-soft-errors-05 (work in progress),
April 2007.
[I-D.ietf-tcpm-tcpsecure]
Ramaiah, A., "Improving TCP's Robustness to Blind In-
Window Attacks", draft-ietf-tcpm-tcpsecure-07 (work in
progress), February 2007.
[I-D.larsen-tsvwg-port-randomisation]
Larsen, M., "Port Randomisation",
draft-larsen-tsvwg-port-randomisation-00 (work in
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".
[McKusick]
McKusick, M., Bostic, K., Karels, M., and J. Quarterman,
"The Design and Implementation of the 4.4BSD Operating
System", Addison-Wesley , 1996.
[NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP:
Vulnerability Issues in ICMP packets with TCP payloads",
http://www.niscc.gov.uk/niscc/docs/
al-20050412-00308.html?lang=en, 2005.
[NetBSD] The NetBSD Project, "http://www.netbsd.org".
[OpenBSD] The OpenBSD Project, "http://www.openbsd.org".
[OpenBSD-PF]
The OpenBSD Packet Filter,
"http://www.openbsd.org/faq/pf/".
[RFC0816] Clark, D., "Fault isolation and recovery", RFC 816,
July 1982.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, September 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP
Implementations do not adequately validate ICMP error
messages", http://www.kb.cert.org/vuls/id/222750, 2005.
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks",
2004 CanSecWest Conference , 2004.
[Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
The Implementation", Addison-Wesley , 1994.
Appendix A. The counter-measure for the PMTUD attack in action 7.3. The counter-measure for the PMTUD attack in action
This appendix shows the proposed counter-measure for the ICMP attack This SECTION shows the proposed counter-measure for the ICMP attack
against the PMTUD mechanism in action. It shows both how the fix against the PMTUD mechanism in action. It shows both how the fix
protects TCP from being attacked and how the counter-measure works in protects TCP from being attacked and how the counter-measure works in
normal scenarios. As discussed in Section 7.2, this Appendix assumes normal scenarios. As discussed in Section 7.2, this section assumes
the PMTUD-specific counter-measure is implemented in addition to the the PMTUD-specific counter-measure is implemented in addition to the
TCP sequence number checking described in Section 4.1. TCP sequence number checking described in Section 4.1.
Figure 1 illustrates an hypothetical scenario in which two hosts are Figure 1 illustrates an hypothetical scenario in which two hosts are
connected by means of three intermediate routers. It also shows the connected by means of three intermediate routers. It also shows the
MTU of each hypothetical hop. All the following subsections assume MTU of each hypothetical hop. All the following subsections assume
the network setup of this figure. the network setup of this figure.
Also, for simplicity sake, all subsections assume an IP header of 20 Also, for simplicity sake, all subsections assume an IP header of 20
octets and a TCP header of 20 octets. Thus, for example, when the octets and a TCP header of 20 octets. Thus, for example, when the
skipping to change at page 27, line 12 skipping to change at page 19, line 34
For simplicity sake, all the following subsections assume the TCP For simplicity sake, all the following subsections assume the TCP
implementation at Host 1 has chosen a a MAXSEGRTO of 1. implementation at Host 1 has chosen a a MAXSEGRTO of 1.
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 | | H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
MTU=4464 MTU=2048 MTU=1500 MTU=4464 MTU=4464 MTU=2048 MTU=1500 MTU=4464
Figure 1: Hypothetical scenario Figure 1: Hypothetical scenario
A.1. Normal operation for bulk transfers 7.3.1. Normal operation for bulk transfers
This subsection shows the proposed counter-measure in normal This subsection shows the proposed counter-measure in normal
operation, when a TCP connection is used for bulk transfers. That operation, when a TCP connection is used for bulk transfers. That
is, it shows how the proposed counter-measure works when there is no is, it shows how the proposed counter-measure works when there is no
attack taking place, and a TCP connection is used for transferring attack taking place, and a TCP connection is used for transferring
large amounts of data. This section assumes that just after the large amounts of data. This section assumes that just after the
connection is established, one of the TCP endpoints begins to connection is established, one of the TCP endpoints begins to
transfer data in packets that are as large as possible. transfer data in packets that are as large as possible.
Host 1 Host 2 Host 1 Host 2
skipping to change at page 28, line 39 skipping to change at page 21, line 21
In line 8, the TCP at H1 sends a segment with 1460 bytes of data, In line 8, the TCP at H1 sends a segment with 1460 bytes of data,
which results in an IP packet of 1500 octets. maxsizesent is thus set which results in an IP packet of 1500 octets. maxsizesent is thus set
to 1500. This packet reaches H2, where it elicits an acknowledgement to 1500. This packet reaches H2, where it elicits an acknowledgement
(ACK) segment. (ACK) segment.
In line 9, H1 finally gets the acknowledgement for the data segment. In line 9, H1 finally gets the acknowledgement for the data segment.
As the corresponding packet was larger than maxsizeacked, TCP updates As the corresponding packet was larger than maxsizeacked, TCP updates
maxsizeacked, setting it to 1500. At this point TCP has discovered maxsizeacked, setting it to 1500. At this point TCP has discovered
the Path-MTU for this TCP connection. the Path-MTU for this TCP connection.
A.2. Operation during Path-MTU changes 7.3.2. Operation during Path-MTU changes
Let us suppose a TCP connection between H1 and H2 has already been Let us suppose a TCP connection between H1 and H2 has already been
established, and that the PMTU for the connection has already been established, and that the PMTU for the connection has already been
discovered to be 1500. At this point, both maxsizesent and discovered to be 1500. At this point, both maxsizesent and
maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose
some time later the PMTU decreases to 1492. For simplicity, let us some time later the PMTU decreases to 1492. For simplicity, let us
suppose that the Path-MTU has decreased because the MTU of the link suppose that the Path-MTU has decreased because the MTU of the link
between R2 and R3 has decreased from 1500 to 1492. Figure 3 between R2 and R3 has decreased from 1500 to 1492. Figure 3
illustrates how the proposed counter-measure would work in this illustrates how the proposed counter-measure would work in this
scenario. scenario.
skipping to change at page 29, line 45 skipping to change at page 22, line 27
protocol in use. protocol in use.
In line 5, H1 retransmits the data using the updated PMTU, and thus In line 5, H1 retransmits the data using the updated PMTU, and thus
maxsizesent is set to 1492. The resulting packet reaches H2, where maxsizesent is set to 1492. The resulting packet reaches H2, where
it elicits an acknowledgement (ACK) segment. it elicits an acknowledgement (ACK) segment.
In line 6, H1 finally gets the acknowledgement for the data segment. In line 6, H1 finally gets the acknowledgement for the data segment.
At this point TCP has discovered the new Path-MTU for this TCP At this point TCP has discovered the new Path-MTU for this TCP
connection. connection.
A.3. Idle connection being attacked 7.3.3. Idle connection being attacked
Let us suppose a TCP connection between H1 and H2 has already been Let us suppose a TCP connection between H1 and H2 has already been
established, and the PMTU for the connection has already been established, and the PMTU for the connection has already been
discovered to be 1500. Figure 4 shows a sample time-line diagram discovered to be 1500. Figure 4 shows a sample time-line diagram
that illustrates an idle connection being attacked. that illustrates an idle connection being attacked.
Host 1 Host 2 Host 1 Host 2
1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=50> --> 1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=50> -->
2. <-- <SEQ=X><ACK=150><CTL=ACK> <-- 2. <-- <SEQ=X><ACK=150><CTL=ACK> <--
skipping to change at page 30, line 24 skipping to change at page 23, line 7
In line 1, H1 sends its last bunch of data. At line 2, H2 In line 1, H1 sends its last bunch of data. At line 2, H2
acknowledges the receipt of these data. Then the connection becomes acknowledges the receipt of these data. Then the connection becomes
idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet
Too Big" error messages to H1. Regardless of how many packets it Too Big" error messages to H1. Regardless of how many packets it
sends and the TCP sequence number each ICMP packet includes, none of sends and the TCP sequence number each ICMP packet includes, none of
these ICMP error messages will pass the TCP sequence number check these ICMP error messages will pass the TCP sequence number check
described in Section 4.1, as H1 has no unacknowledged data in flight described in Section 4.1, as H1 has no unacknowledged data in flight
to H2. Therefore, the attack does not succeed. to H2. Therefore, the attack does not succeed.
A.4. Active connection being attacked after discovery of the Path-MTU 7.3.4. Active connection being attacked after discovery of the Path-MTU
Let us suppose an attacker attacks a TCP connection for which the Let us suppose an attacker attacks a TCP connection for which the
PMTU has already been discovered. In this case, as illustrated in PMTU has already been discovered. In this case, as illustrated in
Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a
possible packet exchange. possible packet exchange.
Host 1 Host 2 Host 1 Host 2
1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1460> --> 1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1460> -->
2. --> <SEQ=1560><ACK=X><CTL=ACK><DATA=1460> --> 2. --> <SEQ=1560><ACK=X><CTL=ACK><DATA=1460> -->
skipping to change at page 31, line 12 skipping to change at page 23, line 42
the connection and a valid TCP sequence number. As the Next-Hop MTU the connection and a valid TCP sequence number. As the Next-Hop MTU
claimed in the ICMP "Packet Too Big" message (claimedmtu) is smaller claimed in the ICMP "Packet Too Big" message (claimedmtu) is smaller
than maxsizeacked, this packet is assumed to be performing Path-MTU than maxsizeacked, this packet is assumed to be performing Path-MTU
Update. Thus, the error message is recorded. Update. Thus, the error message is recorded.
In line 6, H1 receives an acknowledgement for the segment sent in In line 6, H1 receives an acknowledgement for the segment sent in
line 1, before it times out. At this point, the "pending error" line 1, before it times out. At this point, the "pending error"
condition is cleared, and the recorded ICMP "Packet Too Big" error condition is cleared, and the recorded ICMP "Packet Too Big" error
message is ignored. Therefore, the attack does not succeed. message is ignored. Therefore, the attack does not succeed.
A.5. TCP peer attacked when sending small packets just after the three- 7.3.5. TCP peer attacked when sending small packets just after the
way handshake three-way handshake
This section analyzes an scenario in which a TCP peer that is sending This section analyzes an scenario in which a TCP peer that is sending
small segments just after the connection has been established, is small segments just after the connection has been established, is
attacked. The connection could be being used by protocols such as attacked. The connection could be being used by protocols such as
SMTP [RFC2821] and HTTP [RFC2616], for example, which usually behave SMTP [RFC2821] and HTTP [RFC2616], for example, which usually behave
like this. like this.
Figure 6 shows a possible packet exchange for such scenario. Figure 6 shows a possible packet exchange for such scenario.
Host 1 Host 2 Host 1 Host 2
skipping to change at page 32, line 12 skipping to change at page 24, line 42
In lines 6 and 7, H1 sends two small segments to H2. In line 8, In lines 6 and 7, H1 sends two small segments to H2. In line 8,
while the segments from lines 6 and 7 are still in flight to H2, an while the segments from lines 6 and 7 are still in flight to H2, an
attacker sends a forged ICMP "Packet Too Big" error message to H1. attacker sends a forged ICMP "Packet Too Big" error message to H1.
Assuming the attacker is lucky enough to guess a valid TCP sequence Assuming the attacker is lucky enough to guess a valid TCP sequence
number, this ICMP message will pass the TCP sequence number check. number, this ICMP message will pass the TCP sequence number check.
The Next-Hop MTU reported by the ICMP error message (claimedmtu) is The Next-Hop MTU reported by the ICMP error message (claimedmtu) is
then compared with maxsizesent. As claimedmtu is larger than then compared with maxsizesent. As claimedmtu is larger than
maxsizesent, the ICMP error message is silently discarded. maxsizesent, the ICMP error message is silently discarded.
Therefore, the attack does not succeed. Therefore, the attack does not succeed.
Appendix B. Pseudo-code for the counter-measure for the blind 7.4. Pseudo-code for the counter-measure for the blind performance-
performance-degrading attack degrading attack
This section contains a pseudo-code version of the counter-measure This section contains a pseudo-code version of the counter-measure
described in Section 7.2 for the blind performance-degrading attack described in Section 7.2 for the blind performance-degrading attack
described in Section 7. It is meant as guidance for developers on described in Section 7. It is meant as guidance for developers on
how to implement this counter-measure. how to implement this counter-measure.
The pseudo-code makes use of the following variables, constants, and The pseudo-code makes use of the following variables, constants, and
functions: functions:
ack ack
skipping to change at page 33, line 11 skipping to change at page 25, line 40
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 far this connection, as explained in has so far been acked for this connection, as explained in
Section 7.2 Section 7.2.
maxsizesent maxsizesent
Variable holding the largest packet size (data, plus headers) that Variable holding the largest packet size (data, plus headers) that
has so for been sent far this connection, as explained in has so far been sent for 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
skipping to change at page 34, line 12 skipping to change at page 26, line 41
EVENT: Segment is sent EVENT: Segment is sent
if (packet_size > maxsizesent) if (packet_size > maxsizesent)
maxsizesent = packet_size; maxsizesent = packet_size;
EVENT: Segment is received EVENT: Segment is received
if (acked_packet_size > maxsizeacked) if (acked_packet_size > maxsizeacked)
maxsizeacked = acked_packet_size; maxsizeacked = acked_packet_size;
if (pending_mesage) if (pending_message)
if (ack > claimedtcpseq){ if (ack > claimedtcpseq){
pending_message = 0; pending_message = 0;
nsegrto = 0; nsegrto = 0;
} }
EVENT: ICMP "Packet Too Big" message is received EVENT: ICMP "Packet Too Big" message is received
if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >= SND.NXT){ if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >= SND.NXT){
drop_message(); drop_message();
} }
else { else {
if (claimedmtu >= maxsizesent || claimedmtu >= current_mtu) if (claimedmtu >= maxsizesent || claimedmtu >= current_mtu)
drop_message(); drop_message();
else { else {
if (claimedmtu > maxsizeacked){ if (claimedmtu > maxsizeacked){
skipping to change at page 35, line 18 skipping to change at page 28, line 5
} }
Notes: Notes:
All comparisions between sequence numbers must be performed using All comparisions between sequence numbers must be performed using
sequence number arithmethic. sequence number arithmethic.
The pseudo-code implements the mechanism described in Section 7.2, The pseudo-code implements the mechanism described in Section 7.2,
the TCP sequence number checking described in Section 4.1, and the the TCP sequence number checking described in Section 4.1, and the
validation check on the advertised Next-Hop MTU described in validation check on the advertised Next-Hop MTU described in
[RFC1191] and [RFC1981]. [RFC1191] and [RFC1981].
Appendix C. Additional considerations for the validation of ICMP error 8. Security Considerations
messages
The checksum of the IP datagram contained in the ICMP payload should This document describes the use of ICMP error messages to perform a
be checked to be valid. In case it is invalid, the ICMP error number of attacks against the TCP protocol, and describes a number of
message should be silently dropped. widely-implemented counter-measures that either eliminate or reduce
the impact of these attacks when they are performed by off-path
attackers.
If a full IP datagram is contained in the ICMP payload, and the IP 9. Acknowledgements
datagram is authenticated [RFC4301], the signature should be
recalculated for that packet. If it doesn't match the one already
included in the ICMP payload, the ICMP error message should be
silently dropped.
If a full TCP segment is contained in the payload of the ICMP error This document was inspired by Mika Liljeberg, while discussing some
message, then the first check that should be performed is that the issues related to [I-D.ietf-tcpm-tcp-soft-errors] by private e-mail.
TCP checksum is valid. Then, if a TCP MD5 option is present, the MD5 The author would like to thank (in alphabetical order): Bora Akyol,
signature should be recalculated for the encapsulated packet, and if Mark Allman, Ran Atkinson, James Carlson, Alan Cox, Theo de Raadt,
it doesn't match the one contained in the TCP MD5 option, the ICMP Ted Faber, Juan Fraschini, Markus Friedl, Guillermo Gont, John
error message should be silently dropped. Heffner, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, Mika
Liljeberg, Matt Mathis, David Miller, Miles Nordin, Eloy Paris,
Kacheong Poon, Andrew Powell, Pekka Savola, Pyda Srisuresh, Fred
Templin, and Joe Touch for contributing many valuable comments.
Regardless of whether the received ICMP error message contains a full Juan Fraschini and the author of this document implemented freely-
packet or not, if a TCP timestamp option is present, it should be available audit tools to help vendors audit their systems by
used to validate the error message according to the rules specified reproducing the attacks discussed in this document. This tools are
in [RFC1323]. available at http://www.gont.com.ar/tools/index.html .
It must be noted that most of the checks discussed in this appendix Markus Friedl, Chad Loder, and the author of this document, produced
imply that the ICMP error message contains more data than just the and tested in OpenBSD [OpenBSD] the first implementation of the
full IP header and the first 64 bits of the payload of the original counter-measure described in Section 7.2. This first implementation
datagram that elicited the error message. As discussed in Section 3, helped to test the effectiveness of the ideas introduced in this
for obvious reasons one should not expect an attacker to include in document, and has served as a reference implementation for other
the packets it sends more information than that required to by the operating systems.
current specifications.
Appendix D. Advice and guidance to vendors The author would like to thank the UK's National Infrastructure
Security Co-ordination Centre (NISCC) for coordinating the disclosure
of these issues with a large number of vendors and CSIRTs (Computer
Security Incident Response Teams).
Vendors are urged to contact NISCC (vulteam@niscc.gov.uk) if they The author wishes to express deep and heartfelt gratitude to Jorge
Oscar Gont and Nelida Garcia, for their precious motivation and
guidance.
10. References
10.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
10.2. Informative References
[DClark] Clark, D., "The Design Philosophy of the DARPA Internet
Protocols", Computer Communication Review Vol. 18, No. 4,
1988.
[FreeBSD] The FreeBSD Project, "http://www.freebsd.org".
[I-D.ietf-tcpm-tcp-soft-errors]
Gont, F., "TCP's Reaction to Soft Errors",
draft-ietf-tcpm-tcp-soft-errors-07 (work in progress),
December 2007.
[I-D.ietf-tcpm-tcpsecure]
Ramaiah, A., "Improving TCP's Robustness to Blind In-
Window Attacks", draft-ietf-tcpm-tcpsecure-09 (work in
progress), January 2008.
[I-D.ietf-tsvwg-port-randomization]
Larsen, M. and F. Gont, "Port Randomization",
draft-ietf-tsvwg-port-randomization-01 (work in progress),
February 2008.
[ICMP-Filtering]
Gont, F., "Filtering of ICMP error messages", http://
www.gont.com.ar/papers/
filtering-of-icmp-error-messages.pdf.
[IP-filtering]
NISCC, "NISCC Technical Note 01/2006: Egress and Ingress
Filtering", http://www.niscc.gov.uk/niscc/docs/
re-20060420-00294.pdf?lang=en, 2006.
[Linux] The Linux Project, "http://www.kernel.org".
[McKusick]
McKusick, M., Bostic, K., Karels, M., and J. Quarterman,
"The Design and Implementation of the 4.4BSD Operating
System", Addison-Wesley , 1996.
[NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP:
Vulnerability Issues in ICMP packets with TCP payloads",
http://www.niscc.gov.uk/niscc/docs/
al-20050412-00308.html?lang=en, 2005.
[NetBSD] The NetBSD Project, "http://www.netbsd.org".
[OpenBSD] The OpenBSD Project, "http://www.openbsd.org".
[OpenBSD-PF]
The OpenBSD Packet Filter,
"http://www.openbsd.org/faq/pf/".
[RFC0816] Clark, D., "Fault isolation and recovery", RFC 816,
July 1982.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, September 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[RFC4907] Aboba, B., "Architectural Implications of Link
Indications", RFC 4907, June 2007.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007.
[US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP
Implementations do not adequately validate ICMP error
messages", http://www.kb.cert.org/vuls/id/222750, 2005.
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks",
2004 CanSecWest Conference , 2004.
[Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
The Implementation", Addison-Wesley , 1994.
Appendix A. An analysis of ICMP hard errors
This appendix contains an analysis of ICMP hard errors.
ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable)
This ICMP error message indicates that the host sending the ICMP
error message received a packet meant for a transport protocol it
does not support. For connection-oriented protocols such as TCP,
one could expect to receive such an error as the result of a
connection-establishment attempt. However, it would be strange to
get such an error during the life of a connection, as this would
indicate that support for that transport protocol has been removed
from the system sending the error message during the life of the
corresponding connection.
ICMP type 3 (Destination Unreachable), code 3 (port unreachable)
This error message indicates that the system sending the ICMP
error message received a packet meant for a socket (IP address,
port number) on which there is no process listening. Those
transport protocols which have their own mechanisms for notifying
this condition should not be receiving these error messages, as
the protocol would signal the port unreachable condition by means
of its own messages. Assuming that once a connection is
established it is not usual for the transport protocol to change
(or be reloaded), it should be unusual to get these error
messages.
ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed
and DF bit set)
This error message indicates that an intermediate node needed to
fragment a datagram, but the DF (Don't Fragment) bit in the IP
header was set. It is considered a soft error when TCP implements
PMTUD, and a hard error if TCP does not implement PMTUD. Those
TCPs that do not implement the PMTUD mechanism should not be
sending their IP packets with the DF bit set, and thus should not
be receiving these ICMP error messages.
ICMPv6 type 1 (Destination Unreachable), code 1 (communication with
destination administratively prohibited)
This error message indicates that the destination is unreachable
because of an administrative policy. For connection-oriented
protocols such as TCP, one could expect to receive such an error
as the result of a connection-establishment attempt. Receiving
such an error for a connection in any of the synchronized states
would mean that the administrative policy changed during the life
of the connection. However, in the same way this error condition
(which was not present when the conenction was established)
appeared, it could get solved solved in the near term.
ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable)
This error message is analogous to the ICMP type 3 (Destination
Unreachable), code 3 (Port unreachable) error message discussed
above. Therefore, the same considerations apply.
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 there is ambiguity in the
specifications that may or may not provide some room to go against
that advice.
Appendix B. Advice and guidance to vendors
Vendors are urged to contact CPNI (vulteam@cpni.gsi.gov.uk) if they
think they may be affected by the issues described in this document. think they may be affected by the issues described in this document.
As the lead coordination center for these issues, NISCC is well As the lead coordination center for these issues, CPNI is well placed
placed to give advice and guidance as required. to give advice and guidance as required.
NISCC works extensively with government departments and agencies, CPNI works extensively with government departments and agencies,
commercial organizations and the academic community to research commercial organizations and the academic community to research
vulnerabilities and potential threats to IT systems especially where vulnerabilities and potential threats to IT systems especially where
they may have an impact on Critical National Infrastructure's (CNI). they may have an impact on Critical National Infrastructure's (CNI).
Other ways to contact NISCC, plus NISCC's PGP public key, are Other ways to contact CPNI, plus CPNI's PGP public key, are available
available at http://www.uniras.gov.uk/vuls/ . at http://www.cpni.gov.uk .
Appendix E. Changes from previous versions of the draft (to be removed Appendix C. Changes from previous versions of the draft (to be removed
by the RFC Editor before publishing this document as an by the RFC Editor before publishing this document as an
RFC) RFC)
E.1. Changes from draft-ietf-tcpm-icmp-attacks-01 C.1. Changes from draft-ietf-tcpm-icmp-attacks-02
o Added a disclaimer to indicate that this document does not update
the current specifications.
o Addresses feedback sent off-list by Alfred Hoenes.
o The text (particulary that which describes the counter-measures)
was reworded to document what current implementations are doing,
rather than "proposing" the implementation of the counter-
measures.
o Some text has been removed: we're just documenting the problem,
and what existing implementations have done.
o Miscelaneous editorial changes.
C.2. Changes from draft-ietf-tcpm-icmp-attacks-01
o Fixed references to the antispoof documents (were hardcoded and o Fixed references to the antispoof documents (were hardcoded and
missing in the References Section). missing in the References Section).
o The draft had expired and thus is resubmitted with no further o The draft had expired and thus is resubmitted with no further
changes. changes.
E.2. Changes from draft-ietf-tcpm-icmp-attacks-00 C.3. Changes from draft-ietf-tcpm-icmp-attacks-00
o Added references to the specific sections of each of the o Added references to the specific sections of each of the
referenced specifications referenced specifications
o Corrected the threat analysys o Corrected the threat analysys
o Added clarification about whether the counter-measures violate the o Added clarification about whether the counter-measures violate the
current specifications or not. current specifications or not.
o Changed text so that the document fits better in the Informational o Changed text so that the document fits better in the Informational
path path
o Added an specific section on IPsec (Section 2.3) o Added a specific section on IPsec (Section 2.3)
o Added clarification and references on the use of ICMP filtering o Added clarification and references on the use of ICMP filtering
based on the ICMP payload based on the ICMP payload
o Updated references to obsoleted RFCs o Updated references to obsoleted RFCs
o Added a discussion of multipath scenarios, and possible lose in o Added a discussion of multipath scenarios, and possible lose in
responsiveness resulting from the reaction to hard errors as soft responsiveness resulting from the reaction to hard errors as soft
errors (in Section 5.2.3) errors
o Miscellaneous editorial changes o Miscellaneous editorial changes
E.3. Changes from draft-gont-tcpm-icmp-attacks-05 C.4. Changes from draft-gont-tcpm-icmp-attacks-05
o Removed RFC 2119 wording to make the draft suitable for o Removed RFC 2119 wording to make the draft suitable for
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.4. Changes from draft-gont-tcpm-icmp-attacks-04 C.5. Changes from draft-gont-tcpm-icmp-attacks-04
o Added Appendix C o Added section on additional considerations for validating ICMP
error messages
o Added reference to [I-D.iab-link-indications] o Added reference to (draft) [RFC4907]
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.5. Changes from draft-gont-tcpm-icmp-attacks-03 C.6. 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 of the blind connection-reset vulnerability 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 Section 7.4 was added
o Miscellaneous editorial changes o Miscellaneous editorial changes
E.6. Changes from draft-gont-tcpm-icmp-attacks-02 C.7. Changes from draft-gont-tcpm-icmp-attacks-02
o Fixed errors in Section 5.2.1
o Fixed errors in in the discussion of the blind connection-reset
attack
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 Section 7.3 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 B
o Miscellaneous editorial changes o Miscellaneous editorial changes
E.7. Changes from draft-gont-tcpm-icmp-attacks-01 C.8. 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
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.8. Changes from draft-gont-tcpm-icmp-attacks-00 C.9. 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
skipping to change at page 40, line 7 skipping to change at page 38, line 7
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fernando@gont.com.ar Email: fernando@gont.com.ar
URI: http://www.gont.com.ar URI: http://www.gont.com.ar
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 40, line 44 skipping to change at line 1680
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 101 change blocks. 
711 lines changed or deleted 597 lines changed or added

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