draft-ietf-tcpm-icmp-attacks-06.txt   draft-ietf-tcpm-icmp-attacks-07.txt 
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UTN/FRH Extensions (tcpm) UTN/FRH
Internet-Draft August 24, 2009 Internet-Draft December 8, 2009
Intended status: Informational Intended status: Informational
Expires: February 25, 2010 Expires: June 11, 2010
ICMP attacks against TCP ICMP attacks against TCP
draft-ietf-tcpm-icmp-attacks-06.txt draft-ietf-tcpm-icmp-attacks-07.txt
Abstract
This document discusses the use of the Internet Control Message
Protocol (ICMP) to perform a variety of attacks against the
Transmission Control Protocol (TCP) and other similar protocols.
Additionally, describes a number of widely implemented modifications
to TCP's handling of ICMP error messages that help to mitigate these
issues.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 42
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 February 25, 2010. This Internet-Draft will expire on June 11, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document discusses the use of the Internet Control Message This document may contain material from IETF Documents or IETF
Protocol (ICMP) to perform a variety of attacks against the Contributions published or made publicly available before November
Transmission Control Protocol (TCP) and other similar protocols. 10, 2008. The person(s) controlling the copyright in some of this
Additionally, describes a number of widely implemented modifications material may not have granted the IETF Trust the right to allow
to TCP's handling of ICMP error messages that help to mitigate these modifications of such material outside the IETF Standards Process.
issues. Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5 2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 6
2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 5 2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 6
2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6 2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 7
2.2. Handling of ICMP error messages . . . . . . . . . . . . . 6 2.2. Handling of ICMP error messages . . . . . . . . . . . . . 7
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 . 8
3. Constraints in the possible solutions . . . . . . . . . . . . 8 3. Constraints in the possible solutions . . . . . . . . . . . . 9
4. General counter-measures against ICMP attacks . . . . . . . . 9 4. General counter-measures against ICMP attacks . . . . . . . . 10
4.1. TCP sequence number checking . . . . . . . . . . . . . . . 9 4.1. TCP sequence number checking . . . . . . . . . . . . . . . 10
4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 10 4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 11
4.3. Filtering ICMP error messages based on the ICMP payload . 10 4.3. Filtering ICMP error messages based on the ICMP payload . 11
5. Blind connection-reset attack . . . . . . . . . . . . . . . . 11 5. Blind connection-reset attack . . . . . . . . . . . . . . . . 12
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Attack-specific counter-measures . . . . . . . . . . . . . 12 5.2. Attack-specific counter-measures . . . . . . . . . . . . . 13
6. Blind throughput-reduction attack . . . . . . . . . . . . . . 15 6. Blind throughput-reduction attack . . . . . . . . . . . . . . 16
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Attack-specific counter-measures . . . . . . . . . . . . . 15 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 16
7. Blind performance-degrading attack . . . . . . . . . . . . . . 15 7. Blind performance-degrading attack . . . . . . . . . . . . . . 17
7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Attack-specific counter-measures . . . . . . . . . . . . . 17 7.2. Attack-specific counter-measures . . . . . . . . . . . . . 18
7.3. The counter-measure for the PMTUD attack in action . . . . 20 7.3. The counter-measure for the PMTUD attack in action . . . . 22
7.3.1. Normal operation for bulk transfers . . . . . . . . . 21 7.3.1. Normal operation for bulk transfers . . . . . . . . . 22
7.3.2. Operation during Path-MTU changes . . . . . . . . . . 23 7.3.2. Operation during Path-MTU changes . . . . . . . . . . 24
7.3.3. Idle connection being attacked . . . . . . . . . . . . 24 7.3.3. Idle connection being attacked . . . . . . . . . . . . 25
7.3.4. Active connection being attacked after discovery 7.3.4. Active connection being attacked after discovery
of the Path-MTU . . . . . . . . . . . . . . . . . . . 24 of the Path-MTU . . . . . . . . . . . . . . . . . . . 26
7.3.5. TCP peer attacked when sending small packets just 7.3.5. TCP peer attacked when sending small packets just
after the three-way handshake . . . . . . . . . . . . 25 after the three-way handshake . . . . . . . . . . . . 26
7.4. Pseudo-code for the counter-measure for the blind 7.4. Pseudo-code for the counter-measure for the blind
performance-degrading attack . . . . . . . . . . . . . . . 26 performance-degrading attack . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Changes from previous versions of the draft (to Appendix A. 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) . . . . . . . . . . . . . . 34 this document as an RFC) . . . . . . . . . . . . . . 36
A.1. Changes from draft-ietf-tcpm-icmp-attacks-05 . . . . . . . 34 A.1. Changes from draft-ietf-tcpm-icmp-attacks-06 . . . . . . . 36
A.2. Changes from draft-ietf-tcpm-icmp-attacks-04 . . . . . . . 34 A.2. Changes from draft-ietf-tcpm-icmp-attacks-05 . . . . . . . 36
A.3. Changes from draft-ietf-tcpm-icmp-attacks-03 . . . . . . . 34 A.3. Changes from draft-ietf-tcpm-icmp-attacks-04 . . . . . . . 36
A.4. Changes from draft-ietf-tcpm-icmp-attacks-02 . . . . . . . 34 A.4. Changes from draft-ietf-tcpm-icmp-attacks-03 . . . . . . . 36
A.5. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 35 A.5. Changes from draft-ietf-tcpm-icmp-attacks-02 . . . . . . . 36
A.6. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 35 A.6. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 37
A.7. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 35 A.7. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 37
A.8. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 36 A.8. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 37
A.9. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 36 A.9. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 38
A.10. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 36 A.10. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 38
A.11. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 36 A.11. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 38
A.12. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 37 A.12. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 A.13. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite,
and is used mainly for reporting network error conditions. However, and is used mainly for reporting network error conditions. However,
the current specifications do not recommend any kind of validation the current specifications do not recommend any kind of validation
checks on the received ICMP error messages, thus 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
skipping to change at page 5, line 30 skipping to change at page 6, line 30
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.
It is important to note that ICMP error messages are unreliable, and It is important to note that ICMP error messages are unreliable, and
may be discarded due to data corruption, network congestion or rate- may be discarded due to data corruption, network congestion or rate-
limiting. Thus, while they provide useful information, upper layer limiting. Thus, while they provide useful information, upper layer
protocols cannot depend on ICMP for correct operation. protocols cannot depend on ICMP for correct operation.
It should be noted that are no timeliness requirements for ICMP error
messages. ICMP error messages could be delayed for various reasons,
and at least in theory could be received with an arbitrarily long
delay. For example, there are no existing requirements that a router
flushes any queued ICMP error messages when it is rebooted.
2.1.1. ICMP for IP version 4 (ICMP) 2.1.1. ICMP for IP version 4 (ICMP)
[RFC0792] specifies the Internet Control Message Protocol (ICMP) to [RFC0792] specifies the Internet Control Message Protocol (ICMP) to
be used with the Internet Protocol version 4 (IPv4). It defines, be used with the Internet Protocol version 4 (IPv4). It defines,
among other things, a number of error messages that can be used by among other things, a number of error messages that can be used by
end-systems and intermediate systems to report errors to the sending end-systems and intermediate systems to report errors to the sending
system. The Host Requirements RFC [RFC1122] classifies ICMP error system. The Host Requirements RFC [RFC1122] classifies ICMP error
messages into those that indicate "soft errors", and those that messages into those that indicate "soft errors", and those that
indicate "hard errors", thus roughly defining the semantics of them. indicate "hard errors", thus roughly defining the semantics of them.
skipping to change at page 6, line 38 skipping to change at page 7, line 44
receiving system can use that information to match the ICMP error to receiving system can use that information to match the ICMP error to
the transport protocol instance that elicited it. the transport protocol instance that elicited it.
Neither the Host Requirements RFC [RFC1122] nor the original TCP Neither the Host Requirements RFC [RFC1122] nor the original TCP
specification [RFC0793] recommend any validation checks on the specification [RFC0793] recommend any validation checks on the
received ICMP messages. Thus, as long as the ICMP payload contains received ICMP messages. Thus, as long as the ICMP payload contains
the information that identifies an existing communication instance, the information that identifies an existing communication instance,
it will be processed by the corresponding transport-protocol it will be processed by the corresponding transport-protocol
instance, and the corresponding action will be performed. instance, and the corresponding action will be performed.
Therefore, in the case of TCP, an attacker could send a forged ICMP Therefore, in the case of TCP, an attacker could send a crafted ICMP
message to the attacked system, and, as long as he is able to guess error message to the attacked system, and, as long as he is able to
the four-tuple (i.e., Source IP Address, Source TCP port, Destination guess the four-tuple (i.e., Source IP Address, Source TCP port,
IP Address, and Destination TCP port) that identifies the Destination IP Address, and Destination TCP port) that identifies the
communication instance to be attacked, he will be able to use ICMP to communication instance to be attacked, he will be able to use ICMP to
perform a variety of attacks. perform a variety of attacks.
Generally, the four-tuple required to perform these attacks is not Generally, the four-tuple required to perform these attacks is not
known. However, as discussed in [Watson] and [RFC4953], there are a known. However, as discussed in [Watson] and [RFC4953], there are a
number of scenarios (notably that of TCP connections established number of scenarios (notably that of TCP connections established
between two BGP routers [RFC4271]), in which an attacker may be able between two BGP routers [RFC4271]), in which an attacker may be able
to know or guess the four-tuple that identifies a TCP connection. In to know or guess the four-tuple that identifies a TCP connection. In
such a case, if we assume the attacker knows the two systems involved such a case, if we assume the attacker knows the two systems involved
in the TCP connection to be attacked, both the client-side and the in the TCP connection to be attacked, both the client-side and the
skipping to change at page 7, line 14 skipping to change at page 8, line 21
number of possibilities. Furthermore, as most Internet services use number of possibilities. Furthermore, as most Internet services use
the so-called "well-known" ports, only the client port number might the so-called "well-known" ports, only the client port number might
need to be guessed. In such a scenario, an attacker would need to need to be guessed. In such a scenario, an attacker would need to
send, in principle, at most 65536 packets to perform any of the send, in principle, at most 65536 packets to perform any of the
attacks described in this document. These issues are exacerbated by attacks described in this document. These issues are exacerbated by
the fact that most systems choose the port numbers they use for the fact that most systems choose the port numbers they use for
outgoing connections from a subset of the whole port number space, outgoing connections from a subset of the whole port number space,
thus reducing the amount of work needed to successfully perform these thus reducing the amount of work needed to successfully perform these
attacks. attacks.
The need to be more more cautious when processing received ICMP error The need to be more cautious when processing received ICMP error
messages in order to mitigate or eliminate the impact of the attacks messages in order to mitigate or eliminate the impact of the attacks
described in this document has been documented by the Internet described in this document has been documented by the Internet
Architecture Board (IAB) in [RFC4907]. Architecture Board (IAB) in [RFC4907].
2.3. Handling of ICMP error messages in the context of IPsec 2.3. Handling of ICMP error messages in the context of IPsec
Section 5.2 of [RFC4301] describes the processing of inbound IP Section 5.2 of [RFC4301] describes the processing of inbound IP
Traffic in the case of "unprotected-to-protected". In the case of Traffic in the case of "unprotected-to-protected". In the case of
ICMP, when an unprotected ICMP error message is received, it is ICMP, when an unprotected ICMP error message is received, it is
matched to the corresponding security association by means of the SPI matched to the corresponding security association by means of the SPI
skipping to change at page 9, line 36 skipping to change at page 10, line 42
against these attacks. against these attacks.
4.1. TCP sequence number checking 4.1. TCP sequence number checking
The current specifications do not impose any validity checks on the The current specifications do not impose any validity checks on the
TCP segment that is contained in the ICMP payload. For instance, no TCP segment that is contained in the ICMP payload. For instance, no
checks are performed to verify that a received ICMP error message has checks are performed to verify that a received ICMP error message has
been 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.
Many TCP implementations have incorporated a validation check so Many TCP implementations have incorporated a validation check such
makes TCP react only to those ICMP error messages elicited by that they react only to those ICMP error messages that appear to
segments that were "in-flight" to the destination system. These relate to segments currently "in-flight" to the destination system.
implementations check that the TCP sequence number contained in the These implementations check that the TCP sequence number contained in
payload of the ICMP error message is within the range SND.UNA =< the payload of the ICMP error message is within the range SND.UNA =<
SEG.SEQ < SND.NXT. This means that they require that the sequence SEG.SEQ < SND.NXT. This means that they require that the sequence
number be within the range of the data already sent but not yet number be within the range of the data already sent but not yet
acknowledged. If an ICMP error message does not pass this check, it acknowledged. If an ICMP error message does not pass this check, it
is 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]).
skipping to change at page 10, line 21 skipping to change at page 11, line 28
It is important to note that while this check greatly increases the It is important to note that while this check greatly increases the
number of packets required to perform any of the attacks discussed in number of packets required to perform any of the attacks discussed in
this document, this may not be enough in those scenarios in which this document, this may not be enough in those scenarios in which
bandwidth is easily available, and/or large TCP windows [RFC1323] are bandwidth is easily available, and/or large TCP windows [RFC1323] are
in use. Additionally, this validation check does not help to prevent in use. Additionally, this validation check does not help to prevent
on-path attacks, that is, attacks performed in scenarios in which the on-path attacks, that is, attacks performed in scenarios in which the
attacker can sniff the packets that correspond to the target TCP attacker can sniff the packets that correspond to the target TCP
connection. connection.
It should be note that as there are no timeliness for ICMP error It should be noted that as there are no timeliness requirements for
messages, the TCP Sequence Number check described in this section ICMP error messages, the TCP Sequence Number check described in this
might cause legitimate ICMP error messages to be discarded. section might cause legitimate ICMP error messages to be discarded.
Also, even if this check is enforced, TCP might end up responding to
stale ICMP error messages (e.g., if the Sequence Number for the
corresponding direction of the data transfer wrap around).
4.2. Port randomization 4.2. Port randomization
As discussed in the previous sections, in order to perform any of the As discussed in the previous sections, in order to perform any of the
attacks described in this document, an attacker would need to guess attacks described in this document, an attacker would need to guess
(or know) the four-tuple that identifies the connection to be (or know) the four-tuple that identifies the connection to be
attacked. Increasing the port number range used for outgoing TCP attacked. Increasing the port number range used for outgoing TCP
connections, and randomizing the port number chosen for each outgoing connections, and randomizing the port number chosen for each outgoing
TCP conenctions would make it harder for an attacker to perform any TCP connections would make it harder for an attacker to perform any
of the attacks discussed in this document. of the attacks discussed in this document.
[I-D.ietf-tsvwg-port-randomization] discusses a number of algorithms [I-D.ietf-tsvwg-port-randomization] discusses a number of 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
skipping to change at page 13, line 30 skipping to change at page 14, line 43
ICMPv6 type 1 (Destination Unreachable), code 1 (communication with ICMPv6 type 1 (Destination Unreachable), code 1 (communication with
destination administratively prohibited) destination administratively prohibited)
This error message indicates that the destination is unreachable This error message indicates that the destination is unreachable
because of an administrative policy. For connection-oriented because of an administrative policy. For connection-oriented
protocols such as TCP, one could expect to receive such an error protocols such as TCP, one could expect to receive such an error
as the result of a connection-establishment attempt. Receiving as the result of a connection-establishment attempt. Receiving
such an error for a connection in any of the synchronized states such an error for a connection in any of the synchronized states
would mean that the administrative policy changed during the life would mean that the administrative policy changed during the life
of the connection. However, in the same way this error condition of the connection. However, in the same way this error condition
(which was not present when the conenction was established) (which was not present when the connection was established)
appeared, it could get solved solved in the near term. appeared, it could get solved in the near term.
ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable) ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable)
This error message is analogous to the ICMP type 3 (Destination This error message is analogous to the ICMP type 3 (Destination
Unreachable), code 3 (Port unreachable) error message discussed Unreachable), code 3 (Port unreachable) error message discussed
above. Therefore, the same considerations apply. above. Therefore, the same considerations apply.
The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that
TCP SHOULD abort the corresponding connection in response to ICMP TCP SHOULD abort the corresponding connection in response to ICMP
messages of type 3, codes 2 (protocol unreachable), 3 (port messages of type 3, codes 2 (protocol unreachable), 3 (port
skipping to change at page 14, line 5 skipping to change at page 15, line 18
(type 3, code 3) for the same purpose as an RST. Therefore, for ICMP (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 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 advice provided in the existing specifications, while in the case of
ICMP messages of type 3 code 3 there is ambiguity in the ICMP messages of type 3 code 3 there is ambiguity in the
specifications that may or may not provide some room to go against specifications that may or may not provide some room to go against
that advice. that advice.
Based on this analysis, most popular TCP implementations treat all Based on this analysis, most popular TCP implementations treat all
ICMP "hard errors" received for connections in any of the ICMP "hard errors" received for connections in any of the
synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
CLOSING, LAST-ACK or TIME-WAIT)as "soft errors". That is, they do CLOSING, LAST-ACK or TIME-WAIT) as "soft errors". That is, they do
not abort the corresponding connection upon receipt of them. not abort the corresponding connection upon receipt of them.
Additionally, they do not extrapolate ICMP errors across TCP Additionally, they do not extrapolate ICMP errors across TCP
connections. This policy is based on the premise that TCP should be connections. This policy is based on the premise that TCP should be
as robust as possible. Aborting the connection would be to ignore as robust as possible. Aborting the connection would be to ignore
the valuable feature of the Internet that for many internal failures the valuable feature of the Internet that for many internal failures
it reconstructs its function without any disruption of the end points it reconstructs its function without any disruption of the end points
[RFC0816]. [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
skipping to change at page 16, line 16 skipping to change at page 17, line 28
[RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and [RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and
IPv6, respectively. IPv6, respectively.
The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the
IP header to dynamically discover the Path MTU. The basic idea IP header to dynamically discover the Path MTU. The basic idea
behind the PMTUD mechanism is that a source system assumes that the behind the PMTUD mechanism is that a source system assumes that the
MTU of the path is that of the first hop, and sends all its datagrams MTU of the path is that of the first hop, and sends all its datagrams
with the DF bit set. If any of the datagrams is too large to be with the DF bit set. If any of the datagrams is too large to be
forwarded without fragmentation by some intermediate router, the forwarded without fragmentation by some intermediate router, the
router will discard the corresponding datagram, and will return an router will discard the corresponding datagram, and will return an
ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF ICMP "Destination Unreachable" (type 3) "fragmentation needed and DF
set" (code 4) error message to the sending system. This message will set" (code 4) error message to the sending system. This message will
report the MTU of the constricting hop, so that the sending system report the MTU of the constricting hop, so that the sending system
can reduce the assumed Path-MTU accordingly. can reduce the assumed Path-MTU accordingly.
For IPv6, intermediate systems do not fragment packets. Thus, For IPv6, intermediate systems do not fragment packets. Thus,
there's an "implicit" DF bit set in every packet sent on a network. there's an "implicit" DF bit set in every packet sent on a network.
If any of the datagrams is too large to be forwarded without If any of the datagrams is too large to be forwarded without
fragmentation by some intermediate router, the router will discard fragmentation by some intermediate router, the router will discard
the corresponding datagram, and will return an ICMPv6 "Packet Too the corresponding datagram, and will return an ICMPv6 "Packet Too
Big" (type 2, code 0) error message to sending system. This message Big" (type 2, code 0) error message to sending system. This message
will report the MTU of the constricting hop, so that the sending will report the MTU of the constricting hop, so that the sending
system can reduce the assumed Path-MTU accordingly. system can reduce the assumed Path-MTU accordingly.
As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery
mechanism can be used to attack TCP. An attacker could send a forged mechanism can be used to attack TCP. An attacker could send a
ICMP "Destination Unreachable, fragmentation needed and DF set" crafted ICMP "Destination Unreachable, fragmentation needed and DF
packet (or their ICMPv6 counterpart) to the sending system, set" packet (or their ICMPv6 counterpart) to the sending system,
advertising a small Next-Hop MTU. As a result, the attacked system advertising a small Next-Hop MTU. As a result, the attacked system
would reduce the size of the packets it sends for the corresponding would reduce the size of the packets it sends for the corresponding
connection accordingly. connection accordingly.
The effect of this attack is two-fold. On one hand, it will increase The effect of this attack is two-fold. On one hand, it will increase
the headers/data ratio, thus increasing the overhead needed to send the headers/data ratio, thus increasing the overhead needed to send
data to the remote TCP end-point. On the other hand, if the attacked data to the remote TCP 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
skipping to change at page 17, line 24 skipping to change at page 18, line 37
unpredictable results. unpredictable results.
For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as
[RFC0791] requires every internet module to be able to forward a [RFC0791] requires every internet module to be able to forward a
datagram of 68 octets without further fragmentation. For IPv6, the datagram of 68 octets without further fragmentation. For IPv6, the
reported Next-Hop MTU could be as low as 1280 octets (the minimum reported Next-Hop MTU could be as low as 1280 octets (the minimum
IPv6 MTU) [RFC2460]. IPv6 MTU) [RFC2460].
7.2. Attack-specific counter-measures 7.2. Attack-specific counter-measures
The IETF has standardized a Path-MTU Discuvery mechanism called The IETF has standardized a Path-MTU Discovery mechanism called
"Packetization Layer Path MTU Discovery" that does not depend on ICMP "Packetization Layer Path MTU Discovery" that does not depend on ICMP
error messages. Implementation of the aforementioned mechanism in error messages. Implementation of the aforementioned mechanism in
replacement of the traditional PMTUD (specified in [RFC1191] and replacement of the traditional PMTUD (specified in [RFC1191] and
[RFC1981]) would eliminate this vulnerability. However, it might [RFC1981]) would eliminate this vulnerability. However, it might
also lead to an increase of the PMTUD convergence time. also lead to an increase of the PMTUD convergence time.
This section describes a modification to the PMTUD mechanism This section describes a modification to the PMTUD mechanism
specified in [RFC1191] and [RFC1981] that has been implemented in a specified in [RFC1191] and [RFC1981] that has been implemented in a
variety of TCP implementations to improve TCP's resistance to the variety of TCP implementations to improve TCP's resistance to the
blind performance-degrading attack described in Section 7.1. The blind performance-degrading attack described in Section 7.1. The
skipping to change at page 30, line 13 skipping to change at page 31, line 13
[RFC1191] and [RFC1981]. [RFC1191] and [RFC1981].
8. Security Considerations 8. Security Considerations
This document describes the use of ICMP error messages to perform a This document describes the use of ICMP error messages to perform a
number of attacks against the TCP protocol, and describes a number of number of attacks against the TCP protocol, and describes a number of
widely-implemented counter-measures that either eliminate or reduce widely-implemented counter-measures that either eliminate or reduce
the impact of these attacks when they are performed by off-path the impact of these attacks when they are performed by off-path
attackers. attackers.
9. Acknowledgements Section 4.1 describes a validation check that could be enforced on
ICMP error messages, such that TCP reacts only to those ICMP error
messages that appear to relate to segments currently "in-flight" to
the destination system. This requires more effort on the side of an
off-path attacker at the expense of possible reduced responsiveness
to network errors.
Section 4.2 describes how obfuscation of TCP ephemeral ports require
more effort on the side of the attacker to successfully exploit any
of the attacks described in this document.
Section 4.3 describes how ICMP error messages could possibly be
filtered based on their payload, to prevent users of the local
network from successfully performing attacks against third-party
connections. This is analogous to ingress filtering and egress
filtering of IP packets [IP-filtering].
Section 5.2 describes an attack-specific counter-measure for the
blind connection-reset attack. It describes the processing of ICMP
"hard errors" as "soft errors" when they are received for connections
in any of the synchronized states. This countermeasure eliminates
the aforementioned vulnerability in synchronized connections at the
expense of a possible reduced responsiveness in some network
scenarios.
Section 6.2 describes an attack-specific counter-measure for the
blind throughput-reduction attack. It suggests that the
aforementioned vulnerability can be eliminated by ignoring ICMP
Source Quench messages meant for TCP connections. This is in
accordance with research results that indicate that ICMP Source
Quench messages are ineffective and unfair antidote for congestion.
Finally, Section 7.2 describes an attack-specific countermeasure for
the blind performance-degrading attack. It consists of the
validation check described in Section 4.1, with a modification that
makes TCP react to ICMP "Packet Too Big" error messages such that
they are processed when an outstanding TCP segment times out. This
countermeasures parallels the Packetization Layer Path MTU Discovery
(PLPMTUD) mechanism [RFC4821].
9. IANA Considerations
This document has no actions for IANA.. The RFC-Editor can remove
this section before publication of this document as an RFC.
10. Acknowledgements
This document was inspired by Mika Liljeberg, while discussing some This document was inspired by Mika Liljeberg, while discussing some
issues related to [I-D.ietf-tcpm-tcp-soft-errors] by private e-mail. issues related to [RFC5461] by private e-mail. The author would like
The author would like to thank (in alphabetical order): Bora Akyol, to thank (in alphabetical order): Bora Akyol, Mark Allman, Ran
Mark Allman, Ran Atkinson, James Carlson, Alan Cox, Theo de Raadt, Atkinson, James Carlson, Alan Cox, Theo de Raadt, Wesley Eddy, Ted
Wesley Eddy, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo Faber, Juan Fraschini, Markus Friedl, Guillermo Gont, John Heffner,
Gont, John Heffner, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, Mika Liljeberg, Matt
Mika Liljeberg, Matt Mathis, David Miller, Miles Nordin, Eloy Paris, Mathis, David Miller, Toby Moncaster, Miles Nordin, Eloy Paris,
Kacheong Poon, Andrew Powell, Pekka Savola, Pyda Srisuresh, Fred Kacheong Poon, Andrew Powell, Pekka Savola, Donald Smith, Pyda
Templin, and Joe Touch for contributing many valuable comments. Srisuresh, Fred Templin, and Joe Touch for contributing many valuable
comments.
Juan Fraschini and the author of this document implemented freely- Juan Fraschini and the author of this document implemented freely-
available audit tools to help vendors audit their systems by available audit tools to help vendors audit their systems by
reproducing the attacks discussed in this document. This tools are reproducing the attacks discussed in this document. This tools are
available at http://www.gont.com.ar/tools/index.html . available at http://www.gont.com.ar/tools/index.html .
Markus Friedl, Chad Loder, and the author of this document, produced Markus Friedl, Chad Loder, and the author of this document, produced
and tested in OpenBSD [OpenBSD] the first implementation of the and tested in OpenBSD [OpenBSD] the first implementation of the
counter-measure described in Section 7.2. This first implementation counter-measure described in Section 7.2. This first implementation
helped to test the effectiveness of the ideas introduced in this helped to test the effectiveness of the ideas introduced in this
skipping to change at page 30, line 47 skipping to change at page 32, line 45
The author would like to thank the UK's Centre for the Protection of The author would like to thank the UK's Centre for the Protection of
National Infrastructure (CPNI) -- formerly National Infrastructure National Infrastructure (CPNI) -- formerly National Infrastructure
Security Co-ordination Centre (NISCC) -- for coordinating the Security Co-ordination Centre (NISCC) -- for coordinating the
disclosure of these issues with a large number of vendors and CSIRTs disclosure of these issues with a large number of vendors and CSIRTs
(Computer Security Incident Response Teams). (Computer Security Incident Response Teams).
The author wishes to express deep and heartfelt gratitude to Jorge The author wishes to express deep and heartfelt gratitude to Jorge
Oscar Gont and Nelida Garcia, for their precious motivation and Oscar Gont and Nelida Garcia, for their precious motivation and
guidance. guidance.
10. References 11. References
10.1. Normative References
11.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
skipping to change at page 31, line 40 skipping to change at page 33, line 36
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
10.2. Informative References 11.2. Informative References
[DClark] Clark, D., "The Design Philosophy of the DARPA Internet [DClark] Clark, D., "The Design Philosophy of the DARPA Internet
Protocols", Computer Communication Review Vol. 18, No. 4, Protocols", Computer Communication Review Vol. 18, No. 4,
1988. 1988.
[FreeBSD] The FreeBSD Project, "http://www.freebsd.org". [FreeBSD] The FreeBSD Project, "http://www.freebsd.org".
[I-D.ietf-tcpm-tcp-auth-opt] [I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-05 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-08
(work in progress), July 2009. (work in progress), October 2009.
[I-D.ietf-tcpm-tcp-soft-errors]
Gont, F., "TCP's Reaction to Soft Errors",
draft-ietf-tcpm-tcp-soft-errors-09 (work in progress),
November 2008.
[I-D.ietf-tcpm-tcpsecure] [I-D.ietf-tcpm-tcpsecure]
Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", Robustness to Blind In-Window Attacks",
draft-ietf-tcpm-tcpsecure-11 (work in progress), draft-ietf-tcpm-tcpsecure-12 (work in progress),
November 2008. September 2009.
[I-D.ietf-tsvwg-port-randomization] [I-D.ietf-tsvwg-port-randomization]
Larsen, M. and F. Gont, "Port Randomization", Larsen, M. and F. Gont, "Port Randomization",
draft-ietf-tsvwg-port-randomization-04 (work in progress), draft-ietf-tsvwg-port-randomization-05 (work in progress),
July 2009. November 2009.
[ICMP-Filtering] [ICMP-Filtering]
Gont, F., "Filtering of ICMP error messages", http:// Gont, F., "Filtering of ICMP error messages", http://
www.gont.com.ar/papers/ www.gont.com.ar/papers/
filtering-of-icmp-error-messages.pdf. filtering-of-icmp-error-messages.pdf.
[IP-filtering] [IP-filtering]
NISCC, "NISCC Technical Note 01/2006: Egress and Ingress NISCC, "NISCC Technical Note 01/2006: Egress and Ingress
Filtering", http://www.niscc.gov.uk/niscc/docs/ Filtering", http://www.niscc.gov.uk/niscc/docs/
re-20060420-00294.pdf?lang=en, 2006. re-20060420-00294.pdf?lang=en, 2006.
skipping to change at page 33, line 46 skipping to change at page 35, line 37
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, March 2007.
[RFC4907] Aboba, B., "Architectural Implications of Link [RFC4907] Aboba, B., "Architectural Implications of Link
Indications", RFC 4907, June 2007. Indications", RFC 4907, June 2007.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007. RFC 4953, July 2007.
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
February 2009.
[US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP [US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP
Implementations do not adequately validate ICMP error Implementations do not adequately validate ICMP error
messages", http://www.kb.cert.org/vuls/id/222750, 2005. messages", http://www.kb.cert.org/vuls/id/222750, 2005.
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks",
2004 CanSecWest Conference , 2004. 2004 CanSecWest Conference , 2004.
[Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: [Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
The Implementation", Addison-Wesley , 1994. The Implementation", Addison-Wesley , 1994.
Appendix A. Changes from previous versions of the draft (to be removed Appendix A. 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)
A.1. Changes from draft-ietf-tcpm-icmp-attacks-05 A.1. Changes from draft-ietf-tcpm-icmp-attacks-06
o Addresses WGLC feedback by Joe Touch and Donald Smith.
A.2. Changes from draft-ietf-tcpm-icmp-attacks-05
o Addresses feedback submitted by Wes Eddy o Addresses feedback submitted by Wes Eddy
(http://www.ietf.org/mail-archive/web/tcpm/current/msg04573.html (http://www.ietf.org/mail-archive/web/tcpm/current/msg04573.html
and and
http://www.ietf.org/mail-archive/web/tcpm/current/msg04574.html) http://www.ietf.org/mail-archive/web/tcpm/current/msg04574.html)
and Joe Touch (on June 8th... couldn't find online ref, sorry) on and Joe Touch (on June 8th... couldn't find online ref, sorry) on
the TCPM WG mailing-list. the TCPM WG mailing-list.
A.2. Changes from draft-ietf-tcpm-icmp-attacks-04 A.3. Changes from draft-ietf-tcpm-icmp-attacks-04
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. Currently working on a rev of the document (Please send changes. Currently working on a rev of the document (Please send
feedback!). feedback!).
A.3. Changes from draft-ietf-tcpm-icmp-attacks-03 A.4. Changes from draft-ietf-tcpm-icmp-attacks-03
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.
A.4. Changes from draft-ietf-tcpm-icmp-attacks-02 A.5. Changes from draft-ietf-tcpm-icmp-attacks-02
o Added a disclaimer to indicate that this document does not update o Added a disclaimer to indicate that this document does not update
the current specifications. the current specifications.
o Addresses feedback sent off-list by Alfred Hoenes. o Addresses feedback sent off-list by Alfred Hoenes.
o The text (particulary that which describes the counter-measures) o The text (particulary that which describes the counter-measures)
was reworded to document what current implementations are doing, was reworded to document what current implementations are doing,
rather than "proposing" the implementation of the counter- rather than "proposing" the implementation of the counter-
measures. measures.
o Some text has been removed: we're just documenting the problem, o Some text has been removed: we're just documenting the problem,
and what existing implementations have done. and what existing implementations have done.
o Miscelaneous editorial changes. o Miscelaneous editorial changes.
A.5. Changes from draft-ietf-tcpm-icmp-attacks-01 A.6. 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 only a minor o The draft had expired and thus is resubmitted with only a minor
editorial change. editorial change.
A.6. Changes from draft-ietf-tcpm-icmp-attacks-00 A.7. 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
skipping to change at page 35, line 39 skipping to change at page 37, line 39
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 errors
o Miscellaneous editorial changes o Miscellaneous editorial changes
A.7. Changes from draft-gont-tcpm-icmp-attacks-05 A.8. 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
A.8. Changes from draft-gont-tcpm-icmp-attacks-04 A.9. Changes from draft-gont-tcpm-icmp-attacks-04
o Added section on additional considerations for validating ICMP o Added section on additional considerations for validating ICMP
error messages error messages
o Added reference to (draft) [RFC4907] 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
A.9. Changes from draft-gont-tcpm-icmp-attacks-03 A.10. 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 of the blind connection-reset vulnerability was o The discussion of the blind connection-reset vulnerability was
expanded and improved 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 Section 7.4 was added o Section 7.4 was added
o Miscellaneous editorial changes o Miscellaneous editorial changes
A.10. Changes from draft-gont-tcpm-icmp-attacks-02 A.11. Changes from draft-gont-tcpm-icmp-attacks-02
o Fixed errors in in the discussion of the blind connection-reset o Fixed errors in in the discussion of the blind connection-reset
attack 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 Section 7.3 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 CPNI contact information. o Added CPNI contact information.
o Miscellaneous editorial changes o Miscellaneous editorial changes
A.11. Changes from draft-gont-tcpm-icmp-attacks-01 A.12. 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
A.12. Changes from draft-gont-tcpm-icmp-attacks-00 A.13. Changes from draft-gont-tcpm-icmp-attacks-00
o Added a proposal to change the handling of the so-called ICMP hard o Added a proposal to change the handling of the so-called ICMP hard
errors during the synchronized states errors during the synchronized states
o Added a summary of the relevant RFCs in several sections o Added a summary of the relevant RFCs in several sections
o Miscellaneous editorial changes o Miscellaneous editorial changes
Author's Address Author's Address
 End of changes. 42 change blocks. 
120 lines changed or deleted 196 lines changed or added

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