summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5927.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5927.txt')
-rw-r--r--doc/rfc/rfc5927.txt2019
1 files changed, 2019 insertions, 0 deletions
diff --git a/doc/rfc/rfc5927.txt b/doc/rfc/rfc5927.txt
new file mode 100644
index 0000000..7e6b77a
--- /dev/null
+++ b/doc/rfc/rfc5927.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) F. Gont
+Request for Comments: 5927 UTN/FRH
+Category: Informational July 2010
+ISSN: 2070-1721
+
+
+ ICMP Attacks against TCP
+
+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). Additionally, this document
+ 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
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5927.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont Informational [Page 1]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ 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 Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont Informational [Page 2]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5
+ 2.1.1. ICMP for IP version 4 (ICMPv4) . . . . . . . . . . . . 5
+ 2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6
+ 2.2. Handling of ICMP Error Messages . . . . . . . . . . . . . 6
+ 2.3. Handling of ICMP Error Messages in the Context of IPsec . 7
+ 3. Constraints in the Possible Solutions . . . . . . . . . . . . 8
+ 4. General Counter-Measures against ICMP Attacks . . . . . . . . 10
+ 4.1. TCP Sequence Number Checking . . . . . . . . . . . . . . . 10
+ 4.2. Port Randomization . . . . . . . . . . . . . . . . . . . . 11
+ 4.3. Filtering ICMP Error Messages Based on the ICMP Payload . 11
+ 5. Blind Connection-Reset Attack . . . . . . . . . . . . . . . . 12
+ 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 13
+ 6. Blind Throughput-Reduction Attack . . . . . . . . . . . . . . 16
+ 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 16
+ 7. Blind Performance-Degrading Attack . . . . . . . . . . . . . . 16
+ 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16
+ 7.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 18
+ 7.3. The Counter-Measure for the PMTUD Attack in Action . . . . 22
+ 7.3.1. Normal Operation for Bulk Transfers . . . . . . . . . 22
+ 7.3.2. Operation during Path-MTU Changes . . . . . . . . . . 24
+ 7.3.3. Idle Connection Being Attacked . . . . . . . . . . . . 25
+ 7.3.4. Active Connection Being Attacked after Discovery
+ of the Path-MTU . . . . . . . . . . . . . . . . . . . 26
+ 7.3.5. TCP Peer Attacked when Sending Small Packets Just
+ after the Three-Way Handshake . . . . . . . . . . . . 26
+ 7.4. Pseudo-Code for the Counter-Measure for the Blind
+ Performance-Degrading Attack . . . . . . . . . . . . . . . 27
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 33
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont Informational [Page 3]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+1. Introduction
+
+ ICMP [RFC0792] [RFC4443] is a fundamental part of the TCP/IP protocol
+ suite, and is used mainly for reporting network error conditions.
+ However, the current specifications do not recommend any kind of
+ validation checks on the received ICMP error messages, thus allowing
+ a variety of attacks against TCP [RFC0793] by means of ICMP, which
+ include blind connection-reset, blind throughput-reduction, and blind
+ performance-degrading attacks. All of these attacks can be performed
+ even when the attacker is off-path, without the need to sniff the
+ packets that correspond to the attacked TCP connection.
+
+ While the possible security implications of ICMP have been known in
+ the research community for a long time, there has never been an
+ official proposal on how to deal with these vulnerabilities. In
+ 2005, a disclosure process was carried out by the UK's National
+ Infrastructure Security Co-ordination Centre (NISCC) (now CPNI,
+ Centre for the Protection of National Infrastructure), with the
+ collaboration of other computer emergency response teams. A large
+ number of implementations were found vulnerable to either all or a
+ subset of the attacks discussed in this document [NISCC][US-CERT].
+ The affected systems ranged from TCP/IP implementations meant for
+ desktop computers, to TCP/IP implementations meant for core Internet
+ routers.
+
+ It is clear that implementations should be more cautious when
+ processing ICMP error messages, to eliminate or mitigate the use of
+ ICMP to perform attacks against TCP [RFC4907].
+
+ This document aims to raise awareness of the use of ICMP to perform a
+ variety of attacks against TCP, and discusses several counter-
+ measures that eliminate or minimize the impact of these attacks.
+ Most of the these counter-measures can be implemented while still
+ remaining compliant with the current specifications, as they simply
+ describe reasons for not taking the advice provided in the
+ specifications in terms of "SHOULDs", but still comply with the
+ 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
+ discusses the constraints in the general counter-measures that can be
+ implemented against the attacks described in this document.
+
+
+
+Gont Informational [Page 4]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ Section 4 describes several general validation checks that can be
+ implemented to mitigate any ICMP-based attack. Finally, Section 5,
+ Section 6, and Section 7, discuss a variety of ICMP attacks that can
+ be performed against TCP, and describe attack-specific counter-
+ measures that eliminate or greatly mitigate their impact.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2. Background
+
+2.1. The Internet Control Message Protocol (ICMP)
+
+ The Internet Control Message Protocol (ICMP) is used in the Internet
+ architecture mainly to perform the fault-isolation function, that is,
+ the group of actions that hosts and routers take to determine that
+ there is some network failure [RFC0816].
+
+ When an intermediate router detects a network problem while trying to
+ forward an IP packet, it will usually send an ICMP error message to
+ the source system, to inform the source system of the network problem
+ taking place. In the same way, there are a number of scenarios in
+ which an end-system may generate an ICMP error message if it finds a
+ problem while processing a datagram. The received ICMP errors are
+ handed to the corresponding transport-protocol instance, which will
+ usually perform a fault recovery function.
+
+ It is important to note that ICMP error messages are transmitted
+ unreliably and may be discarded due to data corruption, network
+ congestion, or rate-limiting. Thus, while they provide useful
+ information, upper-layer protocols cannot depend on ICMP for correct
+ operation.
+
+ It should be noted that there 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 flush any queued ICMP error messages when it is rebooted.
+
+2.1.1. ICMP for IP version 4 (ICMPv4)
+
+ [RFC0792] specifies the Internet Control Message Protocol (ICMP) to
+ be used with the Internet Protocol version 4 (IPv4) -- henceforth
+ "ICMPv4". It defines, among other things, a number of error messages
+ that can be used by end-systems and intermediate systems to report
+ errors to the sending system. The Host Requirements RFC [RFC1122]
+
+
+
+
+Gont Informational [Page 5]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ classifies ICMPv4 error messages into those that indicate "soft
+ errors", and those that indicate "hard errors", thus roughly defining
+ the semantics of them.
+
+ The ICMPv4 specification [RFC0792] also defines the ICMPv4 Source
+ Quench message (type 4, code 0), which is meant to provide a
+ mechanism for flow control and congestion control.
+
+ [RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD),
+ which makes use of ICMPv4 error messages of type 3 (Destination
+ Unreachable), code 4 (fragmentation needed and DF bit set) to allow
+ systems to determine the MTU of an arbitrary internet path.
+
+ Finally, [RFC4884] redefines selected ICMPv4 messages to include an
+ extension structure and a length attribute, such that those ICMPv4
+ messages can carry additional information by encoding that
+ information in the extension structure.
+
+ Appendix D of [RFC4301] provides information about which ICMPv4 error
+ messages are produced by hosts, intermediate routers, or both.
+
+2.1.2. ICMP for IP version 6 (ICMPv6)
+
+ [RFC4443] specifies the Internet Control Message Protocol (ICMPv6) to
+ be used with the Internet Protocol version 6 (IPv6) [RFC2460].
+
+ [RFC4443] defines the "Packet Too Big" (type 2, code 0) error
+ message, which is analogous to the ICMPv4 "fragmentation needed and
+ DF bit set" (type 3, code 4) error message. [RFC1981] defines the
+ Path MTU Discovery mechanism for IP version 6, which makes use of
+ these messages to determine the MTU of an arbitrary internet path.
+
+ Finally, [RFC4884] redefines selected ICMPv6 messages to include an
+ extension structure and a length attribute, such that those ICMPv6
+ messages can carry additional information by encoding that
+ information in the extension structure.
+
+ Appendix D of [RFC4301] provides information about which ICMPv6 error
+ messages are produced by hosts, intermediate routers, or both.
+
+2.2. Handling of ICMP Error Messages
+
+ The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that
+ TCP MUST act on an ICMP error message passed up from the IP layer,
+ directing it to the connection that triggered the error.
+
+
+
+
+
+
+Gont Informational [Page 6]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ In order to allow ICMP messages to be demultiplexed by the receiving
+ system, part of the original packet that triggered the message is
+ included in the payload of the ICMP error message. Thus, the
+ receiving system can use that information to match the ICMP error to
+ the transport protocol instance that triggered it.
+
+ Neither the Host Requirements RFC [RFC1122] nor the original TCP
+ specification [RFC0793] recommends any validation checks on the
+ received ICMP messages. Thus, as long as the ICMP payload contains
+ the information that identifies an existing communication instance,
+ it will be processed by the corresponding transport-protocol
+ instance, and the corresponding action will be performed.
+
+ 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
+ guess the four-tuple (i.e., Source IP Address, Source TCP port,
+ Destination IP Address, and Destination TCP port) that identifies the
+ communication instance to be attacked, he will be able to use ICMP to
+ perform a variety of attacks.
+
+ Generally, the four-tuple required to perform these attacks is not
+ known. However, as discussed in [Watson] and [RFC4953], there are a
+ number of scenarios (notably that of TCP connections established
+ 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
+ such a case, if we assume the attacker knows the two systems involved
+ in the TCP connection to be attacked, both the client-side and the
+ server-side IP addresses could be known or be within a reasonable
+ number of possibilities. Furthermore, as most Internet services use
+ the so-called "well-known" ports, only the client port number might
+ need to be guessed. In such a scenario, an attacker would need to
+ send, in principle, at most 65536 packets to perform any of the
+ attacks described in this document. These issues are exacerbated by
+ the fact that most systems choose the port numbers they use for
+ outgoing connections from a subset of the whole port number space,
+ thus reducing the amount of work needed to successfully perform these
+ attacks.
+
+ The need to be more cautious when processing received ICMP error
+ messages in order to mitigate or eliminate the impact of the attacks
+ described in this RFC has been documented by the Internet
+ Architecture Board (IAB) in [RFC4907].
+
+2.3. Handling of ICMP Error Messages in the Context of IPsec
+
+ Section 5.2 of [RFC4301] describes the processing of inbound IP
+ traffic in the case of "unprotected-to-protected". In the case of
+ ICMP, when an unprotected ICMP error message is received, it is
+
+
+
+Gont Informational [Page 7]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ matched to the corresponding security association by means of the SPI
+ (Security Parameters Index) included in the payload of the ICMP error
+ message. Then, local policy is applied to determine whether to
+ accept or reject the message and, if accepted, what action to take as
+ a result. For example, if an ICMP Destination Unreachable message is
+ received, the implementation must decide whether to act on it, reject
+ it, or act on it with constraints. Section 8 ("Path MTU/DF
+ Processing") discusses the processing of unauthenticated ICMPv4
+ "fragmentation needed and DF bit set" (type 3, code 4) and ICMPv6
+ "Packet Too Big" (type 2, code 0) messages when an IPsec
+ implementation is configured to process (vs. ignore) such messages.
+
+ Section 6.1.1 of [RFC4301] notes that processing of unauthenticated
+ ICMP error messages may result in denial or degradation of service,
+ and therefore it would be desirable to ignore such messages.
+ However, it also notes that in many cases, ignoring these ICMP
+ messages can degrade service, e.g., because of a failure to process
+ PMTUD and redirection messages, and therefore there is also a
+ motivation for accepting and acting upon them. It finally states
+ that to accommodate both ends of this spectrum, a compliant IPsec
+ implementation MUST permit a local administrator to configure an
+ IPsec implementation to accept or reject unauthenticated ICMP
+ traffic, and that this control MUST be at the granularity of ICMP
+ type and MAY be at the granularity of ICMP type and code.
+ Additionally, an implementation SHOULD incorporate mechanisms and
+ parameters for dealing with such traffic.
+
+ Thus, the policy to apply for the processing of unprotected ICMP
+ error messages is left up to the implementation and administrator.
+
+3. Constraints in the Possible Solutions
+
+ If a host wants to perform validation checks on the received ICMP
+ error messages before acting on them, it is limited by the piece of
+ the packet that triggered the error that the sender of the ICMP error
+ message chose to include in the ICMP payload. This constrains 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 bits of the packet that triggered the ICMPv4 message are to be
+ included in the payload of the ICMPv4 error message. Thus, it is
+ assumed that all data needed to identify a transport protocol
+ instance and process the ICMPv4 error message is contained in the
+ first 64 bits of the transport protocol header. Section 3.2.2 of
+ [RFC1122] states that "the Internet header and at least the first 8
+ data octets of the datagram that triggered the error" are to be
+
+
+
+Gont Informational [Page 8]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ included in the payload of ICMPv4 error messages, and that "more than
+ 8 octets MAY be sent", thus allowing implementations to include more
+ data from the original packet than those required by the original
+ ICMPv4 specification. The "Requirements for IP Version 4 Routers"
+ RFC [RFC1812] states that ICMPv4 error messages "SHOULD contain as
+ much of the original datagram as possible without the length of the
+ ICMP datagram exceeding 576 bytes".
+
+ Thus, for ICMPv4 messages generated by hosts, we can only expect to
+ get 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 be included in the ICMPv4 payload are the source port
+ number, the destination port number, and the 32-bit TCP sequence
+ number. This clearly imposes a constraint on the possible validation
+ checks that can be performed, as there is not much information
+ available on which to perform them.
+
+ This means, for example, that even if TCP were signing its segments
+ by means of the TCP MD5 signature option [RFC2385], this mechanism
+ could not be used as a counter-measure against ICMP-based attacks,
+ because, as ICMP messages include only a piece of the TCP segment
+ that triggered the error, the MD5 [RFC1321] signature could not be
+ recalculated. In the same way, even if the attacked peer were
+ authenticating its packets at the IP layer [RFC4301], because only a
+ part of the original IP packet would be available, the signature used
+ for authentication could not be recalculated, and thus the
+ authentication header in the original packet could not be used as a
+ counter-measure for ICMP-based attacks against TCP.
+
+ [RFC4884] updated [RFC0792] and specified that ICMPv4 Destination
+ Unreachable (type 3), Time Exceeded (type 11), and Parameter Problem
+ (type 12) messages that have an ICMP Extension Structure appended
+ include at least 128 octets in the "original datagram" field. This
+ would improve the situation, but at the time of this writing,
+ [RFC4884] is not yet widely deployed for end-systems.
+
+ For IPv6, the payload of ICMPv6 error messages includes as many
+ octets from the IPv6 packet that triggered the ICMPv6 error message
+ as will fit without making the resulting ICMPv6 error message exceed
+ the minimum IPv6 MTU (1280 octets) [RFC4443]. Thus, more information
+ is available than in the IPv4 case.
+
+ Hosts could require ICMP error messages to be authenticated
+ [RFC4301], in order to act upon them. However, while this
+ requirement could make sense for those ICMP error messages sent by
+ hosts, it would not be feasible for those ICMP error messages
+ generated by routers, as this would imply either that the attacked
+ system should have a security association [RFC4301] with every
+
+
+
+Gont Informational [Page 9]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ existing intermediate system, or that it should be able to establish
+ one dynamically. Current levels of deployment of protocols for
+ dynamic establishment of security associations makes this unfeasible.
+ Additionally, this would require routers to use certificates with
+ paths compatible for all hosts on the network. Finally, there may be
+ some scenarios, such as embedded devices, in which the processing
+ power requirements of authentication might not allow IPsec
+ authentication to be implemented effectively.
+
+4. General Counter-Measures against ICMP Attacks
+
+ The following subsections describe a number of mitigation techniques
+ that help to eliminate or mitigate the impact of the attacks
+ discussed in this document. Rather than being alternative counter-
+ measures, they can be implemented together to increase the protection
+ against these attacks.
+
+4.1. TCP Sequence Number Checking
+
+ The current specifications do not impose any validity checks on the
+ TCP segment that is contained in the ICMP payload. For instance, no
+ checks are performed to verify that a received ICMP error message has
+ been triggered by a segment that was "in flight" to the destination.
+ Thus, even stale ICMP error messages will be acted upon.
+
+ Many TCP implementations have incorporated a validation check such
+ that they react only to those ICMP error messages that appear to
+ relate to segments currently "in flight" to the destination system.
+ These implementations check that the TCP sequence number contained in
+ the payload of the ICMP error message is within the range
+ SND.UNA =< 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 acknowledged. If an ICMP error message does not pass this check,
+ it is discarded.
+
+ Even if an attacker were able to guess the four-tuple that identifies
+ the TCP connection, this additional check would reduce the
+ possibility of considering a spoofed ICMP packet as valid to
+ Flight_Size/2^^32 (where Flight_Size is the number of data bytes
+ already sent to the remote peer, but not yet acknowledged [RFC5681]).
+ For connections in the SYN-SENT or SYN-RECEIVED states, this would
+ reduce the possibility of considering a spoofed ICMP packet as valid
+ to 1/2^^32. For a TCP endpoint with no data "in flight", this would
+ completely eliminate the possibility of success of these attacks.
+
+ This validation check has been implemented in Linux [Linux] for many
+ years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and
+ NetBSD [NetBSD] since 2005.
+
+
+
+Gont Informational [Page 10]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ It is important to note that while this check greatly increases the
+ number of packets required to perform any of the attacks discussed in
+ this document, this may not be enough in those scenarios in which
+ bandwidth is easily available and/or large TCP windows [RFC1323] are
+ in use. Additionally, this validation check does not help to prevent
+ on-path attacks, that is, attacks performed in scenarios in which the
+ attacker can sniff the packets that correspond to the target TCP
+ connection.
+
+ It should be noted that, as there are no timeliness requirements for
+ ICMP error messages, the TCP Sequence Number check described in this
+ 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 wraps around).
+
+4.2. Port Randomization
+
+ As discussed in the previous sections, in order to perform any of the
+ attacks described in this document, an attacker would need to guess
+ (or know) the four-tuple that identifies the connection to be
+ attacked. Increasing the port number range used for outgoing TCP
+ connections, and randomizing the port number chosen for each outgoing
+ TCP connection, would make it harder for an attacker to perform any
+ of the attacks discussed in this document.
+
+ [PORT-RANDOM] recommends that transport 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
+
+ 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
+ messages might legitimately come from an intermediate system.
+ Therefore, simple filtering based on the source address of ICMP error
+ messages does not serve as a counter-measure against these attacks.
+ However, a more advanced packet filtering can be implemented in
+ middlebox devices such as firewalls and NATs. Middleboxes
+ implementing such advanced filtering look at the payload of the ICMP
+ error messages, and perform ingress and egress packet filtering based
+ on the source address of the IP header contained in the payload of
+ the ICMP error message. As the source address contained in the
+ payload of the ICMP error message does need to be spoofed to perform
+ the attacks described in this document, this kind of advanced
+ filtering serves as a counter-measure against these attacks. As with
+ traditional egress filtering [IP-filtering], egress filtering based
+ on the ICMP payload can help to prevent users of the network being
+
+
+
+Gont Informational [Page 11]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ protected by the firewall from successfully performing ICMP attacks
+ against TCP connections established between external systems.
+ Additionally, ingress filtering based on the ICMP payload can prevent
+ TCP connections established between internal systems from being
+ attacked by external systems. [ICMP-Filtering] provides examples of
+ ICMP filtering based on the ICMP payload.
+
+ This filtering technique has been implemented in OpenBSD's Packet
+ Filter [OpenBSD-PF], which has in turn been ported to a number of
+ systems, including FreeBSD [FreeBSD].
+
+5. Blind Connection-Reset Attack
+
+5.1. Description
+
+ When TCP is handed an ICMP error message, it will perform its fault
+ recovery function, as follows:
+
+ o If the network problem being reported is a "hard error", TCP will
+ abort the corresponding connection.
+
+ o If the network problem being reported is a "soft error", TCP will
+ just record this information, and repeatedly retransmit its data
+ until they either get acknowledged, or the connection times out.
+
+ The Host Requirements RFC [RFC1122] states (in Section 4.2.3.9) that
+ a host SHOULD abort the corresponding connection when receiving an
+ ICMPv4 error message that indicates a "hard error", and states that
+ ICMPv4 error messages of type 3 (Destination Unreachable), codes 2
+ (protocol unreachable), 3 (port unreachable), and 4 (fragmentation
+ needed and DF bit set) should be considered as indicating "hard
+ errors". In the case of ICMPv4 port unreachables, the specifications
+ are ambiguous, as Section 4.2.3.9 of [RFC1122] states that TCP SHOULD
+ abort the corresponding connection in response to them, but
+ Section 3.2.2.1 of the same RFC ([RFC1122]) states that TCP MUST
+ abort the connection in response to them.
+
+ While [RFC4443] did not exist when [RFC1122] was published, one could
+ extrapolate the concept of "hard errors" to ICMPv6 error messages of
+ type 1 (Destination Unreachable), codes 1 (communication with
+ destination administratively prohibited), and 4 (port unreachable).
+
+ Thus, an attacker could use ICMP to perform a blind connection-reset
+ attack by sending any ICMP error message that indicates a "hard
+ error" to either of the two TCP endpoints of the connection. Because
+ of TCP's fault recovery policy, the connection would be immediately
+ aborted.
+
+
+
+
+Gont Informational [Page 12]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ Some stacks are known to extrapolate ICMP "hard errors" across TCP
+ connections, increasing the impact of this attack, as a single ICMP
+ packet could bring down all the TCP connections between the
+ corresponding peers.
+
+ It is important to note that even if TCP itself were protected
+ against the blind connection-reset attack described in [Watson] and
+ [TCPM-TCPSECURE] by means of authentication at the network layer
+ [RFC4301], by means of the TCP MD5 signature option [RFC2385], by
+ means of the TCP-AO [RFC5925], or by means of the mechanism specified
+ in [TCPM-TCPSECURE], the blind connection-reset attack described in
+ this document would still succeed.
+
+5.2. Attack-Specific Counter-Measures
+
+ An analysis of the circumstances in which ICMP messages that indicate
+ "hard errors" may be received can shed some light on opportunities to
+ mitigate the impact of ICMP-based blind connection-reset attacks.
+
+ ICMPv4 type 3 (Destination Unreachable), code 2 (protocol
+ unreachable)
+
+ This ICMP error message indicates that the host sending the ICMP
+ error message received a packet meant for a transport protocol it
+ does not support. For connection-oriented protocols such as TCP,
+ one could expect to receive such an error as the result of a
+ connection-establishment attempt. However, it would be strange to
+ get such an error during the life of a connection, as this would
+ indicate that support for that transport protocol has been removed
+ from the system sending the error message during the life of the
+ corresponding connection.
+
+ ICMPv4 type 3 (Destination Unreachable), code 3 (port unreachable)
+
+ This error message indicates that the system sending the ICMP
+ error message received a packet meant for a socket (IP address,
+ port number) on which there is no process listening. Those
+ transport protocols that have their own mechanisms for signaling
+ this condition should not be receiving these error messages, as
+ the protocol would signal the port unreachable condition by means
+ of its own mechanisms. Assuming that once a connection is
+ established it is not usual for the transport protocol to change
+ (or be reloaded), it should be unusual to get these error
+ messages.
+
+ ICMPv4 type 3 (Destination Unreachable), code 4 (fragmentation needed
+ and DF bit set)
+
+
+
+
+Gont Informational [Page 13]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ This error message indicates that an intermediate node needed to
+ fragment a datagram, but the DF (Don't Fragment) bit in the IP
+ header was set. It is considered a "soft error" when TCP
+ implements PMTUD, and a "hard error" if TCP does not implement
+ PMTUD. Those TCP/IP stacks that do not implement PMTUD (or have
+ disabled it) but support IP fragmentation/reassembly should not be
+ sending their IP packets with the DF bit set, and thus should not
+ be receiving these ICMP error messages. Some TCP/IP stacks that
+ do not implement PMTUD and that do not support IP fragmentation/
+ reassembly are known to send their packets with the DF bit set,
+ and thus could legitimately receive these ICMP error messages.
+
+ ICMPv6 type 1 (Destination Unreachable), code 1 (communication with
+ destination administratively prohibited)
+
+ This error message indicates that the destination is unreachable
+ because of an administrative policy. For connection-oriented
+ protocols such as TCP, one could expect to receive such an error
+ as the result of a connection-establishment attempt. Receiving
+ such an error for a connection in any of the synchronized states
+ would mean that the administrative policy changed during the life
+ of the connection. However, in the same way this error condition
+ (which was not present when the connection was established)
+ appeared, it could get solved in the near term.
+
+ ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable)
+
+ This error message is analogous to the ICMPv4 type 3 (Destination
+ Unreachable), code 3 (port unreachable) error message discussed
+ above. Therefore, the same considerations apply.
+
+ The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that
+ TCP SHOULD abort the corresponding connection in response to ICMPv4
+ messages of type 3 (Destination Unreachable), codes 2 (protocol
+ unreachable), 3 (port unreachable), and 4 (fragmentation needed and
+ DF bit set). However, Section 3.2.2.1 states that TCP MUST accept an
+ ICMPv4 port unreachable (type 3, code 3) for the same purpose as a
+ RST. Therefore, for ICMPv4 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 ICMPv4 messages of type 3,
+ code 3, there is ambiguity in the specifications that may or may not
+ provide some room to go against that advice.
+
+ Based on this analysis, most popular TCP implementations treat all
+ ICMP "hard errors" received for connections in any of the
+ synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
+ CLOSING, LAST-ACK, or TIME-WAIT) as "soft errors". That is, they do
+ not abort the corresponding connection upon receipt of them.
+
+
+
+Gont Informational [Page 14]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ Additionally, they do not extrapolate ICMP errors across TCP
+ connections. This policy is based on the premise that TCP should be
+ as robust as possible. Aborting the connection would be to ignore
+ the valuable feature of the Internet -- that for many internal
+ failures, it reconstructs its function without any disruption of the
+ endpoints [RFC0816].
+
+ It should be noted that treating ICMP "hard errors" as "soft errors"
+ for connections in any of the synchronized states may prevent TCP
+ from responding quickly to a legitimate ICMP error message.
+
+ It is interesting to note that, as ICMP error messages are
+ transmitted unreliably, transport protocols should not depend on them
+ for correct functioning. In the event one of these messages were
+ legitimate, the corresponding connection would eventually time out.
+ Also, applications may still be notified asynchronously about the
+ error condition, and thus may still abort their connections on their
+ own if they consider it appropriate.
+
+ In scenarios such as that in which an intermediate system sets the DF
+ bit in the segments transmitted by a TCP that does not implement
+ PMTUD, or the TCP at one of the endpoints of the connection is
+ dynamically disabled, TCP would only abort the connection after a
+ USER TIMEOUT [RFC0793], losing responsiveness. However, these
+ scenarios are very unlikely in production environments, and it is
+ probably preferable to potentially lose responsiveness for the sake
+ of robustness. It should also be noted that applications may still
+ be notified asynchronously about the error condition, and thus may
+ still abort their connections on their own if they consider it
+ appropriate.
+
+ In scenarios of multipath routing or route changes, failures in some
+ (but not all) of the paths may elicit ICMP error messages that would
+ likely not cause a connection abort if any of the counter-measures
+ described in this section were implemented. However, aborting the
+ connection would be to ignore the valuable feature of the Internet --
+ that for many internal failures, it reconstructs its function without
+ any disruption of the endpoints [RFC0816]. That is, communication
+ should survive if there is still a working path to the destination
+ system [DClark]. Additionally, applications may still be notified
+ asynchronously about the error condition, and thus may still abort
+ their connections on their own if they consider it appropriate.
+
+ This counter-measure has been implemented in BSD-derived TCP/IP
+ implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more
+ than ten years [Wright][McKusick]. The Linux kernel has also
+ implemented this policy for more than ten years [Linux].
+
+
+
+
+Gont Informational [Page 15]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+6. Blind Throughput-Reduction Attack
+
+6.1. Description
+
+ The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that
+ hosts MUST react to ICMPv4 Source Quench messages by slowing
+ transmission on the connection. Thus, an attacker could send ICMPv4
+ Source Quench (type 4, code 0) messages to a TCP endpoint to make it
+ reduce the rate at which it sends data to the other endpoint of the
+ connection. [RFC1122] further adds that the RECOMMENDED procedure is
+ to put the corresponding connection in the slow-start phase of TCP's
+ congestion control algorithm [RFC5681]. In the case of those
+ implementations that use an initial congestion window of one segment,
+ a sustained attack would reduce the throughput of the attacked
+ connection to about SMSS (Sender Maximum Segment Size) [RFC5681]
+ bytes per RTT (round-trip time). The throughput achieved during an
+ attack might be a little higher if a larger initial congestion window
+ is in use [RFC3390].
+
+6.2. Attack-Specific Counter-Measures
+
+ As discussed in the "Requirements for IP Version 4 Routers" RFC
+ [RFC1812], research seems to suggest that ICMPv4 Source Quench
+ messages are an ineffective (and unfair) antidote for congestion.
+ [RFC1812] further states that routers SHOULD NOT send ICMPv4 Source
+ Quench messages in response to congestion. Furthermore, TCP
+ implements its own congestion control mechanisms ([RFC5681]
+ [RFC3168]) that do not depend on ICMPv4 Source Quench messages.
+
+ Based on this reasoning, a large number of implementations completely
+ ignore ICMPv4 Source Quench messages meant for TCP connections. This
+ behavior has been implemented in, at least, Linux [Linux] since 2004,
+ and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD]
+ since 2005. However, it must be noted that this behavior violates
+ the requirement in [RFC1122] to react to ICMPv4 Source Quench
+ messages by slowing transmission on the connection.
+
+7. Blind Performance-Degrading Attack
+
+7.1. Description
+
+ When one IP system has a large amount of data to send to another
+ system, the data will be transmitted as a series of IP datagrams. It
+ is usually preferable that these datagrams be of the largest size
+ that does not require fragmentation anywhere along the path from the
+ source to the destination. This datagram size is referred to as the
+ Path MTU (PMTU) and is equal to the minimum of the MTUs of each hop
+ in the path. A technique called "Path MTU Discovery" (PMTUD) lets IP
+
+
+
+Gont Informational [Page 16]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ systems determine the Path MTU of an arbitrary internet path.
+ [RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and
+ IPv6, respectively.
+
+ The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the
+ IP header to dynamically discover the Path MTU. The basic idea
+ 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
+ with the DF bit set. If any of the datagrams is too large to be
+ forwarded without fragmentation by some intermediate router, the
+ router will discard the corresponding datagram and will return an
+ ICMPv4 "Destination Unreachable, fragmentation needed and DF set"
+ (type 3, code 4) error message to the sending system. This message
+ will report the MTU of the constricting hop, so that the sending
+ system can reduce the assumed Path-MTU accordingly.
+
+ For IPv6, intermediate systems do not fragment packets. Thus,
+ 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
+ fragmentation by some intermediate router, the router will discard
+ the corresponding datagram, and will return an ICMPv6 "Packet Too
+ Big" (type 2, code 0) error message to the sending system. This
+ message will report the MTU of the constricting hop, so that the
+ sending system can reduce the assumed Path-MTU accordingly.
+
+ As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery
+ mechanism can be used to attack TCP. An attacker could send a
+ crafted ICMPv4 "Destination Unreachable, fragmentation needed and DF
+ set" packet (or their ICMPv6 counterpart) to the sending 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
+ connection accordingly.
+
+ 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
+ data to the remote TCP endpoint. On the other hand, if the attacked
+ system wanted to keep the same throughput it was achieving before
+ being attacked, it would have to increase the packet rate. On
+ virtually all systems, this will lead to an increased processing
+ overhead, thus degrading the overall system performance.
+
+ A particular scenario that may take place is one in which an attacker
+ reports a Next-Hop MTU smaller than or equal to the amount of bytes
+ needed for headers (IP header, plus TCP header). For example, if the
+ attacker reports a Next-Hop MTU of 68 bytes, and the amount of bytes
+ used for headers (IP header, plus TCP header) is larger than
+ 68 bytes, the assumed Path-MTU will not even allow the attacked
+ system to send a single byte of application data without
+
+
+
+Gont Informational [Page 17]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ fragmentation. This particular scenario might lead to unpredictable
+ results. Another possible scenario is one in which a TCP connection
+ is being secured by means of IPsec. If the Next-Hop MTU reported by
+ the attacker is smaller than the amount of bytes needed for headers
+ (IP and IPsec, in this case), the assumed Path-MTU will not even
+ allow the attacked system to send a single byte of the TCP header
+ without fragmentation. This is another scenario that may lead to
+ unpredictable results.
+
+ For IPv4, the reported Next-Hop MTU could be as small as 68 octets,
+ as [RFC0791] requires every internet module to be able to forward a
+ datagram of 68 octets without further fragmentation. For IPv6, while
+ the required minimum IPv6 MTU is 1280, the reported Next-Hop MTU can
+ be smaller than 1280 octets [RFC2460]. If the reported Next-Hop MTU
+ is smaller than the minimum IPv6 MTU, the receiving host is not
+ required to reduce the Path-MTU to a value smaller than 1280, but is
+ required to include a fragmentation header in the outgoing packets to
+ that destination from that moment on.
+
+7.2. Attack-Specific Counter-Measures
+
+ The IETF has standardized a Path-MTU Discovery mechanism called
+ "Packetization Layer Path MTU Discovery" (PLPMTUD) that does not
+ depend on ICMP error messages. Implementation of the aforementioned
+ mechanism in replacement of the traditional PMTUD (specified in
+ [RFC1191] and [RFC1981]) eliminates this vulnerability. However, it
+ can also lead to an increase in PMTUD convergence time.
+
+ This section describes a modification to the PMTUD mechanism
+ specified in [RFC1191] and [RFC1981] that has been incorporated in
+ OpenBSD and NetBSD (since 2005) to improve TCP's resistance to the
+ blind performance-degrading attack described in Section 7.1. The
+ described counter-measure basically disregards ICMP messages when a
+ connection makes progress, without violating any of the requirements
+ stated in [RFC1191] and [RFC1981].
+
+ Henceforth, we will refer to both ICMPv4 "fragmentation needed and DF
+ bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too
+ Big" messages.
+
+ In addition to the general validation check described in Section 4.1,
+ these implementations include a modification to TCP's reaction to
+ ICMP "Packet Too Big" error messages that disregards them when a
+ connection makes progress, and honors them only after the
+ corresponding data have been retransmitted a specified number of
+ times. This means that upon receipt of an ICMP "Packet Too Big"
+
+
+
+
+
+Gont Informational [Page 18]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ error message, TCP just records this information, and honors it only
+ when the corresponding data have already been retransmitted a
+ specified number of times.
+
+ While this basic policy would greatly mitigate the impact of the
+ attack against the PMTUD mechanism, it would also mean that it might
+ take TCP more time to discover the Path-MTU for a TCP connection.
+ This would be particularly annoying for connections that have just
+ been established, as it might take TCP several transmission attempts
+ (and the corresponding timeouts) before it discovers the PMTU for the
+ corresponding connection. Thus, this policy would increase the time
+ it takes for data to begin to be received at the destination host.
+
+ In order to protect TCP from the attack against the PMTUD mechanism,
+ while still allowing TCP to quickly determine the initial Path-MTU
+ for a connection, the aforementioned implementations have divided the
+ traditional PMTUD mechanism into two stages: Initial Path-MTU
+ Discovery and Path-MTU Update.
+
+ The Initial Path-MTU Discovery stage is when TCP tries to send
+ segments that are larger than the ones that have so far been sent and
+ acknowledged for this connection. That is, in the Initial Path-MTU
+ Discovery stage, TCP has no record of these large segments getting to
+ the destination host, and thus these implementations believe the
+ network when it reports that these packets are too large to reach the
+ destination host without being fragmented.
+
+ The Path-MTU Update stage is when TCP tries to send segments that are
+ equal to or smaller than the ones that have already been sent and
+ acknowledged for this connection. During the Path-MTU Update stage,
+ TCP already has knowledge of the estimated Path-MTU for the given
+ connection. Thus, in this case, these implementations are more
+ cautious with the errors being reported by the network.
+
+ In order to allow TCP to distinguish segments between those
+ performing Initial Path-MTU Discovery and those performing Path-MTU
+ Update, two new variables are introduced to TCP: maxsizesent and
+ maxsizeacked.
+
+ The maxsizesent variable holds the size (in octets) of the largest
+ packet that has so far been sent for this connection. It is
+ initialized to 68 (the minimum IPv4 MTU) when the underlying Internet
+ Protocol is IPv4, and is initialized to 1280 (the minimum IPv6 MTU)
+ when the underlying Internet Protocol is IPv6. Whenever a packet
+ larger than maxsizesent octets is sent, maxsizesent is set to that
+ value.
+
+
+
+
+
+Gont Informational [Page 19]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ On the other hand, maxsizeacked holds the size (in octets) of the
+ largest packet (data, plus headers) that has so far been acknowledged
+ for this connection. It is initialized to 68 (the minimum IPv4 MTU)
+ when the underlying Internet Protocol is IPv4, and is initialized to
+ 1280 (the minimum IPv6 MTU) when the underlying Internet Protocol is
+ IPv6. Whenever an acknowledgement for a packet larger than
+ maxsizeacked octets is received, maxsizeacked is set to the size of
+ 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"
+ assume it is in the "Path-MTU Update" stage, rather than the "Initial
+ Path-MTU Discovery" stage (as described below).
+
+ Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop
+ MTU claimed by the ICMP message (henceforth "claimedmtu") is compared
+ with maxsizesent. If claimedmtu is larger than maxsizesent, then the
+ ICMP error message is silently discarded. The rationale for this is
+ that the ICMP error message cannot be legitimate if it claims to have
+ been triggered by a packet larger than the largest packet we have so
+ far sent for this connection.
+
+ If this check is passed, claimedmtu is compared with maxsizeacked.
+ If claimedmtu is equal to or larger than maxsizeacked, TCP is
+ supposed to be at the Initial Path-MTU Discovery stage, and thus the
+ ICMP "Packet Too Big" error message is honored immediately. That is,
+ the assumed Path-MTU is updated according to the Next-Hop MTU claimed
+ in the ICMP error message. Also, maxsizesent is reset to the minimum
+ MTU of the Internet Protocol in use (68 for IPv4, and 1280 for IPv6).
+
+ On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is
+ supposed to be in the Path-MTU Update stage. At this stage, these
+ implementations are more cautious with the errors being reported by
+ the network, and therefore just record the received error message,
+ and delay the update of the assumed Path-MTU.
+
+ To perform this delay, one new variable and one new parameter are
+ introduced to TCP: nsegrto and MAXSEGRTO. The nsegrto variable holds
+ the number of times a specified segment has timed out. It is
+ initialized to zero, and is incremented by one every time the
+ corresponding segment times out. MAXSEGRTO specifies the number of
+ times a given segment must time out 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 0.
+
+
+
+
+
+
+
+
+Gont Informational [Page 20]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a
+ pending ICMP "Packet Too Big" error message, the corresponding error
+ message is processed. At that point, maxsizeacked is set to
+ claimedmtu, and maxsizesent is set to 68 (for IPv4) or 1280 (for
+ IPv6).
+
+ If, while there is a pending ICMP "Packet Too Big" error message, the
+ TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK
+ that acknowledges that sequence number is received), then the
+ "pending error" condition is cleared.
+
+ The rationale behind performing this delayed processing of ICMP
+ "Packet Too Big" messages is that if there is progress on the
+ connection, the ICMP "Packet Too Big" errors must be a false claim.
+ By checking for progress on the connection, rather than just for
+ staleness of the received ICMP messages, TCP is protected from attack
+ even if the offending ICMP messages are "in window", and as a
+ corollary, is made more robust to spurious ICMP messages triggered
+ by, for example, corrupted TCP segments.
+
+ MAXSEGRTO can be set, in principle, to any value greater than or
+ equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the
+ traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A
+ MAXSEGRTO of 1 provides enough protection for most cases. In any
+ case, implementations are free to choose higher values for this
+ constant. MAXSEGRTO could be a function of the Next-Hop MTU claimed
+ in the received ICMP "Packet Too Big" message. That is, higher
+ values for MAXSEGRTO could be imposed when the received ICMP "Packet
+ Too Big" message claims a Next-Hop MTU that is smaller than some
+ specified value. Both OpenBSD and NetBSD set MAXSEGRTO to 1.
+
+ 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
+ could consider TCP to always be in the Path-MTU Update stage, thus
+ always delaying the update of the assumed Path-MTU.
+
+ Section 7.3 shows this counter-measure in action. Section 7.4 shows
+ this counter-measure in pseudo-code.
+
+ It is important to note that the mechanism described in this section
+ is an improvement to the current Path-MTU discovery mechanism, to
+ mitigate its security implications. The current PMTUD mechanism, as
+ specified by [RFC1191] and [RFC1981], still suffers from some
+ functionality problems [RFC2923] that this document does not aim to
+ address. A mechanism that addresses those issues is described in
+ [RFC4821].
+
+
+
+
+
+Gont Informational [Page 21]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+7.3. The Counter-Measure for the PMTUD Attack in Action
+
+ This section illustrates the operation of the counter-measure for the
+ ICMP attack against the PMTUD mechanism that has been implemented in
+ OpenBSD and NetBSD. It shows both how the fix protects TCP from
+ being attacked and how the counter-measure works in normal scenarios.
+ As discussed in Section 7.2, this section assumes the PMTUD-specific
+ counter-measure is implemented in addition to the TCP sequence number
+ checking described in Section 4.1.
+
+ Figure 1 illustrates a hypothetical scenario in which two hosts are
+ connected by means of three intermediate routers. It also shows the
+ MTU of each hypothetical hop. All the following subsections assume
+ the network setup of this figure.
+
+ Also, for simplicity's sake, all subsections assume an IP header of
+ 20 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
+ contain, at most, 1460 octets of data.
+
+ For simplicity's sake, all the following subsections assume the TCP
+ implementation at Host 1 (H1) has chosen a MAXSEGRTO of 1.
+
+ +----+ +----+ +----+ +----+ +----+
+ | H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 |
+ +----+ +----+ +----+ +----+ +----+
+ MTU=4464 MTU=2048 MTU=1500 MTU=4464
+
+ Figure 1: Hypothetical Scenario
+
+7.3.1. Normal Operation for Bulk Transfers
+
+ This subsection shows the counter-measure in normal operation, when a
+ TCP connection is used for bulk transfers. That is, it shows how the
+ counter-measure works when there is no attack taking place and a TCP
+ connection is used for transferring large amounts of data. This
+ section assumes that just after the connection is established, one of
+ the TCP endpoints begins to transfer data in packets that are as
+ large as possible.
+
+
+
+
+
+
+
+
+
+
+
+
+Gont Informational [Page 22]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ Host 1 Host 2
+
+ 1. --> <SEQ=100><CTL=SYN> -->
+ 2. <-- <SEQ=X><ACK=101><CTL=SYN,ACK> <--
+ 3. --> <SEQ=101><ACK=X+1><CTL=ACK> -->
+ 4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=4424> -->
+ 5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1
+ 6. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=2008> -->
+ 7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2
+ 8. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=1460> -->
+ 9. <-- <SEQ=X+1><ACK=1561><CTL=ACK> <--
+
+ Figure 2: Normal Operation for Bulk Transfers
+
+ The nsegrto variable is initialized to zero. Both maxsizeacked and
+ maxsizesent are initialized to the minimum MTU for the Internet
+ Protocol being used (68 for IPv4, and 1280 for IPv6).
+
+ In lines 1 to 3, the three-way handshake takes place, and the
+ connection is established. In line 4, H1 tries to send a full-sized
+ TCP segment. As described by [RFC1191] and [RFC1981], in this case,
+ TCP will try to send a segment with 4424 bytes of data, which will
+ result in an IP packet of 4464 octets. Therefore, maxsizesent is set
+ to 4464. When the packet reaches R1, it elicits an ICMP "Packet Too
+ Big" error message.
+
+ In line 5, H1 receives the ICMP error message, which reports a Next-
+ Hop MTU of 2048 octets. After performing the TCP sequence number
+ check described in Section 4.1, the Next-Hop MTU reported by the ICMP
+ error message (claimedmtu) is compared with maxsizesent. As it is
+ smaller than maxsizesent, it passes the check, and thus is then
+ compared with maxsizeacked. As claimedmtu is larger than
+ maxsizeacked, TCP assumes that the corresponding TCP segment was
+ performing the Initial PMTU Discovery. Therefore, the TCP at H1
+ honors the ICMP message by updating the assumed Path-MTU. The
+ maxsizesent variable is reset to the minimum MTU of the Internet
+ Protocol in use (68 for IPv4, and 1280 for IPv6).
+
+ In line 6, the TCP at H1 sends a segment with 2008 bytes of data,
+ which results in an IP packet of 2048 octets. The maxsizesent
+ variable is thus set to 2008 bytes. When the packet reaches R2, it
+ elicits an ICMP "Packet Too Big" error message.
+
+ In line 7, H1 receives the ICMP error message, which reports a Next-
+ Hop MTU of 1500 octets. After performing the TCP sequence number
+ check, the Next-Hop MTU reported by the ICMP error message
+ (claimedmtu) is compared with maxsizesent. As it is smaller than
+ maxsizesent, it passes the check, and thus is then compared with
+
+
+
+Gont Informational [Page 23]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ maxsizeacked. As claimedmtu is larger than maxsizeacked, TCP assumes
+ that the corresponding TCP segment was performing the Initial PMTU
+ Discovery. Therefore, the TCP at H1 honors the ICMP message by
+ updating the assumed Path-MTU. The maxsizesent variable is reset to
+ the minimum MTU of the Internet Protocol in use.
+
+ In line 8, the TCP at H1 sends a segment with 1460 bytes of data,
+ which results in an IP packet of 1500 octets. Thus, maxsizesent is
+ set to 1500. This packet reaches H2, where it elicits an
+ acknowledgement (ACK) segment.
+
+ In line 9, H1 finally gets the acknowledgement for the data segment.
+ As the corresponding packet was larger than maxsizeacked, TCP updates
+ maxsizeacked, setting it to 1500. At this point, TCP has discovered
+ the Path-MTU for this TCP connection.
+
+7.3.2. Operation during Path-MTU Changes
+
+ Let us suppose a TCP connection between H1 and H2 has already been
+ established, and that the PMTU for the connection has already been
+ discovered to be 1500. At this point, both maxsizesent and
+ maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose
+ 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
+ between R2 and R3 has decreased from 1500 to 1492. Figure 3
+ illustrates how the counter-measure would work in this scenario.
+
+ Host 1 Host 2
+
+ 1. (Path-MTU decreases)
+ 2. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1460> -->
+ 3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2
+ 4. (Segment times out)
+ 5. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1452> -->
+ 6. <-- <SEQ=X><ACK=1552><CTL=ACK> <--
+
+ Figure 3: Operation during Path-MTU Changes
+
+ In line 1, the Path-MTU for this connection decreases from 1500 to
+ 1492. In line 2, the TCP at H1, without being aware of the Path-MTU
+ change, sends a 1500-byte packet to H2. When the packet reaches R2,
+ it elicits an ICMP "Packet Too Big" error message.
+
+ In line 3, H1 receives the ICMP error message, which reports a Next-
+ Hop MTU of 1492 octets. After performing the TCP sequence number
+ check, the Next-Hop MTU reported by the ICMP error message
+ (claimedmtu) is compared with maxsizesent. As claimedmtu is smaller
+ than maxsizesent, it is then compared with maxsizeacked. As
+
+
+
+Gont Informational [Page 24]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ claimedmtu is smaller than maxsizeacked (full-sized packets were
+ getting to the remote endpoint), this packet is assumed to be
+ performing Path-MTU Update, and a "pending error" condition is
+ recorded.
+
+ In line 4, the segment times out. Thus, nsegrto is incremented by 1.
+ As nsegrto is greater than or equal to MAXSEGRTO, the assumed Path-
+ MTU is updated. The nsegrto variable is reset to 0, maxsizeacked is
+ set to claimedmtu, and maxsizesent is set to the minimum MTU of the
+ Internet Protocol in use.
+
+ In line 5, H1 retransmits the data using the updated PMTU, and thus
+ maxsizesent is set to 1492. The resulting packet reaches H2, where
+ it elicits an acknowledgement (ACK) segment.
+
+ In line 6, H1 finally gets the acknowledgement for the data segment.
+ At this point, TCP has discovered the new Path-MTU for this TCP
+ connection.
+
+7.3.3. Idle Connection Being Attacked
+
+ Let us suppose a TCP connection between H1 and H2 has already been
+ established, and the PMTU for the connection has already been
+ discovered to be 1500. Figure 4 shows a sample time-line diagram
+ that illustrates an idle connection being attacked.
+
+ Host 1 Host 2
+
+ 1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=50> -->
+ 2. <-- <SEQ=X><ACK=150><CTL=ACK> <--
+ 3. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
+ 4. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
+ 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
+
+ Figure 4: Idle Connection Being Attacked
+
+ In line 1, H1 sends its last bunch of data. In line 2, H2
+ acknowledges the receipt of these data. Then the connection becomes
+ idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet
+ Too Big" error messages to H1. Regardless of how many packets it
+ sends and of the TCP sequence number each ICMP packet includes, none
+ of these ICMP error messages will pass the TCP sequence number check
+ described in Section 4.1, as H1 has no unacknowledged data "in
+ flight" to H2. Therefore, the attack does not succeed.
+
+
+
+
+
+
+
+Gont Informational [Page 25]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+7.3.4. Active Connection Being Attacked after Discovery of the Path-MTU
+
+ Let us suppose an attacker attacks a TCP connection for which the
+ PMTU has already been discovered. In this case, as illustrated in
+ Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a
+ possible packet exchange.
+
+ Host 1 Host 2
+
+ 1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1460> -->
+ 2. --> <SEQ=1560><ACK=X><CTL=ACK><DATA=1460> -->
+ 3. --> <SEQ=3020><ACK=X><CTL=ACK><DATA=1460> -->
+ 4. --> <SEQ=4480><ACK=X><CTL=ACK><DATA=1460> -->
+ 5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
+ 6. <-- <SEQ=X><CTL=ACK><ACK=1560> <--
+
+ Figure 5: Active Connection Being Attacked after Discovery of PMTU
+
+ As we assume the PMTU has already been discovered, we also assume
+ both maxsizesent and maxsizeacked are equal to 1500. We assume
+ nsegrto is equal to zero, as there have been no segment timeouts.
+
+ In lines 1, 2, 3, and 4, H1 sends four data segments to H2. In
+ line 5, an attacker sends a forged ICMP error message to H1. We
+ assume the attacker is lucky enough to guess both the four-tuple that
+ identifies the connection and a valid TCP sequence number. As the
+ Next-Hop MTU claimed in the ICMP "Packet Too Big" message
+ (claimedmtu) is smaller than maxsizeacked, this packet is assumed to
+ be performing Path-MTU Update. Thus, the error message is recorded.
+
+ In line 6, H1 receives an acknowledgement for the segment sent in
+ line 1, before it times out. At this point, the "pending error"
+ condition is cleared, and the recorded ICMP "Packet Too Big" error
+ message is ignored. Therefore, the attack does not succeed.
+
+7.3.5. TCP Peer Attacked when Sending Small Packets Just after the
+ Three-Way Handshake
+
+ This section analyzes a scenario in which a TCP peer that is sending
+ small segments just after the connection has been established is
+ attacked. The connection could be in use by protocols such as SMTP
+ [RFC5321] and HTTP [RFC2616], for example, which usually behave like
+ this.
+
+ Figure 6 shows a possible packet exchange for such a scenario.
+
+
+
+
+
+
+Gont Informational [Page 26]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ Host 1 Host 2
+
+ 1. --> <SEQ=100><CTL=SYN> -->
+ 2. <-- <SEQ=X><ACK=101><CTL=SYN,ACK> <--
+ 3. --> <SEQ=101><ACK=X+1><CTL=ACK> -->
+ 4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=100> -->
+ 5. <-- <SEQ=X+1><ACK=201><CTL=ACK> <--
+ 6. --> <SEQ=201><ACK=X+1><CTL=ACK><DATA=100> -->
+ 7. --> <SEQ=301><ACK=X+1><CTL=ACK><DATA=100> -->
+ 8. <--- ICMP "Packet Too Big" MTU=150, TCPseq#=201 <---
+
+ Figure 6: TCP Peer Attacked when Sending Small Packets
+ Just after the Three-Way Handshake
+
+ The nsegrto variable is initialized to zero. Both maxsizesent and
+ maxsizeacked are initialized to the minimum MTU for the Internet
+ Protocol being used (68 for IPv4, and 1280 for IPv6).
+
+ In lines 1 to 3, the three-way handshake takes place, and the
+ connection is established. At this point, the assumed Path-MTU for
+ this connection is 4464. In line 4, H1 sends a small segment (which
+ results in a 140-byte packet) to H2. Therefore, maxsizesent is set
+ to 140. In line 5, this segment is acknowledged, and thus
+ maxsizeacked is set to 140.
+
+ In lines 6 and 7, H1 sends two small segments to H2. In line 8,
+ while the segments from lines 6 and 7 are still "in flight" to H2, an
+ attacker sends a forged ICMP "Packet Too Big" error message to H1.
+ Assuming the attacker is lucky enough to guess a valid TCP sequence
+ number, this ICMP message will pass the TCP sequence number check.
+ The Next-Hop MTU reported by the ICMP error message (claimedmtu) is
+ then compared with maxsizesent. As claimedmtu is larger than
+ maxsizesent, the ICMP error message is silently discarded.
+ Therefore, the attack does not succeed.
+
+7.4. Pseudo-Code for the Counter-Measure for the Blind Performance-
+ Degrading Attack
+
+ This section contains a pseudo-code version of the counter-measure
+ described in Section 7.2 for the blind performance-degrading attack
+ described in Section 7. It is meant as guidance for developers on
+ how to implement this counter-measure.
+
+ The pseudo-code makes use of the following variables, constants, and
+ functions:
+
+
+
+
+
+
+Gont Informational [Page 27]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ ack
+ Variable holding the acknowledgement number contained in the TCP
+ segment that has just been received.
+
+ acked_packet_size
+ Variable holding the packet size (data, plus headers) that the ACK
+ that has just been received is acknowledging.
+
+ adjust_mtu()
+ Function that adjusts the MTU for this connection, according to
+ the ICMP "Packet Too Big" that was last received.
+
+ claimedmtu
+ Variable holding the Next-Hop MTU advertised by the ICMP "Packet
+ Too Big" error message.
+
+ claimedtcpseq
+ Variable holding the TCP sequence number contained in the payload
+ of the ICMP "Packet Too Big" message that has just been received
+ or was last recorded.
+
+ current_mtu
+ Variable holding the assumed Path-MTU for this connection.
+
+ drop_message()
+ Function that performs the necessary actions to drop the ICMP
+ message being processed.
+
+ initial_mtu
+ Variable holding the MTU for new connections, as explained in
+ [RFC1191] and [RFC1981].
+
+ maxsizeacked
+ Variable holding the largest packet size (data, plus headers) that
+ has so far been acked for this connection, as explained in
+ Section 7.2.
+
+ maxsizesent
+ Variable holding the largest packet size (data, plus headers) that
+ has so far been sent for this connection, as explained in
+ Section 7.2.
+
+ nsegrto
+ Variable holding the number of times this segment has timed out,
+ as explained in Section 7.2.
+
+ packet_size
+ Variable holding the size of the IP datagram being sent.
+
+
+
+Gont Informational [Page 28]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ pending_message
+ Variable (flag) that indicates whether there is a pending ICMP
+ "Packet Too Big" message to be processed.
+
+ save_message()
+ Function that records the ICMP "Packet Too Big" message that has
+ just been received.
+
+ MINIMUM_MTU
+ Constant holding the minimum MTU for the Internet Protocol in use
+ (68 for IPv4, and 1280 for IPv6).
+
+ MAXSEGRTO
+ Constant holding the number of times a given segment must time out
+ before an ICMP "Packet Too Big" error message can be honored.
+
+
+ EVENT: New TCP connection
+
+ current_mtu = initial_mtu;
+ maxsizesent = MINIMUM_MTU;
+ maxsizeacked = MINIMUM_MTU;
+ nsegrto = 0;
+ pending_message = 0;
+
+ EVENT: Segment is sent
+
+ if (packet_size > maxsizesent)
+ maxsizesent = packet_size;
+
+ EVENT: Segment is received
+
+ if (acked_packet_size > maxsizeacked)
+ maxsizeacked = acked_packet_size;
+
+ if (pending_message)
+ if (ack > claimedtcpseq){
+ pending_message = 0;
+ nsegrto = 0;
+ }
+
+ EVENT: ICMP "Packet Too Big" message is received
+
+ if (claimedmtu <= MINIMUM_MTU)
+ drop_message();
+
+ if (claimedtcpseq < SND.UNA || claimedtcpseq >= SND.NXT)
+ drop_message();
+
+
+
+Gont Informational [Page 29]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ else {
+ if (claimedmtu > maxsizesent || claimedmtu >= current_mtu)
+ drop_message();
+
+ else {
+ if (claimedmtu > maxsizeacked){
+ adjust_mtu();
+ current_mtu = claimedmtu;
+ maxsizesent = MINIMUM_MTU;
+ }
+
+ else {
+ pending_message = 1;
+ save_message();
+ }
+ }
+ }
+
+ EVENT: Segment times out
+
+ nsegrto++;
+
+ if (pending_message && nsegrto >= MAXSEGRTO){
+ adjust_mtu();
+ nsegrto = 0;
+ pending_message = 0;
+ maxsizeacked = claimedmtu;
+ maxsizesent = MINIMUM_MTU;
+ current_mtu = claimedmtu;
+ }
+
+ Notes:
+ All comparisons between sequence numbers must be performed using
+ sequence number arithmetic.
+
+ The pseudo-code implements the mechanism described in Section 7.2,
+ the TCP sequence number checking described in Section 4.1, and the
+ validation check on the advertised Next-Hop MTU described in
+ [RFC1191] and [RFC1981].
+
+8. Security Considerations
+
+ This document describes the use of ICMP error messages to perform a
+ number of attacks against TCP, and describes a number of widely
+ implemented counter-measures that either eliminate or reduce the
+ impact of these attacks when they are performed by off-path
+ attackers.
+
+
+
+
+Gont Informational [Page 30]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ 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 randomization of TCP ephemeral ports
+ requires 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 counter-measure eliminates
+ the aforementioned vulnerability in synchronized connections at the
+ expense of 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 ICMPv4
+ Source Quench messages meant for TCP connections. This is in
+ accordance with research results that indicate that ICMPv4 Source
+ Quench messages are ineffective and are an unfair antidote for
+ congestion.
+
+ Finally, Section 7.2 describes an attack-specific counter-measure 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
+ counter-measure parallels the Packetization Layer Path MTU Discovery
+ (PLPMTUD) mechanism [RFC4821]. It should be noted that if this
+ counter-measure is implemented, in some scenarios TCP may respond
+ more slowly to valid ICMP "Packet Too Big" error messages.
+
+ A discussion of these and other attack vectors for performing similar
+ attacks against TCP (along with possible counter-measures) can be
+ found in [CPNI-TCP] and [TCP-SECURITY].
+
+
+
+
+
+
+Gont Informational [Page 31]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+9. Acknowledgements
+
+ This document was inspired by Mika Liljeberg, while discussing some
+ issues related to [RFC5461] by private e-mail. The author would like
+ to thank (in alphabetical order): Bora Akyol, Mark Allman, Ran
+ Atkinson, James Carlson, Alan Cox, Theo de Raadt, Wesley Eddy, Lars
+ Eggert, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo Gont,
+ John Heffner, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, Mika
+ Liljeberg, Matt Mathis, David Miller, Toby Moncaster, Miles Nordin,
+ Eloy Paris, Kacheong Poon, Andrew Powell, Pekka Savola, Donald Smith,
+ Pyda Srisuresh, Fred Templin, and Joe Touch for contributing many
+ valuable comments.
+
+ Juan Fraschini and the author of this document implemented freely
+ available audit tools to help vendors audit their systems by
+ reproducing the attacks discussed in this document. These tools are
+ available at http://www.gont.com.ar/tools/index.html.
+
+ Markus Friedl, Chad Loder, and the author of this document produced
+ and tested in OpenBSD [OpenBSD] the first implementation of the
+ counter-measure described in Section 7.2. This first implementation
+ helped to test the effectiveness of the ideas introduced in this
+ document, and has served as a reference implementation for other
+ operating systems.
+
+ The author would like to thank the UK's Centre for the Protection of
+ National Infrastructure (CPNI) -- formerly the National
+ Infrastructure Security Co-ordination Centre (NISCC) -- for
+ coordinating the disclosure of these issues with a large number of
+ vendors and CSIRTs (Computer Security Incident Response Teams).
+
+ The author wishes to express deep and heartfelt gratitude to Jorge
+ Oscar Gont and Nelida Garcia, for their precious motivation and
+ guidance.
+
+10. References
+
+10.1. Normative References
+
+ [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC0792] Postel, J., "Internet Control Message Protocol",
+ STD 5, RFC 792, September 1981.
+
+ [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
+ RFC 793, September 1981.
+
+
+
+
+Gont Informational [Page 32]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ [RFC1122] Braden, R., "Requirements for Internet Hosts -
+ Communication Layers", STD 3, RFC 1122,
+ October 1989.
+
+ [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery",
+ RFC 1191, November 1990.
+
+ [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
+ RFC 1812, June 1995.
+
+ [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
+ Discovery for IP version 6", RFC 1981, August 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
+ Version 6 (IPv6) Specification", RFC 2460,
+ December 1998.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet
+ Control Message Protocol (ICMPv6) for the Internet
+ Protocol Version 6 (IPv6) Specification", RFC 4443,
+ March 2006.
+
+ [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
+ "Extended ICMP to Support Multi-Part Messages",
+ RFC 4884, April 2007.
+
+10.2. Informative References
+
+ [CPNI-TCP] CPNI, "Security Assessment of the Transmission
+ Control Protocol (TCP)", http://www.cpni.gov.uk/
+ Docs/tn-03-09-security-assessment-TCP.pdf, 2009.
+
+ [DClark] Clark, D., "The Design Philosophy of the DARPA
+ Internet Protocols", Computer Communication
+ Review Vol. 18, No. 4, 1988.
+
+ [FreeBSD] The FreeBSD Project, http://www.freebsd.org.
+
+ [ICMP-Filtering] Gont, F., "Filtering of ICMP error messages", http
+ ://www.gont.com.ar/papers/
+ filtering-of-icmp-error-messages.pdf.
+
+
+
+
+Gont Informational [Page 33]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ [IP-filtering] NISCC, "NISCC Technical Note 01/2006: Egress and
+ Ingress Filtering",
+ http://www.cpni.gov.uk/Docs/re-20060420-00294.pdf,
+ 2006.
+
+ [Linux] The Linux Project, "http://www.kernel.org".
+
+ [McKusick] McKusick, M., Bostic, K., Karels, M., and J.
+ Quarterman, "The Design and Implementation of the
+ 4.4 BSD Operating System", Addison-Wesley, 1996.
+
+ [NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/
+ ICMP: Vulnerability Issues in ICMP packets with TCP
+ payloads", http://www.cpni.gov.uk/docs/
+ re-20050412-00303.pdf?lang=en, 2005.
+
+ [NetBSD] The NetBSD Project, "http://www.netbsd.org".
+
+ [OpenBSD] The OpenBSD Project, "http://www.openbsd.org".
+
+ [OpenBSD-PF] The OpenBSD Packet Filter,
+ "http://www.openbsd.org/faq/pf/".
+
+ [PORT-RANDOM] Larsen, M. and F. Gont, "Transport Protocol Port
+ Randomization Recommendations", Work in Progress,
+ April 2010.
+
+ [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816,
+ July 1982.
+
+ [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm",
+ RFC 1321, April 1992.
+
+ [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP
+ Extensions for High Performance", RFC 1323,
+ May 1992.
+
+ [RFC2385] Heffernan, A., "Protection of BGP Sessions via the
+ TCP MD5 Signature Option", RFC 2385, August 1998.
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee,
+ "Hypertext Transfer Protocol -- HTTP/1.1",
+ RFC 2616, June 1999.
+
+ [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
+ RFC 2923, September 2000.
+
+
+
+
+Gont Informational [Page 34]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
+ Addition of Explicit Congestion Notification (ECN)
+ to IP", RFC 3168, September 2001.
+
+ [RFC3390] Allman, M., Floyd, S., and C. Partridge,
+ "Increasing TCP's Initial Window", RFC 3390,
+ October 2002.
+
+ [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border
+ Gateway Protocol 4 (BGP-4)", RFC 4271,
+ January 2006.
+
+ [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer
+ Path MTU Discovery", RFC 4821, March 2007.
+
+ [RFC4907] Aboba, B., "Architectural Implications of Link
+ Indications", RFC 4907, June 2007.
+
+ [RFC4953] Touch, J., "Defending TCP Against Spoofing
+ Attacks", RFC 4953, July 2007.
+
+ [RFC5321] Klensin, J., "Simple Mail Transfer Protocol",
+ RFC 5321, October 2008.
+
+ [RFC5461] Gont, F., "TCP's Reaction to Soft Errors",
+ RFC 5461, February 2009.
+
+ [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP
+ Congestion Control", RFC 5681, September 2009.
+
+ [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
+ Authentication Option", RFC 5925, June 2010.
+
+ [TCP-SECURITY] Gont, F., "Security Assessment of the Transmission
+ Control Protocol (TCP)", Work in Progress,
+ February 2010.
+
+ [TCPM-TCPSECURE] Ramaiah, A., Stewart, R., and M. Dalal, "Improving
+ TCP's Robustness to Blind In-Window Attacks", Work
+ in Progress, May 2010.
+
+ [US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750:
+ TCP/IP Implementations do not adequately validate
+ ICMP error messages",
+ http://www.kb.cert.org/vuls/id/222750, 2005.
+
+ [Watson] Watson, P., "Slipping in the Window: TCP Reset
+ Attacks", CanSecWest Conference, 2004.
+
+
+
+Gont Informational [Page 35]
+
+RFC 5927 ICMP Attacks against TCP July 2010
+
+
+ [Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated,
+ Volume 2: The Implementation", Addison-
+ Wesley, 1994.
+
+Author's Address
+
+ Fernando Gont
+ Universidad Tecnologica Nacional / Facultad Regional Haedo
+ Evaristo Carriego 2644
+ Haedo, Provincia de Buenos Aires 1706
+ Argentina
+
+ Phone: +54 11 4650 8472
+ EMail: fernando@gont.com.ar
+ URI: http://www.gont.com.ar
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont Informational [Page 36]
+