draft-ietf-tcpm-icmp-attacks-07.txt   draft-ietf-tcpm-icmp-attacks-08.txt 
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UTN/FRH Extensions (tcpm) UTN/FRH
Internet-Draft December 8, 2009 Internet-Draft January 19, 2010
Intended status: Informational Intended status: Informational
Expires: June 11, 2010 Expires: July 23, 2010
ICMP attacks against TCP ICMP attacks against TCP
draft-ietf-tcpm-icmp-attacks-07.txt draft-ietf-tcpm-icmp-attacks-08.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) and other similar protocols.
Additionally, describes a number of widely implemented modifications Additionally, describes a number of widely implemented modifications
to TCP's handling of ICMP error messages that help to mitigate these to TCP's handling of ICMP error messages that help to mitigate these
issues. issues.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 11, 2010. This Internet-Draft will expire on July 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 6 2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5
2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 6 2.1.1. ICMP for IP version 4 (ICMP) . . . . . . . . . . . . . 5
2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 7 2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6
2.2. Handling of ICMP error messages . . . . . . . . . . . . . 7 2.2. Handling of ICMP error messages . . . . . . . . . . . . . 6
2.3. Handling of ICMP error messages in the context of IPsec . 8 2.3. Handling of ICMP error messages in the context of IPsec . 7
3. Constraints in the possible solutions . . . . . . . . . . . . 9 3. Constraints in the possible solutions . . . . . . . . . . . . 8
4. General counter-measures against ICMP attacks . . . . . . . . 10 4. General counter-measures against ICMP attacks . . . . . . . . 9
4.1. TCP sequence number checking . . . . . . . . . . . . . . . 10 4.1. TCP sequence number checking . . . . . . . . . . . . . . . 9
4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 11 4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 10
4.3. Filtering ICMP error messages based on the ICMP payload . 11 4.3. Filtering ICMP error messages based on the ICMP payload . 10
5. Blind connection-reset attack . . . . . . . . . . . . . . . . 12 5. Blind connection-reset attack . . . . . . . . . . . . . . . . 11
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Attack-specific counter-measures . . . . . . . . . . . . . 13 5.2. Attack-specific counter-measures . . . . . . . . . . . . . 12
6. Blind throughput-reduction attack . . . . . . . . . . . . . . 16 6. Blind throughput-reduction attack . . . . . . . . . . . . . . 15
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Attack-specific counter-measures . . . . . . . . . . . . . 16 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 15
7. Blind performance-degrading attack . . . . . . . . . . . . . . 17 7. Blind performance-degrading attack . . . . . . . . . . . . . . 16
7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Attack-specific counter-measures . . . . . . . . . . . . . 18 7.2. Attack-specific counter-measures . . . . . . . . . . . . . 17
7.3. The counter-measure for the PMTUD attack in action . . . . 22 7.3. The counter-measure for the PMTUD attack in action . . . . 21
7.3.1. Normal operation for bulk transfers . . . . . . . . . 22 7.3.1. Normal operation for bulk transfers . . . . . . . . . 21
7.3.2. Operation during Path-MTU changes . . . . . . . . . . 24 7.3.2. Operation during Path-MTU changes . . . . . . . . . . 23
7.3.3. Idle connection being attacked . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . 26 after the three-way handshake . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . 27 performance-degrading attack . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . . 32
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) . . . . . . . . . . . . . . 36 this document as an RFC) . . . . . . . . . . . . . . 35
A.1. Changes from draft-ietf-tcpm-icmp-attacks-06 . . . . . . . 36 A.1. Changes from draft-ietf-tcpm-icmp-attacks-07 . . . . . . . 35
A.2. Changes from draft-ietf-tcpm-icmp-attacks-05 . . . . . . . 36 A.2. Changes from draft-ietf-tcpm-icmp-attacks-06 . . . . . . . 35
A.3. Changes from draft-ietf-tcpm-icmp-attacks-04 . . . . . . . 36 A.3. Changes from draft-ietf-tcpm-icmp-attacks-05 . . . . . . . 35
A.4. Changes from draft-ietf-tcpm-icmp-attacks-03 . . . . . . . 36 A.4. Changes from draft-ietf-tcpm-icmp-attacks-04 . . . . . . . 35
A.5. Changes from draft-ietf-tcpm-icmp-attacks-02 . . . . . . . 36 A.5. Changes from draft-ietf-tcpm-icmp-attacks-03 . . . . . . . 35
A.6. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 37 A.6. Changes from draft-ietf-tcpm-icmp-attacks-02 . . . . . . . 36
A.7. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 37 A.7. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 36
A.8. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 37 A.8. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 36
A.9. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 38 A.9. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 37
A.10. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 38 A.10. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 37
A.11. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 38 A.11. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 37
A.12. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 38 A.12. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 37
A.13. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 39 A.13. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 A.14. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite,
and is used mainly for reporting network error conditions. However, and is used mainly for reporting network error conditions. However,
the current specifications do not recommend any kind of validation the current specifications do not recommend any kind of validation
checks on the received ICMP error messages, thus allowing variety of checks on the received ICMP error messages, thus allowing variety of
attacks against TCP [RFC0793] by means of ICMP, which include blind attacks against TCP [RFC0793] by means of ICMP, which include blind
connection-reset, blind throughput-reduction, and blind performance- connection-reset, blind throughput-reduction, and blind performance-
degrading attacks. All of these attacks can be performed even being degrading attacks. All of these attacks can be performed even being
skipping to change at page 11, line 9 skipping to change at page 11, line 9
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
is discarded. is discarded.
Even if an attacker were able to guess the four-tuple that identifies Even if an attacker were able to guess the four-tuple that identifies
the TCP connection, this additional check would reduce the the TCP connection, this additional check would reduce the
possibility of considering a spoofed ICMP packet as valid to possibility of considering a spoofed ICMP packet as valid to
Flight_Size/2^^32 (where Flight_Size is the number of data bytes Flight_Size/2^^32 (where Flight_Size is the number of data bytes
already sent to the remote peer, but not yet acknowledged [RFC2581]). already sent to the remote peer, but not yet acknowledged [RFC5681]).
For connections in the SYN-SENT or SYN-RECEIVED states, this would For connections in the SYN-SENT or SYN-RECEIVED states, this would
reduce the possibility of considering a spoofed ICMP packet as valid reduce the possibility of considering a spoofed ICMP packet as valid
to 1/2^^32. For a TCP endpoint with no data "in flight", this would to 1/2^^32. For a TCP endpoint with no data "in flight", this would
completely eliminate the possibility of success of these attacks. completely eliminate the possibility of success of these attacks.
This validation check has been implemented in Linux [Linux] for many This validation check has been implemented in Linux [Linux] for many
years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and
NetBSD [NetBSD] since 2005. NetBSD [NetBSD] since 2005.
It is important to note that while this check greatly increases the It is important to note that while this check greatly increases the
skipping to change at page 11, line 51 skipping to change at page 11, line 51
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] discusses a number of algorithms
to randomize the ephemeral ports used by clients. to randomize the ephemeral ports used by clients.
4.3. Filtering ICMP error messages based on the ICMP payload 4.3. Filtering ICMP error messages based on the ICMP payload
The source address of ICMP error messages does not need to be spoofed The source address of ICMP error messages does not need to be spoofed
to perform the attacks described in this document. Therefore, simple to perform the attacks described in this document, as the ICMP error
filtering based on the source address of ICMP error messages does not messages might legitimately come from an intermediate system.
serve as a counter-measure against these attacks. However, a more
advanced packet filtering can be implemented in middlebox devices Therefore, simple filtering based on the source address of ICMP error
such as firewalls and NATs. Middleboxes implementing such advanced messages does not serve as a counter-measure against these attacks.
filtering look at the payload of the ICMP error messages, and perform However, a more advanced packet filtering can be implemented in
ingress and egress packet filtering based on the source IP address of middlebox devices such as firewalls and NATs. Middleboxes
the IP header contained in the payload of the ICMP error message. As implementing such advanced filtering look at the payload of the ICMP
the source IP address contained in the payload of the ICMP error error messages, and perform ingress and egress packet filtering based
message does need to be spoofed to perform the attacks described in on the source IP address of the IP header contained in the payload of
this document, this kind of advanced filtering serves as a counter- the ICMP error message. As the source IP address contained in the
measure against these attacks. As with traditional egress filtering payload of the ICMP error message does need to be spoofed to perform
[IP-filtering], egress filtering based on the ICMP payload can help the attacks described in this document, this kind of advanced
to prevent users of the network being protected by the firewall from filtering serves as a counter-measure against these attacks. As with
successfully performing ICMP attacks against TCP connections traditional egress filtering [IP-filtering], egress filtering based
established between external systems. Additionally, ingress on the ICMP payload can help to prevent users of the network being
filtering based on the ICMP payload can prevent TCP connections protected by the firewall from successfully performing ICMP attacks
established between internal systems from attacks performed by against TCP connections established between external systems.
external systems. [ICMP-Filtering] provides examples of ICMP Additionally, ingress filtering based on the ICMP payload can prevent
filtering based on the ICMP payload. TCP connections established between internal systems from attacks
performed by external systems. [ICMP-Filtering] provides examples of
ICMP filtering based on the ICMP payload.
This filtering technique has been implemented in OpenBSD's Packet This filtering technique has been implemented in OpenBSD's Packet
Filter [OpenBSD-PF], which has in turn been ported to a number of Filter [OpenBSD-PF], which has in turn been ported to a number of
systems, including FreeBSD [FreeBSD]. systems, including FreeBSD [FreeBSD].
5. Blind connection-reset attack 5. Blind connection-reset attack
5.1. Description 5.1. Description
When TCP is handed an ICMP error message, it will perform its fault When TCP is handed an ICMP error message, it will perform its fault
skipping to change at page 16, line 27 skipping to change at page 16, line 27
6.1. Description 6.1. Description
The Host requirements RFC [RFC1122] states in Section 4.2.3.9 that The Host requirements RFC [RFC1122] states in Section 4.2.3.9 that
hosts MUST react to ICMP Source Quench messages by slowing hosts MUST react to ICMP Source Quench messages by slowing
transmission on the connection. Thus, an attacker could send ICMP transmission on the connection. Thus, an attacker could send ICMP
Source Quench (type 4, code 0) messages to a TCP endpoint to make it 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 end-point of the reduce the rate at which it sends data to the other end-point of the
connection. [RFC1122] further adds that the RECOMMENDED procedure is connection. [RFC1122] further adds that the RECOMMENDED procedure is
to put the corresponding connection in the slow-start phase of TCP's to put the corresponding connection in the slow-start phase of TCP's
congestion control algorithm [RFC2581]. In the case of those congestion control algorithm [RFC5681]. In the case of those
implementations that use an initial congestion window of one segment, implementations that use an initial congestion window of one segment,
a sustained attack would reduce the throughput of the attacked a sustained attack would reduce the throughput of the attacked
connection to about SMSS (Sender Maximum Segment Size) [RFC2581] connection to about SMSS (Sender Maximum Segment Size) [RFC5681]
bytes per RTT (round-trip time). The throughput achieved during an bytes per RTT (round-trip time). The throughput achieved during an
attack might be a little higher if a larger initial congestion window attack might be a little higher if a larger initial congestion window
is in use [RFC3390]. is in use [RFC3390].
6.2. Attack-specific counter-measures 6.2. Attack-specific counter-measures
As discussed in the Requirements for IP Version 4 Routers RFC As discussed in the Requirements for IP Version 4 Routers RFC
[RFC1812], research seems to suggest that ICMP Source Quench is an [RFC1812], research seems to suggest that ICMP Source Quench is an
ineffective (and unfair) antidote for congestion. [RFC1812] further ineffective (and unfair) antidote for congestion. [RFC1812] further
states that routers SHOULD NOT send ICMP Source Quench messages in states that routers SHOULD NOT send ICMP Source Quench messages in
response to congestion. Furthermore, TCP implements its own response to congestion. Furthermore, TCP implements its own
congestion control mechanisms [RFC2581] [RFC3168], that do not depend congestion control mechanisms [RFC5681] [RFC3168], that do not depend
on ICMP Source Quench messages. on ICMP Source Quench messages.
Based on this reasoning, a large number of implementations completely Based on this reasoning, a large number of implementations completely
ignore ICMP Source Quench messages meant for TCP connections. This ignore ICMP Source Quench messages meant for TCP connections. This
behavior has been implemented in, at least, Linux [Linux] since 2004, behavior has been implemented in, at least, Linux [Linux] since 2004,
and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD]
since 2005. However, it must be noted that this behaviour violates since 2005. However, it must be noted that this behaviour violates
the requirement in [RFC1122] to react to ICMP Source Quench messages the requirement in [RFC1122] to react to ICMP Source Quench messages
by slowing transmission on the connection. by slowing transmission on the connection.
skipping to change at page 20, line 23 skipping to change at page 20, line 23
largest packet that has so far been acknowledged for this connection. largest packet that has so far been acknowledged for this connection.
It is initialized to 68 (the minimum IPv4 MTU) when the underlying It is initialized to 68 (the minimum IPv4 MTU) when the underlying
internet protocol is IPv4, and is initialized to 1280 (the minimum internet protocol is IPv4, and is initialized to 1280 (the minimum
IPv6 MTU) when the underlying internet protocol is IPv6. Whenever an IPv6 MTU) when the underlying internet protocol is IPv6. Whenever an
acknowledgement for a packet larger than maxsizeacked octets is acknowledgement for a packet larger than maxsizeacked octets is
received, maxsizeacked is set to the size of that acknowledged received, maxsizeacked is set to the size of that acknowledged
packet. packet.
Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop
MTU claimed by the ICMP message (henceforth "claimedmtu") is compared MTU claimed by the ICMP message (henceforth "claimedmtu") is compared
with maxsizesent. If claimedmtu is equal to or larger than with maxsizesent. If claimedmtu is larger than maxsizesent, then the
maxsizesent, then the ICMP error message is silently discarded. The ICMP error message is silently discarded. The rationale for this is
rationale for this is that the ICMP error message cannot be that the ICMP error message cannot be legitimate if it claims to have
legitimate if it claims to have been elicited by a packet larger than been elicited by a packet larger than the largest packet we have so
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
skipping to change at page 26, line 48 skipping to change at page 26, line 48
line 1, before it times out. At this point, the "pending error" line 1, before it times out. At this point, the "pending error"
condition is cleared, and the recorded ICMP "Packet Too Big" error condition is cleared, and the recorded ICMP "Packet Too Big" error
message is ignored. Therefore, the attack does not succeed. message is ignored. Therefore, the attack does not succeed.
7.3.5. TCP peer attacked when sending small packets just after the 7.3.5. TCP peer attacked when sending small packets just after the
three-way handshake three-way handshake
This section analyzes an scenario in which a TCP peer that is sending This section analyzes an scenario in which a TCP peer that is sending
small segments just after the connection has been established, is small segments just after the connection has been established, is
attacked. The connection could be being used by protocols such as attacked. The connection could be being used by protocols such as
SMTP [RFC2821] and HTTP [RFC2616], for example, which usually behave SMTP [RFC5321] and HTTP [RFC2616], for example, which usually behave
like this. like this.
Figure 6 shows a possible packet exchange for such scenario. Figure 6 shows a possible packet exchange for such scenario.
Host 1 Host 2 Host 1 Host 2
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=100> --> 4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=100> -->
skipping to change at page 30, line 4 skipping to change at page 30, line 4
if (acked_packet_size > maxsizeacked) if (acked_packet_size > maxsizeacked)
maxsizeacked = acked_packet_size; maxsizeacked = acked_packet_size;
if (pending_message) if (pending_message)
if (ack > claimedtcpseq){ if (ack > claimedtcpseq){
pending_message = 0; pending_message = 0;
nsegrto = 0; nsegrto = 0;
} }
EVENT: ICMP "Packet Too Big" message is received EVENT: ICMP "Packet Too Big" message is received
if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >= SND.NXT){ if (claimedmtu &lt= MINIMUM_MTU)
drop_message();
if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ &gt= SND.NXT){
drop_message(); drop_message();
} }
else { else {
if (claimedmtu >= maxsizesent || claimedmtu >= current_mtu) if (claimedmtu > maxsizesent || claimedmtu >= current_mtu)
drop_message(); drop_message();
else { else {
if (claimedmtu > maxsizeacked){ if (claimedmtu > maxsizeacked){
adjust_mtu(); adjust_mtu();
current_mtu = claimedmtu; current_mtu = claimedmtu;
maxsizesent = MINIMUM_MTU; maxsizesent = MINIMUM_MTU;
} }
else { else {
skipping to change at page 32, line 5 skipping to change at page 32, line 5
Quench messages are ineffective and unfair antidote for congestion. Quench messages are ineffective and unfair antidote for congestion.
Finally, Section 7.2 describes an attack-specific countermeasure for Finally, Section 7.2 describes an attack-specific countermeasure for
the blind performance-degrading attack. It consists of the the blind performance-degrading attack. It consists of the
validation check described in Section 4.1, with a modification that validation check described in Section 4.1, with a modification that
makes TCP react to ICMP "Packet Too Big" error messages such that makes TCP react to ICMP "Packet Too Big" error messages such that
they are processed when an outstanding TCP segment times out. This they are processed when an outstanding TCP segment times out. This
countermeasures parallels the Packetization Layer Path MTU Discovery countermeasures parallels the Packetization Layer Path MTU Discovery
(PLPMTUD) mechanism [RFC4821]. (PLPMTUD) mechanism [RFC4821].
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 [I-D.ietf-tcpm-tcp-security].
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
skipping to change at page 33, line 38 skipping to change at page 33, line 42
[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.
11.2. Informative References 11.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 [DClark] Clark, D., "The Design Philosophy of the DARPA Internet
Protocols", Computer Communication Review Vol. 18, No. 4, Protocols", Computer Communication Review Vol. 18, No. 4,
1988. 1988.
[FreeBSD] The FreeBSD Project, "http://www.freebsd.org". [FreeBSD] The FreeBSD Project, "http://www.freebsd.org".
[I-D.ietf-tcpm-tcp-auth-opt] [I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-08 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-08
(work in progress), October 2009. (work in progress), October 2009.
[I-D.ietf-tcpm-tcp-security]
Gont, F., "Security Assessment of the Transmission Control
Protocol (TCP)", draft-ietf-tcpm-tcp-security-00 (work in
progress), August 2009.
[I-D.ietf-tcpm-tcpsecure] [I-D.ietf-tcpm-tcpsecure]
Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", Robustness to Blind In-Window Attacks",
draft-ietf-tcpm-tcpsecure-12 (work in progress), draft-ietf-tcpm-tcpsecure-12 (work in progress),
September 2009. September 2009.
[I-D.ietf-tsvwg-port-randomization] [I-D.ietf-tsvwg-port-randomization]
Larsen, M. and F. Gont, "Port Randomization", Larsen, M. and F. Gont, "Port Randomization",
draft-ietf-tsvwg-port-randomization-05 (work in progress), draft-ietf-tsvwg-port-randomization-05 (work in progress),
November 2009. November 2009.
skipping to change at page 35, line 5 skipping to change at page 35, line 19
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, September 2000. RFC 2923, September 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002. Initial Window", RFC 3390, October 2002.
skipping to change at page 35, line 37 skipping to change at page 35, line 45
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, March 2007.
[RFC4907] Aboba, B., "Architectural Implications of Link [RFC4907] Aboba, B., "Architectural Implications of Link
Indications", RFC 4907, June 2007. Indications", RFC 4907, June 2007.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007. RFC 4953, July 2007.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
February 2009. February 2009.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009.
[US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP [US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP
Implementations do not adequately validate ICMP error Implementations do not adequately validate ICMP error
messages", http://www.kb.cert.org/vuls/id/222750, 2005. messages", http://www.kb.cert.org/vuls/id/222750, 2005.
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks",
2004 CanSecWest Conference , 2004. 2004 CanSecWest Conference , 2004.
[Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: [Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
The Implementation", Addison-Wesley , 1994. The Implementation", Addison-Wesley , 1994.
Appendix A. Changes from previous versions of the draft (to be removed Appendix A. Changes from previous versions of the draft (to be removed
by the RFC Editor before publishing this document as an by the RFC Editor before publishing this document as an
RFC) RFC)
A.1. Changes from draft-ietf-tcpm-icmp-attacks-06 A.1. Changes from draft-ietf-tcpm-icmp-attacks-07
o Addresses some remaining WGLC feedback sent off-list by Donald
Smith and Guillermo Gont.
A.2. 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.2. Changes from draft-ietf-tcpm-icmp-attacks-05 A.3. 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.3. Changes from draft-ietf-tcpm-icmp-attacks-04 A.4. 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.4. Changes from draft-ietf-tcpm-icmp-attacks-03 A.5. 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.5. Changes from draft-ietf-tcpm-icmp-attacks-02 A.6. Changes from draft-ietf-tcpm-icmp-attacks-02
o Added a disclaimer to indicate that this document does not update o Added a disclaimer to indicate that this document does not update
the current specifications. the current specifications.
o Addresses feedback sent off-list by Alfred Hoenes. o Addresses feedback sent off-list by Alfred Hoenes.
o The text (particulary that which describes the counter-measures) o The text (particulary that which describes the counter-measures)
was reworded to document what current implementations are doing, was reworded to document what current implementations are doing,
rather than "proposing" the implementation of the counter- rather than "proposing" the implementation of the counter-
measures. measures.
o Some text has been removed: we're just documenting the problem, o Some text has been removed: we're just documenting the problem,
and what existing implementations have done. and what existing implementations have done.
o Miscelaneous editorial changes. o Miscelaneous editorial changes.
A.6. Changes from draft-ietf-tcpm-icmp-attacks-01 A.7. 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.7. Changes from draft-ietf-tcpm-icmp-attacks-00 A.8. Changes from draft-ietf-tcpm-icmp-attacks-00
o Added references to the specific sections of each of the o Added references to the specific sections of each of the
referenced specifications referenced specifications
o Corrected the threat analysys o Corrected the threat analysys
o Added clarification about whether the counter-measures violate the o Added clarification about whether the counter-measures violate the
current specifications or not. current specifications or not.
o Changed text so that the document fits better in the Informational o Changed text so that the document fits better in the Informational
skipping to change at page 37, line 39 skipping to change at page 38, line 7
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.8. Changes from draft-gont-tcpm-icmp-attacks-05 A.9. 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.9. Changes from draft-gont-tcpm-icmp-attacks-04 A.10. 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.10. Changes from draft-gont-tcpm-icmp-attacks-03 A.11. Changes from draft-gont-tcpm-icmp-attacks-03
o Added references to existing implementations of the proposed o Added references to existing implementations of the proposed
counter-measures counter-measures
o The discussion in Section 4 was improved o The discussion in Section 4 was improved
o The discussion of the blind connection-reset vulnerability was o The discussion of the blind connection-reset vulnerability was
expanded and improved expanded and improved
o The proposed counter-measure for the attack against the PMTUD was o The proposed counter-measure for the attack against the PMTUD was
improved and simplified improved and simplified
o Section 7.4 was added o Section 7.4 was added
o Miscellaneous editorial changes o Miscellaneous editorial changes
A.11. Changes from draft-gont-tcpm-icmp-attacks-02 A.12. Changes from draft-gont-tcpm-icmp-attacks-02
o Fixed errors in in the discussion of the blind connection-reset o Fixed errors in in the discussion of the blind connection-reset
attack attack
o The proposed counter-measure for the attack against the PMTUD o The proposed counter-measure for the attack against the PMTUD
mechanism was refined to allow quick discovery of the Path-MTU mechanism was refined to allow quick discovery of the Path-MTU
o Section 7.3 was added so as to clarify the operation of the o Section 7.3 was added so as to clarify the operation of the
counter-measure for the attack against the PMTUD mechanism counter-measure for the attack against the PMTUD mechanism
o Added CPNI contact information. o Added CPNI contact information.
o Miscellaneous editorial changes o Miscellaneous editorial changes
A.12. Changes from draft-gont-tcpm-icmp-attacks-01 A.13. 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
skipping to change at page 39, line 19 skipping to change at page 39, line 34
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.13. Changes from draft-gont-tcpm-icmp-attacks-00 A.14. 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. 41 change blocks. 
103 lines changed or deleted 129 lines changed or added

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