draft-ietf-tcpm-icmp-attacks-09.txt   draft-ietf-tcpm-icmp-attacks-10.txt 
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UTN/FRH Extensions (tcpm) UTN/FRH
Internet-Draft January 19, 2010 Internet-Draft January 30, 2010
Intended status: Informational Intended status: Informational
Expires: July 23, 2010 Expires: August 3, 2010
ICMP attacks against TCP ICMP attacks against TCP
draft-ietf-tcpm-icmp-attacks-09.txt draft-ietf-tcpm-icmp-attacks-10.txt
Abstract Abstract
This document discusses the use of the Internet Control Message This document discusses the use of the Internet Control Message
Protocol (ICMP) to perform a variety of attacks against the Protocol (ICMP) to perform a variety of attacks against the
Transmission Control Protocol (TCP) and other similar protocols. Transmission Control Protocol (TCP). Additionally, describes a
Additionally, describes a number of widely implemented modifications number of widely implemented modifications to TCP's handling of ICMP
to TCP's handling of ICMP error messages that help to mitigate these error messages that help to mitigate these issues.
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 42 skipping to change at page 1, line 41
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 July 23, 2010. This Internet-Draft will expire on August 3, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 15 skipping to change at page 3, line 15
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 . . . . . . . . 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 . . . . . . . . . . . . . . 15
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Attack-specific counter-measures . . . . . . . . . . . . . 15 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 16
7. Blind performance-degrading attack . . . . . . . . . . . . . . 16 7. Blind performance-degrading attack . . . . . . . . . . . . . . 16
7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Attack-specific counter-measures . . . . . . . . . . . . . 17 7.2. Attack-specific counter-measures . . . . . . . . . . . . . 18
7.3. The counter-measure for the PMTUD attack in action . . . . 21 7.3. The counter-measure for the PMTUD attack in action . . . . 21
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 . . . . . . . . . . 23
7.3.3. Idle connection being attacked . . . . . . . . . . . . 24 7.3.3. Idle connection being attacked . . . . . . . . . . . . 24
7.3.4. Active connection being attacked after discovery 7.3.4. Active connection being attacked after discovery
of the Path-MTU . . . . . . . . . . . . . . . . . . . 25 of the Path-MTU . . . . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . . 32
11.2. Informative 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) . . . . . . . . . . . . . . 35 this document as an RFC) . . . . . . . . . . . . . . 35
A.1. Changes from draft-ietf-tcpm-icmp-attacks-08 . . . . . . . 35 A.1. Changes from draft-ietf-tcpm-icmp-attacks-09 . . . . . . . 35
A.2. Changes from draft-ietf-tcpm-icmp-attacks-07 . . . . . . . 35 A.2. Changes from draft-ietf-tcpm-icmp-attacks-08 . . . . . . . 36
A.3. Changes from draft-ietf-tcpm-icmp-attacks-06 . . . . . . . 35 A.3. Changes from draft-ietf-tcpm-icmp-attacks-07 . . . . . . . 36
A.4. Changes from draft-ietf-tcpm-icmp-attacks-05 . . . . . . . 35 A.4. Changes from draft-ietf-tcpm-icmp-attacks-06 . . . . . . . 36
A.5. Changes from draft-ietf-tcpm-icmp-attacks-04 . . . . . . . 35 A.5. Changes from draft-ietf-tcpm-icmp-attacks-05 . . . . . . . 36
A.6. Changes from draft-ietf-tcpm-icmp-attacks-03 . . . . . . . 36 A.6. Changes from draft-ietf-tcpm-icmp-attacks-04 . . . . . . . 36
A.7. Changes from draft-ietf-tcpm-icmp-attacks-02 . . . . . . . 36 A.7. Changes from draft-ietf-tcpm-icmp-attacks-03 . . . . . . . 36
A.8. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 36 A.8. Changes from draft-ietf-tcpm-icmp-attacks-02 . . . . . . . 36
A.9. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 36 A.9. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 37
A.10. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 37 A.10. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 37
A.11. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 37 A.11. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 37
A.12. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 37 A.12. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 38
A.13. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 38 A.13. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 38
A.14. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 38 A.14. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 38
A.15. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 38 A.15. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 39
A.16. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 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
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. In 2005, official proposal on how to deal with these vulnerabilities. In
a disclosure process was carried out by the UK's National 2005, a disclosure process was carried out by the UK's National
Infrastructure Security Co-ordination Centre (NISCC) (now CPNI, Infrastructure Security Co-ordination Centre (NISCC) (now CPNI,
Centre for the Protection of National Infrastructure), with the Centre for the Protection of National Infrastructure), with the
collaboration of other computer emergency response teams. A large collaboration of other computer emergency response teams. A large
number of implementations were found vulnerable to either all or a number of implementations were found vulnerable to either all or a
subset of the attacks discussed in this document [NISCC][US-CERT]. subset of the attacks discussed in this document [NISCC][US-CERT].
The affected systems ranged from TCP/IP implementations meant for The affected systems ranged from TCP/IP implementations meant for
desktop computers, to TCP/IP implementations meant for core Internet desktop computers, to TCP/IP implementations meant for core Internet
routers. routers.
It is clear that implementations should be more cautious when It is clear that implementations should be more cautious when
skipping to change at page 5, line 43 skipping to change at page 5, line 43
This document aims to raise awareness of the use of ICMP to perform a This document aims to raise awareness of the use of ICMP to perform a
variety of attacks against TCP, and discusses several counter- variety of attacks against TCP, and discusses several counter-
measures that eliminate or minimize the impact of these attacks. measures that eliminate or minimize the impact of these attacks.
Most of the these counter-measures can be implemented while still Most of the these counter-measures can be implemented while still
remaining compliant with the current specifications, as they simply remaining compliant with the current specifications, as they simply
describe reasons for not taking the advice provided in the describe reasons for not taking the advice provided in the
specifications in terms of "SHOULDs", but still comply with the specifications in terms of "SHOULDs", but still comply with the
requirements stated as "MUSTs". requirements stated as "MUSTs".
We note that the counter-measures discussed in this document are not
part of standard TCP behavior and this document does not change that
state of affairs. The consensus of the TCPM WG (TCP Maintenance and
Minor Extensions Working Group) was to document this widespread
implementation of nonstandard TCP behavior but to not change the TCP
standard.
Section 2 provides background information on ICMP. Section 3 Section 2 provides background information on ICMP. Section 3
discusses the constraints in the general counter-measures that can be discusses the constraints in the general counter-measures that can be
implemented against the attacks described in this document. implemented against the attacks described in this document.
Section 4 proposes several general validation checks that can be
Section 4 describes several general validation checks that can be
implemented to mitigate any ICMP-based attack. Finally, Section 5, implemented to mitigate any ICMP-based attack. Finally, Section 5,
Section 6, and Section 7, discuss a variety of ICMP attacks that can Section 6, and Section 7, discuss a variety of ICMP attacks that can
be performed against TCP, and propose attack-specific counter- be performed against TCP, and describe attack-specific counter-
measures that eliminate or greatly mitigate their impact. 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 inform about the network problem taking place.
place. In the same way, there are a number of scenarios in which an In the same way, there are a number of scenarios in which an end-
end-system may generate an ICMP error message if it finds a problem system may generate an ICMP error message if it finds a problem while
while processing a datagram. The received ICMP errors are handed to processing a datagram. The received ICMP errors are handed to the
the corresponding transport-protocol instance, which will usually corresponding transport-protocol instance, which will usually perform
perform a fault recovery function. 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 transmitted
may be discarded due to data corruption, network congestion or rate- unreliably, and may be discarded due to data corruption, network
limiting. Thus, while they provide useful information, upper layer congestion or rate-limiting. Thus, while they provide useful
protocols cannot depend on ICMP for correct operation. information, upper layer protocols cannot depend on ICMP for correct
operation.
It should be noted that are no timeliness requirements for ICMP error It should be noted that are no timeliness requirements for ICMP error
messages. ICMP error messages could be delayed for various reasons, messages. ICMP error messages could be delayed for various reasons,
and at least in theory could be received with an arbitrarily long and at least in theory could be received with an arbitrarily long
delay. For example, there are no existing requirements that a router delay. For example, there are no existing requirements that a router
flushes any queued ICMP error messages when it is rebooted. 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
skipping to change at page 7, line 8 skipping to change at page 7, line 16
The ICMP specification [RFC0792] also defines the ICMP Source Quench The ICMP specification [RFC0792] also defines the ICMP Source Quench
message (type 4, code 0), which is meant to provide a mechanism for message (type 4, code 0), which is meant to provide a mechanism for
flow control and congestion control. flow control and congestion control.
[RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD), [RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD),
which makes use of ICMP error messages of type 3 (Destination which makes use of ICMP error messages of type 3 (Destination
Unreachable), code 4 (fragmentation needed and DF bit set) to allow Unreachable), code 4 (fragmentation needed and DF bit set) to allow
systems to determine the MTU of an arbitrary internet path. systems to determine the MTU of an arbitrary internet path.
Finally, [RFC4884] redefines selected ICMP messages to include an
extension structure and a length attribute, such that those ICMP
messages can carry additional information by encoding that
information in the extension structure.
Appendix D of [RFC4301] provides information about which ICMP error Appendix D of [RFC4301] provides information about which ICMP error
messages are produced by hosts, intermediate routers, or both. messages are produced by hosts, intermediate routers, or both.
2.1.2. ICMP for IP version 6 (ICMPv6) 2.1.2. ICMP for IP version 6 (ICMPv6)
[RFC4443] specifies the Internet Control Message Protocol (ICMPv6) to [RFC4443] specifies the Internet Control Message Protocol (ICMPv6) to
be used with the Internet Protocol version 6 (IPv6) [RFC2460]. be used with the Internet Protocol version 6 (IPv6) [RFC2460].
[RFC4443] defines the "Packet Too Big" (type 2, code 0) error [RFC4443] defines the "Packet Too Big" (type 2, code 0) error
message, that is analogous to the ICMP "fragmentation needed and DF message, that is analogous to the ICMP "fragmentation needed and DF
bit set" (type 3, code 4) error message. [RFC1981] defines the Path bit set" (type 3, code 4) error message. [RFC1981] defines the Path
MTU Discovery mechanism for IP Version 6, that makes use of these MTU Discovery mechanism for IP Version 6, that makes use of these
messages to determine the MTU of an arbitrary internet path. messages to determine the MTU of an arbitrary internet path.
Finally, [RFC4884] redefines selected ICMP messages to include an
extension structure and a length attribute, such that those ICMP
messages can carry additional information by encoding that
information in the extension structure.
Appendix D of [RFC4301] provides information about which ICMPv6 error Appendix D of [RFC4301] provides information about which ICMPv6 error
messages are produced by hosts, intermediate routers, or both. messages are produced by hosts, intermediate routers, or both.
2.2. Handling of ICMP error messages 2.2. Handling of ICMP error messages
The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that a The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that a
TCP MUST act on an ICMP error message passed up from the IP layer, TCP MUST act on an ICMP error message passed up from the IP layer,
directing it to the connection that elicited the error. directing it to the connection that triggered the error.
In order to allow ICMP messages to be demultiplexed by the receiving In order to allow ICMP messages to be demultiplexed by the receiving
system, part of the original packet that elicited the message is system, part of the original packet that triggered the message is
included in the payload of the ICMP error message. Thus, the included in the payload of the ICMP error message. Thus, the
receiving system can use that information to match the ICMP error to receiving system can use that information to match the ICMP error to
the transport protocol instance that elicited it. the transport protocol instance that triggered it.
Neither the Host Requirements RFC [RFC1122] nor the original TCP Neither the Host Requirements RFC [RFC1122] nor the original TCP
specification [RFC0793] recommend any validation checks on the specification [RFC0793] 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 crafted ICMP Therefore, in the case of TCP, an attacker could send a crafted ICMP
error message to the attacked system, and, as long as he is able to error message to the attacked system, and, as long as he is able to
skipping to change at page 9, line 15 skipping to change at page 9, line 33
traffic, and that this control MUST be at the granularity of ICMP traffic, and that this control MUST be at the granularity of ICMP
type and MAY be at the granularity of ICMP type and code. type and MAY be at the granularity of ICMP type and code.
Additionally, an implementation SHOULD incorporate mechanisms and Additionally, an implementation SHOULD incorporate mechanisms and
parameters for dealing with such traffic. parameters for dealing with such traffic.
Thus, the policy to apply for the processing of unprotected ICMP Thus, the policy to apply for the processing of unprotected ICMP
error messages is left up to the implementation and administrator. error messages is left up to the implementation and administrator.
3. Constraints in the possible solutions 3. Constraints in the possible solutions
If a host wants perform validation checks on the received ICMP error
messages before acting on them, it is limited by the piece of the
packet that triggered error that the sender of the ICMP error message
chose to include in the ICMP payload. This contrains the possible
validation checks, as the number of bytes of the packet that
triggered the error message that is included in the ICMP payload is
limited.
For ICMPv4, [RFC0792] states that the IP header plus the first 64 For ICMPv4, [RFC0792] states that the IP header plus the first 64
bits of the packet that elicited the ICMP message are to be included bits of the packet that triggered the ICMP message are to be included
in the payload of the ICMP error message. Thus, it is assumed that in the payload of the ICMP error message. Thus, it is assumed that
all data needed to identify a transport protocol instance and process all data needed to identify a transport protocol instance and process
the ICMP error message is contained in the first 64 bits of the the ICMP error message is contained in the first 64 bits of the
transport protocol header. Section 3.2.2 of [RFC1122] states that transport protocol header. Section 3.2.2 of [RFC1122] states that
"the Internet header and at least the first 8 data octets of the "the Internet header and at least the first 8 data octets of the
datagram that triggered the error" are to be included in the payload datagram that triggered the error" are to be included in the payload
of ICMP error messages, and that "more than 8 octets MAY be sent", of ICMP error messages, and that "more than 8 octets MAY be sent",
thus allowing implementations to include more data from the original thus allowing implementations to include more data from the original
packet than those required by the original ICMP specification. The packet than those required by the original ICMP specification. The
Requirements for IP Version 4 Routers RFC [RFC1812] states that ICMP Requirements for IP Version 4 Routers RFC [RFC1812] states that ICMP
error messages "SHOULD contain as much of the original datagram as error messages "SHOULD contain as much of the original datagram as
possible without the length of the ICMP datagram exceeding 576 possible without the length of the ICMP datagram exceeding 576
bytes". bytes".
Thus, for ICMP messages generated by hosts, we can only expect to get Thus, for ICMP messages generated by hosts, we can only expect to get
the entire IP header of the original packet, plus the first 64 bits the entire IP header of the original packet, plus the first 64 bits
of its payload. For TCP, this means that the only fields that will of its payload. For TCP, this means that the only fields that will
be included in the ICMP payload are: the source port number, the be included in the ICMP payload are: the source port number, the
destination port number, and the 32-bit TCP sequence number. This destination port number, and the 32-bit TCP sequence number. This
clearly imposes a constraint on the possible validation checks that clearly imposes a constraint on the possible validation checks that
can be performed, as there is not much information avalable on which can be performed, as there is not much information available on which
to perform them. to perform them.
This means, for example, that even if TCP were signing its segments This means, for example, that even if TCP were signing its segments
by means of the TCP MD5 signature option [RFC2385], this mechanism by means of the TCP MD5 signature option [RFC2385], this mechanism
could not be used as a counter-measure against ICMP-based attacks, could not be used as a counter-measure against ICMP-based attacks,
because, as ICMP messages include only a piece of the TCP segment because, as ICMP messages include only a piece of the TCP segment
that elicited the error, the MD5 [RFC1321] signature could not be that triggered the error, the MD5 [RFC1321] signature could not be
recalculated. In the same way, even if the attacked peer were recalculated. In the same way, even if the attacked peer were
authenticating its packets at the IP layer [RFC4301], because only a authenticating its packets at the IP layer [RFC4301], because only a
part of the original IP packet would be available, the signature used part of the original IP packet would be available, the signature used
for authentication could not be recalculated, and thus the for authentication could not be recalculated, and thus the
authentication header in the original packet could not be used as a authentication header in the original packet could not be used as a
counter-measure for ICMP-based attacks against TCP. counter-measure for ICMP-based attacks against TCP.
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 triggered the ICMPv6 error message
will fit without making the resulting ICMPv6 error message exceed the as will fit without making the resulting ICMPv6 error message exceed
minimum IPv6 MTU (1280 octets) [RFC4443]. Thus, more information is the minimum IPv6 MTU (1280 octets) [RFC4443]. Thus, more information
available than in the IPv4 case. is available than in the IPv4 case.
Hosts could require ICMP error messages to be authenticated Hosts could require ICMP error messages to be authenticated
[RFC4301], in order to act upon them. However, while this [RFC4301], in order to act upon them. However, while this
requirement could make sense for those ICMP error messages sent by requirement could make sense for those ICMP error messages sent by
hosts, it would not be feasible for those ICMP error messages hosts, it would not be feasible for those ICMP error messages
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 deployment of protocols for one dynamically. Current levels of deployment of protocols for
dynamic establishment of security associations makes this unfeasible. dynamic establishment of security associations makes this unfeasible.
Additionally, this would require routers to use certificates with Additionally, this would require routers to use certificates with
paths compatible for all hosts on the network. Finally, there may be paths compatible for all hosts on the network. Finally, there may be
some scenarios, such as embedded devices, in which the processing some scenarios, such as embedded devices, in which the processing
power requirements of authentication might not allow IPSec power requirements of authentication might not allow IPsec
authentication to be implemented effectively. authentication to be implemented effectively.
4. General counter-measures against ICMP attacks 4. General counter-measures against ICMP attacks
The following subsections describe a number of mitigation techniques The following subsections describe a number of mitigation techniques
that help to eliminate or mitigate the impact of the attacks that help to eliminate or mitigate the impact of the attacks
discussed in this document. Rather than being alternative counter- discussed in this document. Rather than being alternative counter-
measures, they can be implemented together to increase the protection measures, they can be implemented together to increase the protection
against these attacks. against these attacks.
4.1. TCP sequence number checking 4.1. TCP sequence number checking
The current specifications do not impose any validity checks on the The current specifications do not impose any validity checks on the
TCP segment that is contained in the ICMP payload. For instance, no TCP segment that is contained in the ICMP payload. For instance, no
checks are performed to verify that a received ICMP error message has checks are performed to verify that a received ICMP error message has
been elicited by a segment that was "in flight" to the destination. been triggered by a segment that was "in flight" to the destination.
Thus, even stale ICMP error messages will be acted upon. Thus, even stale ICMP error messages will be acted upon.
Many TCP implementations have incorporated a validation check such Many TCP implementations have incorporated a validation check such
that they react only to those ICMP error messages that appear to that they react only to those ICMP error messages that appear to
relate to segments currently "in-flight" to the destination system. relate to segments currently "in-flight" to the destination system.
These implementations check that the TCP sequence number contained in These implementations check that the TCP sequence number contained in
the payload of the ICMP error message is within the range SND.UNA =< the payload of the ICMP error message is within the range 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
skipping to change at page 11, line 45 skipping to change at page 12, line 22
4.2. Port randomization 4.2. Port randomization
As discussed in the previous sections, in order to perform any of the As discussed in the previous sections, in order to perform any of the
attacks described in this document, an attacker would need to guess attacks described in this document, an attacker would need to guess
(or know) the four-tuple that identifies the connection to be (or know) the four-tuple that identifies the connection to be
attacked. Increasing the port number range used for outgoing TCP attacked. Increasing the port number range used for outgoing TCP
connections, and randomizing the port number chosen for each outgoing connections, and randomizing the port number chosen for each outgoing
TCP connections would make it harder for an attacker to perform any TCP 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] recommends that transport
to randomize the ephemeral ports used by clients. protocols randomize the ephemeral ports used by clients, and proposes
a number of randomization algorithms.
4.3. Filtering ICMP error messages based on the ICMP payload 4.3. Filtering ICMP error messages based on the ICMP payload
The source address of ICMP error messages does not need to be spoofed The source address of ICMP error messages does not need to be spoofed
to perform the attacks described in this document, as the ICMP error to perform the attacks described in this document, as the ICMP error
messages might legitimately come from an intermediate system. messages might legitimately come from an intermediate system.
Therefore, simple filtering based on the source address of ICMP error Therefore, simple filtering based on the source address of ICMP error
messages does not serve as a counter-measure against these attacks. messages does not serve as a counter-measure against these attacks.
However, a more advanced packet filtering can be implemented in However, a more advanced packet filtering can be implemented in
middlebox devices such as firewalls and NATs. Middleboxes middlebox devices such as firewalls and NATs. Middleboxes
implementing such advanced filtering look at the payload of the ICMP implementing such advanced filtering look at the payload of the ICMP
error messages, and perform ingress and egress packet filtering based error messages, and perform ingress and egress packet filtering based
on the source IP address of the IP header contained in the payload of on the source IP address of the IP header contained in the payload of
the ICMP error message. As the source IP address contained in the the ICMP error message. As the source IP address contained in the
payload of the ICMP error message does need to be spoofed to perform payload of the ICMP error message does need to be spoofed to perform
the attacks described in this document, this kind of advanced the attacks described in this document, this kind of advanced
skipping to change at page 13, line 25 skipping to change at page 13, line 50
Because of TCP's fault recovery policy, the connection would be Because of TCP's fault recovery policy, the connection would be
immediately aborted. immediately aborted.
Some stacks are known to extrapolate ICMP hard errors across TCP Some stacks are known to extrapolate ICMP hard errors across TCP
connections, increasing the impact of this attack, as a single ICMP connections, increasing the impact of this attack, as a single ICMP
packet could bring down all the TCP connections between the packet could bring down all the TCP connections between the
corresponding peers. corresponding peers.
It is important to note that even if TCP itself were protected It is important to note that even if TCP itself were protected
against the blind connection-reset attack described in [Watson] and against the blind connection-reset attack described in [Watson] and
[I-D.ietf-tcpm-tcpsecure], by means authentication at the network [I-D.ietf-tcpm-tcpsecure], by means of 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],
by means of the TCP-AO [I-D.ietf-tcpm-tcp-auth-opt], or by means of by means of the TCP-AO [I-D.ietf-tcpm-tcp-auth-opt], or by means of
the mechanism proposed in [I-D.ietf-tcpm-tcpsecure], the blind the mechanism specified in [I-D.ietf-tcpm-tcpsecure], the blind
connection-reset attack described in this document would still connection-reset attack described in this document would still
succeed. succeed.
5.2. Attack-specific counter-measures 5.2. Attack-specific counter-measures
An analysis of the circumstances in which ICMP messages that indicate An analysis of the circumstances in which ICMP messages that indicate
hard errors may be received can shed some light to mitigate the hard errors may be received can shed some light to mitigate the
impact of ICMP-based blind connection-reset attacks. impact of ICMP-based blind connection-reset attacks.
ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable) ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable)
skipping to change at page 15, line 28 skipping to change at page 16, line 4
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 transmitted unreliably, transport protocols should not depend on them
functioning. In the event one of these messages were legitimate, the for correct functioning. In the event one of these messages were
corresponding connection would eventually time out. Also, legitimate, the corresponding connection would eventually time out.
applications may still be notified asynchronously about the error Also, applications may still be notified asynchronously about the
contition, and thus may still abort their connections on their own if error condition, and thus may still abort their connections on their
they consider it appropriate. own if they consider it appropriate.
In scenarios such as that in which an intermediate system sets the DF In scenarios such as that in which an intermediate system sets the DF
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, these USER TIMEOUT [RFC0793], losing responsiveness. However, these
scenarios are very unlikely in production environments, and it is scenarios are very unlikely in production environments, and it is
probably preferable to potentially lose responsiveness for the sake probably preferable to potentially lose responsiveness for the sake
of robustness. It should also be noted that applications may still of robustness. It should also be noted that applications may still
be notified asynchronously about the error condition, and thus may be notified asynchronously about the error condition, and thus may
skipping to change at page 18, line 8 skipping to change at page 18, line 32
set" packet (or their ICMPv6 counterpart) to the sending system, set" packet (or their ICMPv6 counterpart) to the sending system,
advertising a small Next-Hop MTU. As a result, the attacked system advertising a small Next-Hop MTU. As a result, the attacked system
would reduce the size of the packets it sends for the corresponding would reduce the size of the packets it sends for the corresponding
connection accordingly. connection accordingly.
The effect of this attack is two-fold. On one hand, it will increase The effect of this attack is two-fold. On one hand, it will increase
the headers/data ratio, thus increasing the overhead needed to send the headers/data ratio, thus increasing the overhead needed to send
data to the remote TCP end-point. On the other hand, if the attacked data to the remote TCP 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 increased processing
(Interrrupt ReQuest) rate and protocol processing time, thus overhead, 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 possible scenario is that in which a TCP connection
is being secured by means of IPSec. If the Next-Hop MTU reported by is being secured by means of IPsec. If the Next-Hop MTU reported by
the attacker is smaller than the amount of bytes needed for headers the attacker is smaller than the amount of bytes needed for headers
(IP and IPSec, in this case), the assumed Path-MTU will not even (IP and IPsec, in this case), the assumed Path-MTU will not even
allow the attacked system to send a single byte of the TCP header allow the attacked system to send a single byte of the TCP header
without fragmentation. This is another scenario that may lead to without fragmentation. This is another scenario that may lead to
unpredictable results. unpredictable results.
For IPv4, the reported Next-Hop MTU could be as 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 Discovery mechanism called The IETF has standardized a Path-MTU Discovery mechanism called
"Packetization Layer Path MTU Discovery" that does not depend on ICMP "Packetization Layer Path MTU Discovery" that does not depend on ICMP
error messages. Implementation of the aforementioned mechanism in error messages. Implementation of the aforementioned mechanism in
skipping to change at page 18, line 41 skipping to change at page 19, line 16
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 Discovery mechanism called The IETF has standardized a Path-MTU Discovery mechanism called
"Packetization Layer Path MTU Discovery" that does not depend on ICMP "Packetization Layer Path MTU Discovery" 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]) eliminates this vulnerability. However, it can also lead
also lead to an increase of the PMTUD convergence time. 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 incorporated in
variety of TCP implementations to improve TCP's resistance to the OpenBSD and NetBSD (since 2005) to improve TCP's resistance to the
blind performance-degrading attack described in Section 7.1. The blind performance-degrading attack described in Section 7.1. The
described mechanism basically disregards ICMP messages when a described mechanism basically disregards ICMP messages when a
connection makes progress. This modification does not violate any of connection makes progress, without violating any of the requirements
the requirements stated in [RFC1191] and [RFC1981]. stated in [RFC1191] and [RFC1981].
Henceforth, we will refer to both ICMP "fragmentation needed and DF Henceforth, we will refer to both 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,
these implementations include a modification to TCP's reaction to these implementations include a modification to TCP's reaction to
ICMP "Packet Too Big" error messages that disregards them when a ICMP "Packet Too Big" error messages that disregards them when a
connection makes progress, and honors them only after the connection makes progress, and honors them only after the
corresponding data have been retransmitted a specified number of corresponding data have been retransmitted a specified number of
skipping to change at page 20, line 13 skipping to change at page 20, line 35
maxsizesent. maxsizesent.
maxsizesent holds the size (in octets) of the largest packet that has maxsizesent holds the size (in octets) of the largest packet that has
so far been sent for this connection. It is initialized to 68 (the so far been sent for this connection. It is initialized to 68 (the
minimum IPv4 MTU) when the underlying internet protocol is IPv4, and minimum IPv4 MTU) when the underlying internet protocol is IPv4, and
is initialized to 1280 (the minimum IPv6 MTU) when the underlying is initialized to 1280 (the minimum IPv6 MTU) when the underlying
internet protocol is IPv6. Whenever a packet larger than maxsizesent internet protocol is IPv6. Whenever a packet larger than maxsizesent
octets is sent, maxsizesent is set to that value. octets is sent, maxsizesent is set to that value.
On the other hand, maxsizeacked holds the size (in octets) of the On the other hand, maxsizeacked holds the size (in octets) of the
largest packet that has so far been acknowledged for this connection. largest packet (data, plus headers) that has so far been acknowledged
It is initialized to 68 (the minimum IPv4 MTU) when the underlying for this connection. It is initialized to 68 (the minimum IPv4 MTU)
internet protocol is IPv4, and is initialized to 1280 (the minimum when the underlying internet protocol is IPv4, and is initialized to
IPv6 MTU) when the underlying internet protocol is IPv6. Whenever an 1280 (the minimum IPv6 MTU) when the underlying internet protocol is
acknowledgement for a packet larger than maxsizeacked octets is IPv6. Whenever an acknowledgement for a packet larger than
received, maxsizeacked is set to the size of that acknowledged maxsizeacked octets is received, maxsizeacked is set to the size of
packet. that acknowledged packet. Note that because of TCP's cumulative
acknowledgement, a single ACK may acknowledge the receipt of more
than one packet. When that happens, the algorithm may "incorrectly"
asume it is in the "Path-MTU Update" stage, rather than the "Initial
Path-MTU Discovery" stage (as described bellow).
Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop
MTU claimed by the ICMP message (henceforth "claimedmtu") is compared MTU claimed by the ICMP message (henceforth "claimedmtu") is compared
with maxsizesent. If claimedmtu is larger than maxsizesent, then the with maxsizesent. If claimedmtu is larger than maxsizesent, then the
ICMP error message is silently discarded. The rationale for this is ICMP error message is silently discarded. The rationale for this is
that the ICMP error message cannot be legitimate if it claims to have that the ICMP error message cannot be legitimate if it claims to have
been elicited by a packet larger than the largest packet we have so been triggered by a packet larger than the largest packet we have so
far sent for this connection. far sent for this connection.
If this check is passed, claimedmtu is compared with maxsizeacked. If this check is passed, claimedmtu is compared with maxsizeacked.
If claimedmtu is equal to or larger than maxsizeacked, TCP is If claimedmtu is equal to or larger than maxsizeacked, TCP is
supposed to be at the Initial Path-MTU Discovery stage, and thus the supposed to be at the Initial Path-MTU Discovery stage, and thus the
ICMP "Packet Too Big" error message is honored immediately. That is, ICMP "Packet Too Big" error message is honored immediately. That is,
the assumed Path-MTU is updated according to the Next-Hop MTU claimed the assumed Path-MTU is updated according to the Next-Hop MTU claimed
in the ICMP error message. Also, maxsizesent is reset to the minimum in the ICMP error message. Also, maxsizesent is reset to the minimum
MTU of the internet protocol in use (68 for IPv4, and 1280 for IPv6). MTU of the internet protocol in use (68 for IPv4, and 1280 for IPv6).
On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is
supposed to be in the Path-MTU Update stage. At this stage, these supposed to be in the Path-MTU Update stage. At this stage, these
implementations are more cautious with the errors being reported by implementations are more cautious with the errors being reported by
the network, and therefore just record the received error message, the network, and therefore just record the received error message,
and delay the update of the assumed Path-MTU. and delay the update of the assumed Path-MTU.
To perform this delay, one new variable and one new parameter is To perform this delay, one new variable and one new parameter is
introduced to TCP: nsegrto and MAXSEGRTO. nsegrto holds the number of introduced to TCP: nsegrto and MAXSEGRTO. nsegrto holds the number of
times a specified segment has timed out. It is initialized to zero, times a specified segment has timed out. It is initialized to zero,
and is incremented by one every time the corresponding segment times and is incremented by one every time the corresponding segment times
out. MAXSEGRRTO specifies the number of times a given segment must out. MAXSEGRTO specifies the number of times a given segment must
timeout before an ICMP "Packet Too Big" error message can be honored, timeout before an ICMP "Packet Too Big" error message can be honored,
and can be set, in principle, to any value greater than or equal to and can be set, in principle, 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 corresponding error pending ICMP "Packet Too Big" error message, the corresponding error
message is processed. At that point, maxsizeacked is set to message is processed. At that point, maxsizeacked is set to
claimedmtu, and maxsizesent is set to 68 (for IPv4) or 1280 (for claimedmtu, and maxsizesent is set to 68 (for IPv4) or 1280 (for
IPv6). IPv6).
skipping to change at page 21, line 20 skipping to change at page 21, line 47
TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK
that acknowledges that sequence number is received), then the that acknowledges that sequence number is received), then the
"pending error" condition is cleared. "pending error" condition is cleared.
The rationale behind performing this delayed processing of ICMP The rationale behind performing this delayed processing of ICMP
"Packet Too Big" messages is that if there is progress on the "Packet Too Big" messages is that if there is progress on the
connection, the ICMP "Packet Too Big" errors must be a false claim. connection, the ICMP "Packet Too Big" errors must be a false claim.
By checking for progress on the connection, rather than just for By checking for progress on the connection, rather than just for
staleness of the received ICMP messages, TCP is protected from attack staleness of the received ICMP messages, TCP is protected from attack
even if the offending ICMP messages are "in window", and as a even if the offending ICMP messages are "in window", and as a
corollary, is made more robust to spurious ICMP messages elicited by, corollary, is made more robust to spurious ICMP messages triggered
for example, corrupted TCP segments. by, for example, corrupted TCP segments.
MAXSEGRTO can be set, in principle, to any value greater than or MAXSEGRTO can be set, in principle, to any value greater than or
equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the
traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A
MAXSEGRTO of 1 provides enough protection for most cases. In any MAXSEGRTO of 1 provides enough protection for most cases. In any
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. Both OpenBSD and NetBSD set MAXSEGRTO to 1.
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.
Section 7.3 shows the proposed counter-measure in action. Section 7.3 shows this counter-measure in action. Section 7.4 shows
Section 7.4 shows the proposed counter-measure in pseudo-code. this counter-measure in pseudo-code.
This behavior has been implemented in NetBSD [NetBSD] and OpenBSD
[OpenBSD] since 2005.
It is important to note that the mechanism proposed in this section It is important to note that the mechanism described in this section
is an improvement to the current Path-MTU discovery mechanism, to is an improvement to the current Path-MTU discovery mechanism, to
mitigate its security implications. The current PMTUD mechanism, as mitigate its security implications. The current PMTUD mechanism, as
specified by [RFC1191] and [RFC1981], still suffers from some specified by [RFC1191] and [RFC1981], still suffers from some
functionality problems [RFC2923] that this document does not aim to functionality problems [RFC2923] that this document does not aim to
address. A mechanism that addresses those issues is described in address. A mechanism that addresses those issues is described in
[RFC4821]. [RFC4821].
7.3. The counter-measure for the PMTUD attack in action 7.3. The counter-measure for the PMTUD attack in action
This SECTION shows the proposed counter-measure for the ICMP attack This section illustrates the operation of the counter-measure for the
against the PMTUD mechanism in action. It shows both how the fix ICMP attack against the PMTUD mechanism that has been implemented in
protects TCP from being attacked and how the counter-measure works in OpenBSD and NetBSD . It shows both how the fix protects TCP from
normal scenarios. As discussed in Section 7.2, this section assumes being attacked and how the counter-measure works in normal scenarios.
the PMTUD-specific counter-measure is implemented in addition to the As discussed in Section 7.2, this section assumes the PMTUD-specific
TCP sequence number checking described in Section 4.1. counter-measure is implemented in addition to the 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
PMTU is assumed to be 1500 octets, TCP will send segments that PMTU is assumed to be 1500 octets, TCP will send segments that
contain, at most, 1460 octets of data. contain, at most, 1460 octets of data.
skipping to change at page 22, line 36 skipping to change at page 23, line 14
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 | | H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
MTU=4464 MTU=2048 MTU=1500 MTU=4464 MTU=4464 MTU=2048 MTU=1500 MTU=4464
Figure 1: Hypothetical scenario Figure 1: Hypothetical scenario
7.3.1. Normal operation for bulk transfers 7.3.1. Normal operation for bulk transfers
This subsection shows the proposed counter-measure in normal This subsection shows the counter-measure in normal operation, when a
operation, when a TCP connection is used for bulk transfers. That TCP connection is used for bulk transfers. That is, it shows how the
is, it shows how the proposed counter-measure works when there is no counter-measure works when there is no attack taking place, and a TCP
attack taking place, and a TCP connection is used for transferring connection is used for transferring large amounts of data. This
large amounts of data. This section assumes that just after the section assumes that just after the connection is established, one of
connection is established, one of the TCP endpoints begins to the TCP endpoints begins to transfer data in packets that are as
transfer data in packets that are as large as possible. large as possible.
Host 1 Host 2 Host 1 Host 2
1. --> <SEQ=100><CTL=SYN> --> 1. --> <SEQ=100><CTL=SYN> -->
2. <-- <SEQ=X><ACK=101><CTL=SYN,ACK> <-- 2. <-- <SEQ=X><ACK=101><CTL=SYN,ACK> <--
3. --> <SEQ=101><ACK=X+1><CTL=ACK> --> 3. --> <SEQ=101><ACK=X+1><CTL=ACK> -->
4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=4424> --> 4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=4424> -->
5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1 5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1
6. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=2008> --> 6. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=2008> -->
7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2 7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2
skipping to change at page 24, line 30 skipping to change at page 24, line 48
7.3.2. Operation during Path-MTU changes 7.3.2. Operation during Path-MTU changes
Let us suppose a TCP connection between H1 and H2 has already been Let us suppose a TCP connection between H1 and H2 has already been
established, and that the PMTU for the connection has already been established, and that the PMTU for the connection has already been
discovered to be 1500. At this point, both maxsizesent and discovered to be 1500. At this point, both maxsizesent and
maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose
some time later the PMTU decreases to 1492. For simplicity, let us some time later the PMTU decreases to 1492. For simplicity, let us
suppose that the Path-MTU has decreased because the MTU of the link suppose that the Path-MTU has decreased because the MTU of the link
between R2 and R3 has decreased from 1500 to 1492. Figure 3 between R2 and R3 has decreased from 1500 to 1492. Figure 3
illustrates how the proposed counter-measure would work in this illustrates how the counter-measure would work in this scenario.
scenario.
Host 1 Host 2 Host 1 Host 2
1. (Path-MTU decreases) 1. (Path-MTU decreases)
2. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1500> --> 2. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1500> -->
3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2 3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2
4. (Segment times out) 4. (Segment times out)
5. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1452> --> 5. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1452> -->
6. <-- <SEQ=X><ACK=1552><CTL=ACK> <-- 6. <-- <SEQ=X><ACK=1552><CTL=ACK> <--
skipping to change at page 30, line 43 skipping to change at page 31, line 14
if (pending_message && nsegrto >= MAXSEGRTO){ if (pending_message && nsegrto >= MAXSEGRTO){
adjust_mtu(); adjust_mtu();
nsegrto = 0; nsegrto = 0;
pending_message = 0; pending_message = 0;
maxsizeacked = claimedmtu; maxsizeacked = claimedmtu;
maxsizesent = MINIMUM_MTU; maxsizesent = MINIMUM_MTU;
current_mtu = claimedmtu; current_mtu = claimedmtu;
} }
Notes: Notes:
All comparisions between sequence numbers must be performed using All comparisons between sequence numbers must be performed using
sequence number arithmethic. sequence number arithmetic.
The pseudo-code implements the mechanism described in Section 7.2, The pseudo-code implements the mechanism described in Section 7.2,
the TCP sequence number checking described in Section 4.1, and the the TCP sequence number checking described in Section 4.1, and the
validation check on the advertised Next-Hop MTU described in validation check on the advertised Next-Hop MTU described in
[RFC1191] and [RFC1981]. [RFC1191] and [RFC1981].
8. Security Considerations 8. Security Considerations
This document describes the use of ICMP error messages to perform a This document describes the use of ICMP error messages to perform a
number of attacks against the TCP protocol, and describes a number of number of attacks against 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
skipping to change at page 32, line 19 skipping to change at page 32, line 37
9. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. The RFC-Editor can remove This document has no actions for IANA. The RFC-Editor can remove
this section before publication of this document as an RFC. this section before publication of this document as an RFC.
10. Acknowledgements 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 [RFC5461] by private e-mail. The author would like issues related to [RFC5461] by private e-mail. The author would like
to thank (in alphabetical order): Bora Akyol, Mark Allman, Ran to thank (in alphabetical order): Bora Akyol, Mark Allman, Ran
Atkinson, James Carlson, Alan Cox, Theo de Raadt, Wesley Eddy, Ted Atkinson, James Carlson, Alan Cox, Theo de Raadt, Wesley Eddy, Lars
Faber, Juan Fraschini, Markus Friedl, Guillermo Gont, John Heffner, Eggert, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo Gont,
Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, Mika Liljeberg, Matt John Heffner, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, Mika
Mathis, David Miller, Toby Moncaster, Miles Nordin, Eloy Paris, Liljeberg, Matt Mathis, David Miller, Toby Moncaster, Miles Nordin,
Kacheong Poon, Andrew Powell, Pekka Savola, Donald Smith, Pyda Eloy Paris, Kacheong Poon, Andrew Powell, Pekka Savola, Donald Smith,
Srisuresh, Fred Templin, and Joe Touch for contributing many valuable Pyda Srisuresh, Fred Templin, and Joe Touch for contributing many
comments. valuable comments.
Juan Fraschini and the author of this document implemented freely- Juan Fraschini and the author of this document implemented freely-
available audit tools to help vendors audit their systems by available audit tools to help vendors audit their systems by
reproducing the attacks discussed in this document. This tools are reproducing the attacks discussed in this document. 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 33, line 40 skipping to change at page 34, line 12
[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.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
April 2007.
11.2. Informative References 11.2. Informative References
[CPNI-TCP] [CPNI-TCP]
CPNI, "Security Assessment of the Transmission Control CPNI, "Security Assessment of the Transmission Control
Protocol (TCP)", http://www.cpni.gov.uk/Docs/ Protocol (TCP)", http://www.cpni.gov.uk/Docs/
tn-03-09-security-assessment-TCP.pdf, 2009. tn-03-09-security-assessment-TCP.pdf, 2009.
[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.
skipping to change at page 36, line 20 skipping to change at page 36, line 44
[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-08 A.1. Changes from draft-ietf-tcpm-icmp-attacks-09
o Addresses AD review comments by Lars Eggert (hopefully :-) ).
A.2. Changes from draft-ietf-tcpm-icmp-attacks-08
o Fixes a couple of nits found by... Alfred!. Thanks! (again, and o Fixes a couple of nits found by... Alfred!. Thanks! (again, and
again, and again....). again, and again....).
A.2. Changes from draft-ietf-tcpm-icmp-attacks-07 A.3. Changes from draft-ietf-tcpm-icmp-attacks-07
o Addresses some remaining WGLC feedback sent off-list by Donald o Addresses some remaining WGLC feedback sent off-list by Donald
Smith and Guillermo Gont. Smith and Guillermo Gont.
A.3. Changes from draft-ietf-tcpm-icmp-attacks-06 A.4. Changes from draft-ietf-tcpm-icmp-attacks-06
o Addresses WGLC feedback by Joe Touch and Donald Smith. o Addresses WGLC feedback by Joe Touch and Donald Smith.
A.4. Changes from draft-ietf-tcpm-icmp-attacks-05 A.5. 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.5. Changes from draft-ietf-tcpm-icmp-attacks-04 A.6. 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.6. Changes from draft-ietf-tcpm-icmp-attacks-03 A.7. 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.7. Changes from draft-ietf-tcpm-icmp-attacks-02 A.8. 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 (particularly 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 Miscellaneous editorial changes.
A.8. Changes from draft-ietf-tcpm-icmp-attacks-01 A.9. 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.9. Changes from draft-ietf-tcpm-icmp-attacks-00 A.10. 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 analysis
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 a 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 errors
o Miscellaneous editorial changes o Miscellaneous editorial changes
A.10. Changes from draft-gont-tcpm-icmp-attacks-05 A.11. 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.11. Changes from draft-gont-tcpm-icmp-attacks-04 A.12. 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.12. Changes from draft-gont-tcpm-icmp-attacks-03 A.13. 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 described
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 counter-measure for the attack against the PMTUD was improved
improved and simplified and simplified
o Section 7.4 was added o Section 7.4 was added
o Miscellaneous editorial changes o Miscellaneous editorial changes
A.13. Changes from draft-gont-tcpm-icmp-attacks-02 A.14. 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 counter-measure for the attack against the PMTUD mechanism was
mechanism was refined to allow quick discovery of the Path-MTU 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.14. Changes from draft-gont-tcpm-icmp-attacks-01 A.15. 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.15. Changes from draft-gont-tcpm-icmp-attacks-00 A.16. 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. 79 change blocks. 
152 lines changed or deleted 187 lines changed or added

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