TCP Maintenance and Minor                                        F. Gont
Extensions (tcpm)                                                UTN/FRH
Internet-Draft                                          October 24, 2005
Expires: April 27, 2006


                        ICMP attacks against TCP
                  draft-gont-tcpm-icmp-attacks-05.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.
   This document may not be modified, and derivative works of it may not
   be created, except to publish it as an RFC and to translate it into
   languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document discusses the use of the Internet Control Message
   Protocol (ICMP) to perform a variety of attacks against the
   Transmission Control Protocol (TCP) and other similar protocols.  It
   proposes several counter-measures to eliminate or minimize the impact
   of these attacks.



Gont                     Expires April 27, 2006                 [Page 1]


Internet-Draft          ICMP attacks against TCP            October 2005


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 (ICMP) . . . . . . . . . . . . .  5
       2.1.2.  ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . .  6
     2.2.  Handling of ICMP error messages  . . . . . . . . . . . . .  6
   3.  Constraints in the possible solutions  . . . . . . . . . . . .  7
   4.  General counter-measures against ICMP attacks  . . . . . . . .  8
     4.1.  TCP sequence number checking . . . . . . . . . . . . . . .  8
     4.2.  Port randomization . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Filtering ICMP error messages based on the ICMP payload  .  9
   5.  Blind connection-reset attack  . . . . . . . . . . . . . . . .  9
     5.1.  Description  . . . . . . . . . . . . . . . . . . . . . . . 10
     5.2.  Attack-specific counter-measures . . . . . . . . . . . . . 11
       5.2.1.  Changing the reaction to hard errors . . . . . . . . . 11
       5.2.2.  Delaying the connection-reset  . . . . . . . . . . . . 13
   6.  Blind throughput-reduction attack  . . . . . . . . . . . . . . 13
     6.1.  Description  . . . . . . . . . . . . . . . . . . . . . . . 14
     6.2.  Attack-specific counter-measures . . . . . . . . . . . . . 14
   7.  Blind performance-degrading attack . . . . . . . . . . . . . . 14
     7.1.  Description  . . . . . . . . . . . . . . . . . . . . . . . 14
     7.2.  Attack-specific counter-measures . . . . . . . . . . . . . 16
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     10.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Appendix A.  The counter-measure for the PMTUD attack in action  . 22
     A.1.  Normal operation for bulk transfers  . . . . . . . . . . . 23
     A.2.  Operation during Path-MTU changes  . . . . . . . . . . . . 25
     A.3.  Idle connection being attacked . . . . . . . . . . . . . . 26
     A.4.  Active connection being attacked after discovery of
           the Path-MTU . . . . . . . . . . . . . . . . . . . . . . . 27
     A.5.  TCP peer attacked when sending small packets just
           after the three-way handshake  . . . . . . . . . . . . . . 27
   Appendix B.  Pseudo-code for the counter-measure for the blind
                performance-degrading attack  . . . . . . . . . . . . 28
   Appendix C.  Additional considerations for the validation of
                ICMP error messages . . . . . . . . . . . . . . . . . 32
   Appendix D.  Advice and guidance to vendors  . . . . . . . . . . . 32
   Appendix E.  Changes from previous versions of the draft . . . . . 32
     E.1.  Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 32
     E.2.  Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 33
     E.3.  Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 33
     E.4.  Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 33
     E.5.  Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 34



Gont                     Expires April 27, 2006                 [Page 2]


Internet-Draft          ICMP attacks against TCP            October 2005


   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35
   Intellectual Property and Copyright Statements . . . . . . . . . . 36

















































Gont                     Expires April 27, 2006                 [Page 3]


Internet-Draft          ICMP attacks against TCP            October 2005


1.  Introduction

   ICMP [RFC0792] 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 leaving the door
   open to a variety of attacks that can be performed 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 being off-path, without
   the need to sniff the packets that correspond to the attacked TCP
   connection.

   While the 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 vulnerabiliies.  Thus, only a few
   implementations have implemented validation checks on the received
   ICMP error messages to minimize the impact of these attacks.

   Recently, a disclosure process has been carried out by the UK's
   National Infrastructure Security Co-ordination Centre (NISCC), 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 [I-D.iab-link-indications].

   This document aims to raise awareness of the use of ICMP to perform a
   variety of attacks against TCP, and proposes several counter-measures
   that eliminate or minimize the impact of these attacks.

   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.
   Section 4 proposes several general validation checks and counter-
   measures 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 propose 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



Gont                     Expires April 27, 2006                 [Page 4]


Internet-Draft          ICMP attacks against TCP            October 2005


   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 host, to raise awareness 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 handled to
   the corresponding transport-protocol instance, which will usually
   perform a fault recovery function.

   It is important to note that ICMP error messages are unreliable, and
   may be discarded due to data corruption, network congestion and rate-
   limiting.  Thus, while they provide useful information, upper layer
   protocols cannot depend on ICMP for correct operation.

2.1.1.  ICMP for IP version 4 (ICMP)

   [RFC0792] specifies the Internet Control Message Protocol (ICMP) to
   be used with the Internet Protocol version 4 (IPv4).  It defines,
   among other things, a number of error messages that can be used by
   end-systems and intermediate systems to report network errors to the
   sending host.  The Host Requirements RFC [RFC1122] classifies ICMP
   error messages into those that indicate "soft errors", and those that
   indicate "hard errors", thus roughly defining the semantics of them.

   The ICMP specification [RFC0792] also defines the ICMP 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 ICMP error messages of type 3 (Destination
   Unreachable), code 4 (fragmentation needed and DF bit set) to allow
   hosts to determine the MTU of an arbitrary internet path.

   Appendix D of [RFC2401] provides information about which ICMP error
   messages are produced by hosts, intermediate routers, or both.




Gont                     Expires April 27, 2006                 [Page 5]


Internet-Draft          ICMP attacks against TCP            October 2005


2.1.2.  ICMP for IP version 6 (ICMPv6)

   [RFC2463] specifies the Internet Control Message Protocol (ICMPv6) to
   be used with the Internet Protocol version 6 (IPv6) [RFC2460].

   [RFC2463] defines the "Packet Too Big" (type 2, code 0) error
   message, that is analogous to the ICMP "fragmentation needed and DF
   bit set" (type 3, code 4) error message.  [RFC1981] defines the Path
   MTU Discovery mechanism for IP Version 6, that makes use of these
   messages to determine the MTU of an arbitrary internet path.

   Appendix D of [RFC2401] 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 that a TCP MUST act on an
   ICMP error message passed up from the IP layer, directing it to the
   connection that elicited the error.

   In order to allow ICMP messages to be demultiplexed by the receiving
   host, part of the original packet that elicited the message is
   included in the payload of the ICMP error message.  Thus, the
   receiving host can use that information to match the ICMP error to
   the transport protocol instance that elicited it.

   Neither the Host Requirements RFC [RFC1122] nor the original TCP
   specification [RFC0793] recommend 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 forged ICMP
   message to the attacked host, and, as long as he is able to guess the
   four-tuple that identifies the communication instance to be attacked,
   he will be able to use ICMP to perform a variety of attacks.

   As discussed in [Watson], there are a number of scenarios in which an
   attacker may be able to know or guess the four-tuple that identifies
   a TCP connection.  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 will be known.  Furthermore, as most
   Internet services use the so-called "well-known" ports, only the
   client port number would need to be guessed.  This means that an
   attacker would need to send, in principle, at most 65536 packets to
   perform any of the attacks described in this document.  However, most
   systems choose the port numbers they use for outgoing connections



Gont                     Expires April 27, 2006                 [Page 6]


Internet-Draft          ICMP attacks against TCP            October 2005


   from a subset of the whole port number space.  Thus, in practice,
   fewer packets are needed to perform any of the attacks discussed in
   this document.

   It is clear that TCP should be more cautious when processing received
   ICMP error messages, in order to mitigate or eliminate the impact of
   the attacks described in this document [I-D.iab-link-indications].


3.  Constraints in the possible solutions

   For ICMPv4, [RFC0792] states that the internet header plus the first
   64 bits of the packet that elicited the ICMP message are to be
   included in the payload of the ICMP error message.  Thus, it is
   assumed that all data needed to identify a transport protocol
   instance and process the ICMP error message is contained in the first
   64 bits of the transport protocol header.  [RFC1122] states that "the
   Internet header and at least the first 8 data octets of the datagram
   that triggered the error" are to be included in the payload of ICMP
   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 ICMP specification.  The
   Requirements for IP Version 4 Routers RFC [RFC1812] states that ICMP
   error messages "SHOULD contain as much of the original datagram as
   possible without the length of the ICMP datagram exceeding 576
   bytes".

   Thus, for ICMP messages generated by hosts, we can only expect to get
   the entire IP header of the original packet, plus the first 64 bits
   of its payload.  For TCP, this means that the only fields that will
   be included in the ICMP payload are: the source port number, the
   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 avalable 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 elicited 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 [RFC2401], because only a
   part of the original IP packet would be available, the signature used
   for authentication could not be recalculated, and thus this mechanism
   could not be used as a counter-measure aganist ICMP-based attacks
   against TCP.




Gont                     Expires April 27, 2006                 [Page 7]


Internet-Draft          ICMP attacks against TCP            October 2005


   For IPv6, the payload of ICMPv6 error messages includes as many
   octets from the IPv6 packet that elicited the ICMPv6 error message as
   will fit without making the resulting ICMPv6 packet exceed the
   minimum IPv6 MTU (1280 octets) [RFC2463].  Thus, more information is
   available than in the IPv4 case.

   Hosts could require ICMP error messages to be authenticated
   [RFC2401], 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
   host should have a security asociation [RFC2401] with every 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.  Also,
   there may be some cases, such as embedded devices, in which the
   processing power requirements of authentication could not allow IPSec
   authentication to be implemented effectively.

   Additional considerations for the validation of ICMP error messages
   can be found in Appendix C


4.  General counter-measures against ICMP attacks

   There are a number of counter-measures that can be implemented 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.  In particular, all TCP implementations SHOULD perform the
   TCP sequence number checking described in Section 4.1.

4.1.  TCP sequence number checking

   TCP SHOULD 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 the sequence number should be
   within the range of the data already sent but not yet acknowledged.
   If an ICMP error message does not pass this check, it SHOULD be
   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 [RFC2581]).
   For connections in the SYN-SENT or SYN-RECEIVED states, this would
   reduce the possibility of considering a spoofed ICMP packet as valid



Gont                     Expires April 27, 2006                 [Page 8]


Internet-Draft          ICMP attacks against TCP            October 2005


   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.

   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.  Therefore, implementation of the attack-specific counter-
   measures discussed in this document is strongly RECOMMENDED.

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 conenctions would make it harder for an attacker to perform any
   of the attacks discussed in this document.

   [I-D.larsen-tsvwg-port-randomisation] discusses a number of
   algorithms to randomize the ephemeral ports used by clients.

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.  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 could be implemented in firewalls as a
   counter-measure.  Firewalls implementing such advanced filtering
   would look at the payload of the ICMP error messages, and would
   perform ingress and egress packet filtering based on the source IP
   address of the IP header contained in the payload of the ICMP error
   message.  As the source IP address contained in the payload of the
   ICMP error message does need to be spoofed to perform the attacks
   described in this document, this kind of advanced filtering would
   serve as a counter-measure against these attacks.


5.  Blind connection-reset attack






Gont                     Expires April 27, 2006                 [Page 9]


Internet-Draft          ICMP attacks against TCP            October 2005


5.1.  Description

   When TCP is handled 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 that a host SHOULD abort
   the corresponding connection when receiving an ICMP error message
   that indicates a "hard error", and states that ICMP 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 to indicate hard errors.  While [RFC2463] 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.  That is, even being off-path, an attacker could reset any
   TCP connection taking place.  In order to perform such an attack, an
   attacker would send 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.

   As discussed in Section 2.2, all an attacker needs to know to perform
   such an attack is the socket pair that identifies the TCP connection
   to be attacked.  In some scenarios, the IP addresses and port numbers
   in use may be easily guessed or known to the attacker [Watson].

   Some stacks are known to extrapolate ICMP 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
   [I-D.ietf-tcpm-tcpsecure], by means authentication at the network
   layer [RFC2401], by means of the TCP MD5 signature option [RFC2385],
   or by means of the mechanism proposed in [I-D.ietf-tcpm-tcpsecure],
   the blind connection-reset attack described in this document would
   still succeed.



Gont                     Expires April 27, 2006                [Page 10]


Internet-Draft          ICMP attacks against TCP            October 2005


5.2.  Attack-specific counter-measures

5.2.1.  Changing the reaction to hard errors

   An analysis of the circumstances in which ICMP messages that indicate
   hard errors may be received can shed some light to eliminate the
   impact of ICMP-based blind connection-reset attacks.

   ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable)

      This ICMP error message indicates that the host sending the ICMP
      error message received a packet meant for a transport protocol it
      does not support.  For connection-oriented protocols such as TCP,
      one could expect to receive such an error as the result of a
      connection-establishment attempt.  However, it would be strange to
      get such an error during the life of a connection, as this would
      indicate that support for that transport protocol has been removed
      from the host sending the error message during the life of the
      corresponding connection.  Thus, it would be fair to treat ICMP
      protocol unreachable error messages as soft errors (or completely
      ignore them) if they are meant for connections that are in
      synchronized states.  For TCP, this means TCP should treat ICMP
      protocol unreachable error messages as soft errors (or completely
      ignore them) if they are meant for connections that are in the
      ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK
      or TIME-WAIT states.

   ICMP type 3 (Destination Unreachable), code 3 (port unreachable)

      This error message indicates that the host sending the ICMP error
      message received a packet meant for a socket (IP address, port
      number) on which there is no process listening.  Those transport
      protocols which have their own mechanisms for notifying this
      condition should not be receiving these error messages.  However,
      the Host Requirements RFC [RFC1122] states that even those
      transport protocols that have their own mechanism for notifying
      the sender that a port is unreachable MUST nevertheless accept an
      ICMP Port Unreachable for the same purpose.  For security reasons,
      it would be fair to treat ICMP port unreachable messages as soft
      errors (or completely ignore them) when they are meant for
      protocols that have their own mechanism for reporting this error
      condition.

   ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed
   and DF bit set)

      This error message indicates that an intermediate node needed to
      fragment a datagram, but the DF (Don't Fragment) bit in the IP



Gont                     Expires April 27, 2006                [Page 11]


Internet-Draft          ICMP attacks against TCP            October 2005


      header was set.  Those systems that do not implement the PMTUD
      mechanism should not be sending their IP packets with the DF bit
      set, and thus should not be receiving these ICMP error messages.
      Thus, it would be fair for them to treat this ICMP error message
      as indicating a soft error, therefore not aborting the
      corresponding connection when such an error message is received.
      On the other hand, and for obvious reasons, those systems
      implementing the Path-MTU Discovery (PMTUD) mechanism [RFC1191]
      should not abort the corresponding connection when such an ICMP
      error message is received.

   ICMPv6 type 1 (Destination Unreachable), code 1 (communication with
   destination administratively prohibited)

      This error message indicates that the destination is unreachable
      because of an administrative policy.  For connection-oriented
      protocols such as TCP, one could expect to receive such an error
      as the result of a connection-establishment attempt.  Receiving
      such an error for a connection in any of the synchronized states
      would mean that the administrative policy changed during the life
      of the connection.  Therefore, while it would be possible for a
      firewall to be reconfigured during the life of a connection, it
      would be fair, for security reasons, to ignore these messages for
      connections that are in the ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2,
      CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT states.

   ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable)

      This error message is analogous to the ICMP type 3 (Destination
      Unreachable), code 3 (Port unreachable) error message discussed
      above.  Therefore, the same considerations apply.

   Therefore, TCP SHOULD treat all of the above messages as indicating
   "soft errors", rather than "hard errors", and thus SHOULD NOT abort
   the corresponding connection upon receipt of them.  This is policy is
   based on the premise that TCP should be as robust as possible.  Also,
   as discussed in Section 5.1, hosts SHOULD NOT extrapolate ICMP errors
   across TCP connections.

   In case the received message were legitimate, it would mean that the
   "hard error" condition appeared during the life of the connection.
   However, there is no reason to think that in the same way this error
   condition appeared, it won't get solved in the near term.  Therefore,
   treating the received ICMP error messages as "soft errors" would make
   TCP more robust, and could avoid TCP from aborting a TCP connection
   unnecesarily.  Aborting the connection would be to ignore the
   valuable feature of the Internet that for many internal failures it
   reconstructs its function without any disruption of the end points



Gont                     Expires April 27, 2006                [Page 12]


Internet-Draft          ICMP attacks against TCP            October 2005


   [RFC0816].

   Also, it is important to note that the current specifications allow
   this recommended counter-measure.

   One scenario in which a host would benefit from treating the so-
   called ICMP "hard errors" as "soft errors" would be that in which the
   packets that correspond to a given TCP connection are routed along
   multiple different paths.  Some (but not all) of these paths may be
   experiencing an error condition, and therefore generating the so-
   called ICMP hard errors.  However, communication should survive if
   there is still a working path to the destination host [DClark].
   Thus, treating the so-called "hard errors" as "soft errors" when a
   connection is in any of the synchronized states would make TCP
   achieve this goal.

   It is interesting to note that, as ICMP error messages are
   unreliable, 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 received
   error messages, 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 [TCPv2][McKusick].  The Linux kernel has implemented
   this policy for more than ten years, too [Linux].

5.2.2.  Delaying the connection-reset

   An alternative counter-measure could be to delay the connection
   reset.  Rather than immediately aborting a connection, a TCP would
   abort a connection only after an ICMP error message indicating a hard
   error has been received, and the corresponding data have already been
   retransmitted more than some specified number of times.

   The rationale behind this proposed fix is that if a host can make
   forward progress on a connection, it can completely disregard the
   "hard errors" being indicated by the received ICMP error messages.

   While this counter-measure could be useful, we think that the
   counter-measure discussed in Section 5.2.1 is easier to implement,
   and provides increased protection against this type of attack.


6.  Blind throughput-reduction attack




Gont                     Expires April 27, 2006                [Page 13]


Internet-Draft          ICMP attacks against TCP            October 2005


6.1.  Description

   The Host requirements RFC [RFC1122] states that hosts MUST react to
   ICMP Source Quench messages by slowing transmission on the
   connection.  Thus, an attacker could send ICMP 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 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 [RFC2581].  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) [RFC2581] bytes per RTT
   (round-trip time).  The throughput achieved during attack might be a
   little higher if a larger initial congestion window is in use
   [RFC3390].

6.2.  Attack-specific counter-measures

   The Host Requirements RFC [RFC1122] states that hosts MUST react to
   ICMP Source Quench messages by slowing transmission on the
   connection.  However, as discussed in the Requirements for IP Version
   4 Routers RFC [RFC1812], research seems to suggest ICMP Source Quench
   is an ineffective (and unfair) antidote for congestion.  [RFC1812]
   further states that routers SHOULD NOT send ICMP Source Quench
   messages in response to congestion.  On the other hand, TCP
   implements its own congestion control mechanisms [RFC2581] [RFC3168],
   that do not depend on ICMP Source Quench messages.  Thus, hosts
   SHOULD completely ignore ICMP Source Quench messages meant for TCP
   connections.

   This behavior has been implemented in Linux [Linux] since 2004, and
   in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] since
   2005.


7.  Blind performance-degrading attack

7.1.  Description

   When one IP host has a large amount of data to send to another host,
   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 [RFC1191].




Gont                     Expires April 27, 2006                [Page 14]


Internet-Draft          ICMP attacks against TCP            October 2005


   A technique called "Path MTU Discovery" (PMTUD) mechanism lets IP
   hosts 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 host 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
   ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF
   set" (code 4) error message to sending host.  This message will
   report the MTU of the constricting hop, so that the sending host 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 sending host.  This message
   will report the MTU of the constricting hop, so that the sending host
   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 forged
   ICMP "Destination Unreachable, fragmentation needed and DF set"
   packet (or their ICMPv6 counterpart) to the sending host, 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 end-point.  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 increase in the IRQ
   (Interrrupt ReQuest) rate, thus increasing processor utilization, and
   degrading the overall system performance.

   A particular scenario that may take place is that in which an
   attacker reports a Next-Hop MTU smaller than or equal to the amount
   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



Gont                     Expires April 27, 2006                [Page 15]


Internet-Draft          ICMP attacks against TCP            October 2005


   larger than 68 bytes, the assumed Path-MTU will not even allow the
   attacked host to send a single byte of application data without
   fragmentation.  This particular scenario might lead to unpredictable
   results.  Another posible scenario is that 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 host 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 low as 68 octets, as
   [RFC0791] requires every internet module to be able to forward a
   datagram of 68 octets without further fragmentation.  For IPv6, the
   reported Next-Hop MTU could be as low as 1280 octets (the minimum
   IPv6 MTU) [RFC2460].

7.2.  Attack-specific counter-measures

   Henceforth, we will refer to both ICMP "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,
   a counter-measure similar to that described in Section 5.2.2 could be
   implemented to greatly minimize the impact of this attack.

   This would mean that upon receipt of an ICMP "Packet Too Big" error
   message, TCP would just record this information, and would honor it
   only when the corresponding data had already been retransmitted a
   specified number of times.

   While this 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.

   We would like to protect TCP from the attack against the PMTUD
   mechanism, while still allowing TCP to quickly determine the initial
   Path-MTU for a connection.

   To achieve both goals, we can divide the traditional PMTUD mechanism
   into two stages: Initial Path-MTU Discovery, and Path-MTU Update.




Gont                     Expires April 27, 2006                [Page 16]


Internet-Draft          ICMP attacks against TCP            October 2005


   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 it would be fair to 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, it would be fair to be 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 should be introduced to TCP: maxsizeacked
   and maxsizesent.

   maxsizesent would hold the size (in octets) of the largest packet
   that has so far been sent for this connection.  It would be
   initialized to 68 (the minimum IPv4 MTU) when the underlying internet
   protocol is IPv4, and would be initialized to 1280 (the minimum IPv6
   MTU) when the underlying internet protocol is IPv6.  Whenever a
   packet larger than maxsizesent octets is sent, maxsizesent should be
   set to that value.

   On the other hand, maxsizeacked would hold the size (in octets) of
   the largest packet that has so far been acknowledged for this
   connection.  It would be initialized to 68 (the minimum IPv4 MTU)
   when the underlying internet protocol is IPv4, and would be
   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 should be
   set to the size of that acknowledged packet.

   Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop
   MTU claimed by the ICMP message (henceforth "claimedmtu") should be
   compared with maxsizesent.  If claimedmtu is equal to or larger than
   maxsizesent, then the ICMP error message should be silently
   discarded.  The rationale for this is that the ICMP error message
   cannot be legitimate if it claims to have been elicited by a packet
   larger than the largest packet we have so far sent for this
   connection.

   If this check is passed, claimedmtu should be compared with
   maxsizeacked.  If claimedmtu is equal to or larger than maxsizeacked,



Gont                     Expires April 27, 2006                [Page 17]


Internet-Draft          ICMP attacks against TCP            October 2005


   TCP is supposed to be at the Initial Path-MTU Discovery stage, and
   thus the ICMP "Packet Too Big" error message should be honored
   immediately.  That is, the assumed Path-MTU should be updated
   according to the Next-Hop MTU claimed in the ICMP error message.
   Also, maxsizesent should be reset to the minimum MTU of the internet
   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, we
   should be more cautious with the errors being reported by the
   network, and should 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 should
   be introduced to TCP: nsegrto and MAXSEGRTO. nsegrto will hold the
   number of times a specified segment has timed out.  It should be
   initialized to zero, and should be incremented by one everytime the
   corresponding segment times out.  MAXSEGRRTO should specify the
   number of times a given segment must timeout before an ICMP "Packet
   Too Big" error message can be honored, and can be set, in principle,
   to any value greater than or equal to 0.

   Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a
   pending ICMP "Packet Too Big" error message, the correspoing error
   message should be processed.  At that point, maxsizeacked should be
   set to claimedmtu, and maxsizesent should be 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 should be 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.

   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 should provide 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.




Gont                     Expires April 27, 2006                [Page 18]


Internet-Draft          ICMP attacks against TCP            October 2005


   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.

   Appendix A shows the proposed counter-measure in action.  Appendix B
   shows the proposed counter-measure in pseudo-code.

   This behavior has been implemented in NetBSD [NetBSD] and OpenBSD
   [OpenBSD] since 2005.

   It is important to note that the mechanism proposed in this section
   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.  Thus, it does not aleviate the need for other improvements
   to the current PMTUD mechanism or the introduction of an alternative
   PMTUD that replaces the current one, to solve the remaining issues.

   A mechanism that aims to address those remaining issues is described
   in [I-D.ietf-pmtud-method].


8.  Security Considerations

   This document describes the use of ICMP error messages to perform a
   number of attacks against the TCP protocol, and proposes a number of
   counter-measures that either eliminate or reduce the impact of these
   attacks.


9.  Acknowledgements

   This document was inspired by Mika Liljeberg, while discussing some
   issues related to [I-D.gont-tcpm-tcp-soft-errors] by private e-mail.
   The author would like to thank Ran Atkinson, James Carlson, Alan Cox,
   Theo de Raadt, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo
   Gont, John Heffner, Vivek Kakkar, Michael Kerrisk, Mika Liljeberg,
   David Miller, Miles Nordin, Eloy Paris, Kacheong Poon, Andrew Powell,
   Pekka Savola, Joe Touch, and Andres Trapanotto, for contributing many
   valuable comments.

   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



Gont                     Expires April 27, 2006                [Page 19]


Internet-Draft          ICMP attacks against TCP            October 2005


   operating systems.

   The author would like to thank the UK's National Infrastructure
   Security Co-ordination Centre (NISCC) for coordinating the disclosure
   of these issues with a large number of vendors and CSIRTs (Computer
   Security Incident Response Teams).

   The author wishes to express deep and heartfelt gratitude to Jorge
   Oscar Gont and Nelida Garcia, for their precious motivation and
   guidance.


10.  References

10.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.

   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
              for IP version 6", RFC 1981, August 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2463]  Conta, A. and S. Deering, "Internet Control Message
              Protocol (ICMPv6) for the Internet Protocol Version 6



Gont                     Expires April 27, 2006                [Page 20]


Internet-Draft          ICMP attacks against TCP            October 2005


              (IPv6) Specification", RFC 2463, December 1998.

10.2.  Informative References

   [DClark]   Clark, D., "The Design Philosophy of the DARPA Internet
              Protocols", Computer Communication Review Vol. 18, No. 4,
              1988.

   [FreeBSD]  The FreeBSD Project, "http://www.freebsd.org".

   [I-D.gont-tcpm-tcp-soft-errors]
              Gont, F., "TCP's Reaction to Soft Errors",
              draft-gont-tcpm-tcp-soft-errors-02 (work in progress),
              September 2005.

   [I-D.iab-link-indications]
              Aboba, B., "Architectural Implications of Link
              Indications", draft-iab-link-indications-03 (work in
              progress), August 2005.

   [I-D.ietf-pmtud-method]
              Mathis, M., "Path MTU Discovery",
              draft-ietf-pmtud-method-04 (work in progress),
              February 2005.

   [I-D.ietf-tcpm-tcpsecure]
              Dalal, M., "Improving TCP's Robustness to Blind In-Window
              Attacks", draft-ietf-tcpm-tcpsecure-03 (work in progress),
              May 2005.

   [I-D.larsen-tsvwg-port-randomisation]
              Larsen, M., "Port Randomisation",
              draft-larsen-tsvwg-port-randomisation-00 (work in
              progress), October 2004.

   [Linux]    The Linux Project, "http://www.kernel.org".

   [McKusick]
              McKusick, M., Bostic, K., Karels, M., and J. Quarterman,
              "The Design and Implementation of the 4.4BSD Operating
              System", Addison-Wesley , 1996.

   [NISCC]    NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP:
              Vulnerability Issues in ICMP packets with TCP payloads",
              http://www.niscc.gov.uk/niscc/docs/
              al-20050412-00308.html?lang=en, 2005.

   [NetBSD]   The NetBSD Project, "http://www.netbsd.org".



Gont                     Expires April 27, 2006                [Page 21]


Internet-Draft          ICMP attacks against TCP            October 2005


   [OpenBSD]  The OpenBSD Project, "http://www.openbsd.org".

   [RFC0816]  Clark, D., "Fault isolation and recovery", RFC 816,
              July 1982.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC1323]  Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
              for High Performance", RFC 1323, May 1992.

   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, August 1998.

   [RFC2581]  Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
              Control", RFC 2581, April 1999.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2923]  Lahey, K., "TCP Problems with Path MTU Discovery",
              RFC 2923, September 2000.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC3390]  Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
              Initial Window", RFC 3390, October 2002.

   [TCPv2]    Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
              The Implementation", Addison-Wesley , 1994.

   [US-CERT]  US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP
              Implementations do not adequately validate ICMP error
              messages",  http://www.kb.cert.org/vuls/id/222750, 2005.

   [Watson]   Watson, P., "Slipping in the Window: TCP Reset Attacks",
              2004 CanSecWest Conference , 2004.


Appendix A.  The counter-measure for the PMTUD attack in action

   This appendix shows the proposed counter-measure for the ICMP attack



Gont                     Expires April 27, 2006                [Page 22]


Internet-Draft          ICMP attacks against TCP            October 2005


   against the PMTUD mechanism in action.  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 Appendix assumes
   the PMTUD-specific counter-measure is implemented in addition to the
   TCP sequence number checking described in Section 4.1.

   Figure 1 illustrates an hypothetical scenario in which two hosts are
   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 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 sake, all the following subsections assume the TCP
   implementation at Host 1 has chosen a a MAXSEGRTO of 1.


   +----+        +----+        +----+        +----+        +----+
   | H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 |
   +----+        +----+        +----+        +----+        +----+
         MTU=4464      MTU=2048      MTU=1500      MTU=4464

   Figure 1: Hypothetical scenario

A.1.  Normal operation for bulk transfers

   This subsection shows the proposed counter-measure in normal
   operation, when a TCP connection is used for bulk transfers.  That
   is, it shows how the proposed 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                     Expires April 27, 2006                [Page 23]


Internet-Draft          ICMP attacks against TCP            October 2005


      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

   nsegrto 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. maxsizesent
   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. maxsizesent 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



Gont                     Expires April 27, 2006                [Page 24]


Internet-Draft          ICMP attacks against TCP            October 2005


   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. maxsizesent 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. maxsizesent is thus 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.

A.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 proposed counter-measure would work in this
   scenario.


        Host 1                                         Host 2

   1.                     (Path-MTU decreases)
   2.      -->  <SEQ=100><ACK=X><CTL=ACK><DATA=1500>   -->
   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-



Gont                     Expires April 27, 2006                [Page 25]


Internet-Draft          ICMP attacks against TCP            October 2005


   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
   claimedmtu is smaller than maxsizeacked (full-sized packets were
   getting to the remote end-point), 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. nsegrto is reset to 0, and 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.

A.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.  At 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 the TCP sequence number each ICMP packet includes, none of
   these ICMP error messages will pass the TCP sequence number check



Gont                     Expires April 27, 2006                [Page 26]


Internet-Draft          ICMP attacks against TCP            October 2005


   described in Section 4.1, as H1 has no unacknowledged data in flight
   to H2.  Therefore, the attack does not succeed.

A.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 packet 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.

A.5.  TCP peer attacked when sending small packets just after the three-
      way handshake

   This section analyzes an scenario in which a TCP peer that is sending
   small segments just after the connection has been established, is
   attacked.  The connection could be being used by protocols such as
   SMTP [RFC2821] and HTTP [RFC2616], for example, which usually behave
   like this.




Gont                     Expires April 27, 2006                [Page 27]


Internet-Draft          ICMP attacks against TCP            October 2005


   Figure 6 shows a possible packet exchange for such scenario.


      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#=101 <---


   Figure 6: TCP peer attacked when sending small packets just after the
   three-way handshake

   nsegrto 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. maxsizesent is thus 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.


Appendix B.  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.




Gont                     Expires April 27, 2006                [Page 28]


Internet-Draft          ICMP attacks against TCP            October 2005


   The pseudo-code makes use of the following variables, constants, and
   functions:

   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) 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 for been acked for this connection, as explained in
      Section 7.2

   maxsizesent
      Variable holding the largest packet size (data, plus headers) that
      has so for been sent for this connection, as explained in
      Section 7.2







Gont                     Expires April 27, 2006                [Page 29]


Internet-Draft          ICMP attacks against TCP            October 2005


   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

   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 timeout
      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_mesage)
             if (ack > claimedtcpseq){
                  pending_message = 0;
                  nsegrto = 0;
             }



Gont                     Expires April 27, 2006                [Page 30]


Internet-Draft          ICMP attacks against TCP            October 2005


   EVENT: ICMP "Packet Too Big" message is received

        if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >= SND.NXT){
             drop_message();
        }

        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 comparisions between sequence numbers must be performed using
      sequence number arithmethic.
      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].





Gont                     Expires April 27, 2006                [Page 31]


Internet-Draft          ICMP attacks against TCP            October 2005


Appendix C.  Additional considerations for the validation of ICMP error
             messages

   If a full TCP segment is contained in the payload of the ICMP error
   message, then the first check that must be performed is that the TCP
   checksum is valid.  Then, if a TCP MD5 option is present, the MD5
   signature should be recalculated for the encapsulated packet, and if
   doesn't match the one contained in the TCP MD5 option, the packet
   should be dropped.

   Regardless of whether the received ICMP error message contains a full
   packet or not, if a TCP timestamp option is present, it should be
   used to validate the error message according to the rules specified
   in [RFC1323].

   It must be noted that all the checks discussed in this appendix imply
   that the ICMP error message contains more data than just the full IP
   header and the first 64 bits of the payload of the original datagram
   that elicited the error message.  As discussed in Section 3, for
   obvious reasons one should not expect an attacker to include in the
   packets it sends more information than that required to by the
   current specifications.


Appendix D.  Advice and guidance to vendors

   Vendors are urged to contact NISCC (vulteam@niscc.gov.uk) if they
   think they may be affected by the issues described in this document.
   As the lead coordination center for these issues, NISCC is well
   placed to give advice and guidance as required.

   NISCC works extensively with government departments and agencies,
   commercial organizations and the academic community to research
   vulnerabilities and potential threats to IT systems especially where
   they may have an impact on Critical National Infrastructure's (CNI).

   Other ways to contact NISCC, plus NISCC's PGP public key, are
   available at http://www.uniras.gov.uk/vuls/ .


Appendix E.  Changes from previous versions of the draft

E.1.  Changes from draft-gont-tcpm-icmp-attacks-04

   o  Added Appendix C

   o  Added reference to [I-D.iab-link-indications]




Gont                     Expires April 27, 2006                [Page 32]


Internet-Draft          ICMP attacks against TCP            October 2005


   o  Added stress on the fact that ICMP error messages are unreliable

   o  Miscellaneous editorial changes

E.2.  Changes from draft-gont-tcpm-icmp-attacks-03

   o  Added references to existing implementations of the proposed
      counter-measures

   o  The discussion in Section 4 was improved

   o  The discussion in Section 5.2.1 was expanded and improved

   o  The proposed counter-measure for the attack against the PMTUD was
      improved and simplified

   o  Appendix B was added

   o  Miscellaneous editorial changes

E.3.  Changes from draft-gont-tcpm-icmp-attacks-02

   o  Fixed errors in Section 5.2.1

   o  The proposed counter-measure for the attack against the PMTUD
      mechanism was refined to allow quick discovery of the Path-MTU

   o  Appendix A was added so as to clarify the operation of the
      counter-measure for the attack against the PMTUD mechanism

   o  Added Appendix D

   o  Miscellaneous editorial changes

E.4.  Changes from draft-gont-tcpm-icmp-attacks-01

   o  The document was restructured for easier reading

   o  A discussion of ICMPv6 was added in several sections of the
      document

   o  Added Section on Acknowledgement number checking"/>

   o  Added Section 4.3

   o  Added Section 7





Gont                     Expires April 27, 2006                [Page 33]


Internet-Draft          ICMP attacks against TCP            October 2005


   o  Fixed typo in the ICMP types, in several places

   o  Fixed typo in the TCP sequence number check formula

   o  Miscellaneous editorial changes

E.5.  Changes from draft-gont-tcpm-icmp-attacks-00

   o  Added a proposal to change the handling of the so-called ICMP hard
      errors during the synchronized states

   o  Added a summary of the relevant RFCs in several sections

   o  Miscellaneous editorial changes





































Gont                     Expires April 27, 2006                [Page 34]


Internet-Draft          ICMP attacks against TCP            October 2005


Author's Address

   Fernando Gont
   Universidad Tecnologica Nacional
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

   Phone: +54 11 4650 8472
   Email: fernando@gont.com.ar









































Gont                     Expires April 27, 2006                [Page 35]


Internet-Draft          ICMP attacks against TCP            October 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Gont                     Expires April 27, 2006                [Page 36]