TCP Maintenance and Minor                                        F. Gont
Extensions (tcpm)                                                UTN/FRH

Intended status: Informational
Expires: December 6, 2009 February 25, 2010

                        ICMP attacks against TCP
                  draft-ietf-tcpm-icmp-attacks-05.txt
                  draft-ietf-tcpm-icmp-attacks-06.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 December 6, 2009. February 25, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document discusses the use of the Internet Control Message
   Protocol (ICMP) to perform a variety of attacks against the
   Transmission Control Protocol (TCP) and other similar protocols.
   Additionally, describes a number of widely implemented modifications
   to TCP's handling of ICMP error messages that help to mitigate these
   issues.

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
     2.3.  Handling of ICMP error messages in the context of IPsec  .  7
   3.  Constraints in the possible solutions  . . . . . . . . . . . .  8
   4.  General counter-measures against ICMP attacks  . . . . . . . .  9
     4.1.  TCP sequence number checking . . . . . . . . . . . . . . .  9
     4.2.  Port randomization . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Filtering ICMP error messages based on the ICMP payload  . 10
   5.  Blind connection-reset attack  . . . . . . . . . . . . . . . . 11
     5.1.  Description  . . . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Attack-specific counter-measures . . . . . . . . . . . . . 12
   6.  Blind throughput-reduction attack  . . . . . . . . . . . . . . 13 15
     6.1.  Description  . . . . . . . . . . . . . . . . . . . . . . . 13 15
     6.2.  Attack-specific counter-measures . . . . . . . . . . . . . 13 15
   7.  Blind performance-degrading attack . . . . . . . . . . . . . . 14 15
     7.1.  Description  . . . . . . . . . . . . . . . . . . . . . . . 14 15
     7.2.  Attack-specific counter-measures . . . . . . . . . . . . . 15 17
     7.3.  The counter-measure for the PMTUD attack in action . . . . 19 20
       7.3.1.  Normal operation for bulk transfers  . . . . . . . . . 19 21
       7.3.2.  Operation during Path-MTU changes  . . . . . . . . . . 21 23
       7.3.3.  Idle connection being attacked . . . . . . . . . . . . 22 24
       7.3.4.  Active connection being attacked after discovery
               of the Path-MTU  . . . . . . . . . . . . . . . . . . . 23 24
       7.3.5.  TCP peer attacked when sending small packets just
               after the three-way handshake  . . . . . . . . . . . . 23 25
     7.4.  Pseudo-code for the counter-measure for the blind
           performance-degrading attack . . . . . . . . . . . . . . . 24 26
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28 30
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 30
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 31
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 31
     10.2. Informative References . . . . . . . . . . . . . . . . . . 29 31
   Appendix A.  An analysis of ICMP hard errors . . . . . . . . . . . 32
   Appendix B.  Advice and guidance to vendors  . . . . . . . . . . . 33
   Appendix C.  Changes from previous versions of the draft (to
                be removed by the RFC Editor before publishing
                this document as an RFC)  . . . . . . . . . . . . . . 33
     C.1. 34
     A.1.  Changes from draft-ietf-tcpm-icmp-attacks-05 . . . . . . . 34
     A.2.  Changes from draft-ietf-tcpm-icmp-attacks-04 . . . . . . . 33
     C.2. 34
     A.3.  Changes from draft-ietf-tcpm-icmp-attacks-03 . . . . . . . 34
     C.3.
     A.4.  Changes from draft-ietf-tcpm-icmp-attacks-02 . . . . . . . 34
     C.4.
     A.5.  Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 34
     C.5. 35
     A.6.  Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 34
     C.6. 35
     A.7.  Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 35
     C.7.
     A.8.  Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 35
     C.8. 36
     A.9.  Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 35
     C.9. 36
     A.10. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 36
     C.10.
     A.11. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 36
     C.11.
     A.12. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 36 37
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37

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 allowing variety of
   attacks against TCP [RFC0793] by means of ICMP, which include blind
   connection-reset, blind throughput-reduction, and blind performance-
   degrading attacks.  All of these attacks can be performed even being
   off-path, without the need to sniff the packets that correspond to
   the attacked TCP connection.

   While the possible security implications of ICMP have been known in
   the research community for a long time, there has never been an
   official proposal on how to deal with these vulnerabiliies.  In 2005,
   a disclosure process was carried out by the UK's National
   Infrastructure Security Co-ordination Centre (NISCC) (now CPNI,
   Centre for the Protection of National Infrastructure), with the
   collaboration of other computer emergency response teams.  A large
   number of implementations were found vulnerable to either all or a
   subset of the attacks discussed in this document [NISCC][US-CERT].
   The affected systems ranged from TCP/IP implementations meant for
   desktop computers, to TCP/IP implementations meant for core Internet
   routers.

   It is clear that implementations should be more cautious when
   processing ICMP error messages, to eliminate or mitigate the use of
   ICMP to perform attacks against TCP [RFC4907].

   This document aims to raise awareness of the use of ICMP to perform a
   variety of attacks against TCP, and discusses several counter-
   measures that eliminate or minimize the impact of these attacks.
   Most of the these counter-measures can be implemented while still
   remaining compliant with the current specifications, as they simply
   describe reasons for not taking the advice provided in the
   specifications in terms of "SHOULDs", but still comply with the
   requirements stated as "MUSTs".

   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 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
   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
   architecture mainly to perform the fault-isolation function, that is,
   the group of actions that hosts and routers take to determine that
   there is some network failure [RFC0816].

   When an intermediate router detects a network problem while trying to
   forward an IP packet, it will usually send an ICMP error message to
   the source system, to 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 handed to
   the corresponding transport-protocol instance, which will usually
   perform a fault recovery function.

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

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 errors to the sending
   system.  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
   systems to determine the MTU of an arbitrary internet path.

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

2.1.2.  ICMP for IP version 6 (ICMPv6)

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

   [RFC4443] defines the "Packet Too Big" (type 2, code 0) error
   message, 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 [RFC4301] provides information about which ICMPv6 error
   messages are produced by hosts, intermediate routers, or both.

2.2.  Handling of ICMP error messages

   The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that 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
   system, part of the original packet that elicited the message is
   included in the payload of the ICMP error message.  Thus, the
   receiving system can use that information to match the ICMP error to
   the transport protocol instance that 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 system, and, as long as he is able to guess
   the four-tuple (i.e., Source IP Address, Source TCP port, Destination
   IP Address, and Destination TCP port) that identifies the
   communication instance to be attacked, he will be able to use ICMP to
   perform a variety of attacks.

   Generally, the four-tuple required to perform these attacks is not
   known.  However, as discussed in [Watson] and [RFC4953], there are a
   number of scenarios (notably that of TCP connections established
   between two BGP routers [RFC4271]), in which an attacker may be able
   to know or guess the four-tuple that identifies a TCP connection.  In
   such a case, if we assume the attacker knows the two systems involved
   in the TCP connection to be attacked, both the client-side and the
   server-side IP addresses could be known or be within a reasonable
   number of possibilities.  Furthermore, as most Internet services use
   the so-called "well-known" ports, only the client port number might
   need to be guessed.  In such a scenario, an attacker would need to
   send, in principle, at most 65536 packets to perform any of the
   attacks described in this document.  These issues are exacerbated by
   the fact that most systems choose the port numbers they use for
   outgoing connections from a subset of the whole port number space,
   thus reducing the amount of work needed to successfully perform these
   attacks.

   The need to be more more cautious when processing received ICMP error
   messages in order to mitigate or eliminate the impact of the attacks
   described in this document has been documented by the Internet
   Architecture Board (IAB) in [RFC4907].

2.3.  Handling of ICMP error messages in the context of IPsec

   Section 5.2 of [RFC4301] describes the processing of inbound IP
   Traffic in the case of "unprotected-to-protected".  In the case of
   ICMP, when an unprotected ICMP error message is received, it is
   matched to the corresponding security association by means of the SPI
   (Security Parameters Index) included in the payload of the ICMP error
   message.  Then, local policy is applied to determine whether to
   accept or reject the message and, if accepted, what action to take as
   a result.  For example, if an ICMP unreachable message is received,
   the implementation must decide whether to act on it, reject it, or
   act on it with constraints.  Section 8 ("Path MTU/DF processing")
   discusses the processing of unauthenticated ICMP "fragmentation
   needed and DF bit set" (type 3, code 3) and ICMPv6 "Packet Too Big"
   (type 2, code 0) messages when an IPsec implementation is configured
   to process (vs. ignore) such messages.

   Section 6.1.1 of [RFC4301] notes that processing of unauthenticated
   ICMP error messages may result in denial or degradation of service,
   and therefore it would be desirable to ignore such messages.
   However, it also notes that in many cases ignoring these ICMP
   messages can degrade service, e.g., because of a failure to process
   PMTUD and redirection messages, and therefore there is also a
   motivation for accepting and acting upon them.  It finally states
   that to accommodate both ends of this spectrum, a compliant IPsec
   implementation MUST permit a local administrator to configure an
   IPsec implementation to accept or reject unauthenticated ICMP
   traffic, and that this control MUST be at the granularity of ICMP
   type and MAY be at the granularity of ICMP type and code.
   Additionally, an implementation SHOULD incorporate mechanisms and
   parameters for dealing with such traffic.

   Thus, the policy to apply for the processing of unprotected ICMP
   error messages is left up to the implementation and administrator.

3.  Constraints in the possible solutions

   For ICMPv4, [RFC0792] states that the internet IP 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.  Section 3.2.2 of [RFC1122] states that
   "the Internet header and at least the first 8 data octets of the
   datagram that triggered the error" are to be 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 [RFC4301], because only a
   part of the original IP packet would be available, the signature used
   for authentication could not be recalculated, and thus the
   authentication header in the original packet could not be used as a
   counter-measure for ICMP-based attacks against TCP.

   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 error message exceed the
   minimum IPv6 MTU (1280 octets) [RFC4443].  Thus, more information is
   available than in the IPv4 case.

   Hosts could require ICMP error messages to be authenticated
   [RFC4301], in order to act upon them.  However, while this
   requirement could make sense for those ICMP error messages sent by
   hosts, it would not be feasible for those ICMP error messages
   generated by routers, as this would imply either that the attacked
   system should have a security association [RFC4301] with every
   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,
   Additionally, this would require routers to use certificates with
   paths compatible for all hosts on the network.  Finally, there may be
   some scenarios, such as embedded devices, in which the processing
   power requirements of authentication might not allow IPSec
   authentication to be implemented effectively.

4.  General counter-measures against ICMP attacks

   The following subsections describe a number of mitigation techniques
   that help to eliminate or mitigate the impact of the attacks
   discussed in this document.  Rather than being alternative counter-
   measures, they can be implemented together to increase the protection
   against these attacks.

4.1.  TCP sequence number checking

   The current specifications do not impose any validity checks on the
   TCP segment that is contained in the ICMP payload.  For instance, no
   checks are performed to verify that a received ICMP error message has
   been elicited by a segment that was "in flight" to the destination.
   Thus, even stale ICMP error messages will be acted upon.

   Many TCP implementations have incorporated a validation check so
   makes TCP react only to those ICMP error messages elicited by
   segments that were "in-flight" to the destination system.  These
   implementations check that the TCP sequence number contained in the
   payload of the ICMP error message is within the range SND.UNA =<
   SEG.SEQ < SND.NXT.  This means that they require that the sequence
   number be within the range of the data already sent but not yet
   acknowledged.  If an ICMP error message does not pass this check, it
   is discarded.

   Even if an attacker were able to guess the four-tuple that identifies
   the TCP connection, this additional check would reduce the
   possibility of considering a spoofed ICMP packet as valid to
   Flight_Size/2^^32 (where Flight_Size is the number of data bytes
   already sent to the remote peer, but not yet acknowledged [RFC2581]).
   For connections in the SYN-SENT or SYN-RECEIVED states, this would
   reduce the possibility of considering a spoofed ICMP packet as valid
   to 1/2^^32.  For a TCP endpoint with no data "in flight", this would
   completely eliminate the possibility of success of these attacks.

   This validation check has been implemented in Linux [Linux] for many
   years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and
   NetBSD [NetBSD] since 2005.

   It is important to note that while this check greatly increases the
   number of packets required to perform any of the attacks discussed in
   this document, this may not be enough in those scenarios in which
   bandwidth is easily available, and/or large TCP windows [RFC1323] are
   in use.  Additionally, this validation check does not help to prevent
   on-path attacks, that is, attacks performed in scenarios in which the
   attacker can sniff the packets that correspond to the target TCP
   connection.

   It should be note that as there are no timeliness for ICMP error
   messages, the TCP Sequence Number check described in this section
   might cause legitimate ICMP error messages to be discarded.

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.ietf-tsvwg-port-randomization] 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 can be implemented in middlebox devices
   such as firewalls and NATs.  Middleboxes implementing such advanced
   filtering look at the payload of the ICMP error messages, and perform
   ingress and egress packet filtering based on the source 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 serves as a counter-
   measure against these attacks.  As with traditional egress filtering
   [IP-filtering], egress filtering based on the ICMP payload can help
   to prevent users of the network being protected by the firewall from
   successfully performing ICMP attacks against TCP connections
   established between external systems.  Additionally, ingress
   filtering based on the ICMP payload can prevent TCP connections
   established between internal systems from 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
   Filter [OpenBSD-PF], which has in turn been ported to a number of
   systems, including FreeBSD [FreeBSD].

5.  Blind connection-reset attack

5.1.  Description

   When TCP is handed an ICMP error message, it will perform its fault
   recovery function, as follows:

   o  If the network problem being reported is a hard error, TCP will
      abort the corresponding connection.

   o  If the network problem being reported is a soft error, TCP will
      just record this information, and repeatedly retransmit its data
      until they either get acknowledged, or the connection times out.

   The Host Requirements RFC [RFC1122] states (in Section 4.2.3.9) that
   a host SHOULD abort the corresponding connection when receiving an
   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.
   In the case of ICMP port unreachables, the specifications are
   ambiguous, as Section 4.2.3.9 of [RFC1122] states that TCP SHOULD
   abort the corresponding connection in response to them, but Section
   3.2.2.1 of the same RFC ([RFC1122] states that TCP MUST abort the
   connection in response to them.

   While [RFC4443] did not exist when [RFC1122] was published, one could
   extrapolate the concept of "hard errors" to ICMPv6 error messages of
   type 1 (Destination unreachable) codes 1 (communication with
   destination administratively prohibited), and 4 (port unreachable).

   Thus, an attacker could use ICMP to perform a blind connection-reset
   attack by sending any ICMP error message that indicates a "hard
   error", to either of the two TCP endpoints of the connection.
   Because of TCP's fault recovery policy, the connection would be
   immediately aborted.

   Some stacks are known to extrapolate ICMP hard errors across TCP
   connections, increasing the impact of this attack, as a single ICMP
   packet could bring down all the TCP connections between the
   corresponding peers.

   It is important to note that even if TCP itself were protected
   against the blind connection-reset attack described in [Watson] and
   [I-D.ietf-tcpm-tcpsecure], by means authentication at the network
   layer [RFC4301], by means of the TCP MD5 signature option [RFC2385],
   by means of the TCP-AO [I-D.ietf-tcpm-tcp-auth-opt], or by means of
   the mechanism proposed in [I-D.ietf-tcpm-tcpsecure], the blind
   connection-reset attack described in this document would still
   succeed.

5.2.  Attack-specific counter-measures

   This section describes a modification to TCP's reaction to ICMP hard
   errors that has been incorporated in a large number of TCP
   implementations.

   An analysis of each of the different ICMP "hard
   error" messages is included circumstances in Appendix A.

   TCPs implementing this modification treat all which ICMP "hard errors" messages that indicate
   hard errors may be received for connections in any of the synchronized states
   (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK
   or TIME-WAIT)as "soft errors".  Therefore, they do not abort can shed some light to mitigate the
   corresponding connection upon receipt
   impact of them.  Additionally, they do
   not extrapolate ICMP-based blind connection-reset attacks.

   ICMP errors across TCP connections. type 3 (Destination Unreachable), code 2 (protocol unreachable)

      This policy is
   based on the premise ICMP error message indicates that TCP should be as robust as possible.
   Aborting the connection would be to ignore the valuable feature of
   the Internet that for many internal failures it reconstructs its
   function without any disruption of host sending the end points [RFC0816].

   It is interesting to note that, as ICMP
      error messages are
   unreliable, message received a packet meant for a transport protocols should protocol it
      does not depend on them for correct
   functioning.  In the event support.  For connection-oriented protocols such as TCP,
      one of these messages were legitimate, could expect to receive such an error as the
   corresponding connection result of a
      connection-establishment attempt.  However, it would eventually time out.  Also,
   applications may still be notified asynchronously about the error
   contition, and thus may still abort their connections on their own if
   they consider it appropriate.

   In scenarios strange to
      get such as that in which an intermediate system sets the DF
   bit in error during the segments transmitted by life of a TCP connection, as this would
      indicate that does not implement
   PMTUD, or support for that transport protocol has been removed
      from the TCP at one of system sending the endpoints error message during the life of the connection is
   dynamically disabled, TCP would only abort
      corresponding connection.

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

      This error message indicates that the connection after system sending the ICMP
      error message received a
   USER TIMEOUT [RFC0793], losing responsiveness.  However, these
   scenarios are very unlikely in production environments, and it packet meant for a socket (IP address,
      port number) on which there is
   probably preferebable to potentially lose responsiveness no process listening.  Those
      transport protocols which have their own mechanisms for the sake
   of robustness.  It notifying
      this condition should also not be noted that applications may still
   be notified asynchronously about the receiving these error condition, and thus may
   still abort their connections on their messages, as
      the protocol would signal the port unreachable condition by means
      of its own if they consider messages.  Assuming that once a connection is
      established it
   appropriate.

   In scenarios of multipath routing or route changes, failures in some
   (but is not all) of usual for the paths may elicit transport protocol to change
      (or be reloaded), it should be unusual to get these error
      messages.

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

      This error messages message indicates that would
   likely not cause an intermediate node needed to
      fragment a connection abort if any of datagram, but the counter-measures
   described DF (Don't Fragment) bit in this section were implemented.  However, aborting the
   connection would be to ignore the valuable feature of the Internet
   that for many internal failures it reconstructs its function without
   any disruption of the end points [RFC0816].  That is, communication
   should survive if there IP
      header was set.  It is still considered a working path to the destination
   system [DClark].  Additionally, applications may still be notified
   asynchronously about the soft error condition, when TCP implements
      PMTUD, and thus may still abort
   their connections on their own a hard error if they consider it appropriate.

   This counter-measure has been implemented in BSD-derived TCP does not implement PMTUD.  Those
      TCP/IP
   implementations (e.g., [FreeBSD], [NetBSD], stacks that do not implement PMTUD (or have disabled it)
      but support IP fragmentation/reassembly should not be sending
      their IP packets with the DF bit set, and [OpenBSD]) for more
   than ten years [Wright][McKusick].  The Linux kernel has also
   implemented this policy for more than ten years [Linux].

6.  Blind throughput-reduction attack

6.1.  Description

   The Host requirements RFC [RFC1122] states in Section 4.2.3.9 thus should not be
      receiving these ICMP error messages.  Some TCP/IP stacks that
   hosts MUST react do
      not implement PMTUD and that do not support IP fragmentation/
      reassembly are known to ICMP Source Quench messages by slowing
   transmission on send their packets with the connection.  Thus, an attacker DF bit set,
      and thus could send legitimately receive these ICMP
   Source Quench (type 4, error messages.

   ICMPv6 type 1 (Destination Unreachable), 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 1 (communication with
   destination administratively prohibited)

      This error message indicates that the RECOMMENDED procedure destination is unreachable
      because of an administrative policy.  For connection-oriented
      protocols such as TCP, one could expect to put receive such an error
      as the corresponding result of a connection-establishment attempt.  Receiving
      such an error for a connection in the slow-start phase any 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 synchronized states
      would reduce mean that the throughput administrative policy changed during the life
      of the attacked
   connection to about SMSS (Sender Maximum Segment Size) [RFC2581]
   bytes per RTT (round-trip time).  The throughput achieved during an
   attack might be a little higher if a larger initial congestion window
   is in use [RFC3390].

6.2.  Attack-specific counter-measures

   As discussed connection.  However, in the Requirements for IP Version 4 Routers RFC
   [RFC1812], research seems to suggest that ICMP Source Quench same way this error condition
      (which was not present when the conenction was established)
      appeared, it could get solved solved in the near term.

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

      This error message is an
   ineffective (and unfair) antidote for congestion.  [RFC1812] further analogous to the ICMP type 3 (Destination
      Unreachable), code 3 (Port unreachable) error message discussed
      above.  Therefore, the same considerations apply.

   The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that routers
   TCP SHOULD NOT send ICMP Source Quench messages abort the corresponding connection 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.

   Based on this reasoning, a large number of implementations completely
   ignore ICMP Source Quench
   messages meant for TCP connections.  This
   behavior has been implemented in, at least, Linux [Linux] since 2004, of type 3, codes 2 (protocol unreachable), 3 (port
   unreachable), and in FreeBSD [FreeBSD], NetBSD [NetBSD], 4 (fragmentation needed and OpenBSD [OpenBSD]
   since 2005. DF bit set).  However, it must be noted
   Section 3.2.2.1 states that this behaviour violates TCP MUST accept an ICMP port unreachable
   (type 3, code 3) for the requirement in [RFC1122] to react to same purpose as an RST.  Therefore, for ICMP Source Quench
   messages
   by slowing transmission on the connection.

7.  Blind performance-degrading attack

7.1.  Description

   When one IP system has a large amount of data to send type 3 codes 2 and 4 there is room to another
   system, go against the data will be transmitted as a series
   advice provided in the existing specifications, while in the case of IP datagrams.  It
   is usually preferable that these datagrams be
   ICMP messages of type 3 code 3 there is ambiguity in the largest size
   specifications that does may or may not require fragmentation anywhere along the path from the
   source provide some room to go against
   that advice.

   Based on this analysis, most popular TCP implementations treat all
   ICMP "hard errors" received for connections in any of the destination.
   synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
   CLOSING, LAST-ACK or TIME-WAIT)as "soft errors".  That is, they do
   not abort the corresponding connection upon receipt of them.
   Additionally, they do not extrapolate ICMP errors across TCP
   connections.  This datagram size policy is referred to based on the premise that TCP should be
   as robust as possible.  Aborting the
   Path MTU (PMTU), and is equal connection would be to ignore
   the minimum valuable feature of the MTUs Internet that for many internal failures
   it reconstructs its function without any disruption of each hop
   in the path.  A technique called "Path MTU Discovery" (PMTUD) lets IP
   systems determine end points
   [RFC0816].

   It is interesting to note that, as ICMP error messages are
   unreliable, transport protocols should not depend on them for correct
   functioning.  In the Path MTU event one of an arbitrary internet path.
   [RFC1191] and [RFC1981] specify these messages were legitimate, the PMTUD mechanism for IPv4
   corresponding connection would eventually time out.  Also,
   applications may still be notified asynchronously about the error
   contition, and
   IPv6, respectively.

   The PMTUD mechanism for IPv4 uses thus may still abort their connections on their own if
   they consider it appropriate.

   In scenarios such as that in which an intermediate system sets the Don't Fragment (DF) DF
   bit in the
   IP header to dynamically discover the Path MTU.  The basic idea
   behind the PMTUD mechanism is that segments transmitted by a source system assumes TCP that does not implement
   PMTUD, or the
   MTU of the path is that TCP at one of the first hop, and sends all its datagrams
   with the DF bit set.  If any endpoints of the datagrams connection is too large to be
   forwarded without fragmentation by some intermediate router, the
   router will discard
   dynamically disabled, TCP would only abort the corresponding datagram, and will return an
   ICMP "Destination Unreachable" (type 3) "fragmentation neeed connection after a
   USER TIMEOUT [RFC0793], losing responsiveness.  However, these
   scenarios are very unlikely in production environments, and DF
   set" (code 4) error message it is
   probably preferable to potentially lose responsiveness for the sending system.  This message will
   report the MTU sake
   of the constricting hop, so robustness.  It should also be noted that applications may still
   be notified asynchronously about the sending system
   can reduce error condition, and thus may
   still abort their connections on their own if they consider it
   appropriate.

   In scenarios of multipath routing or route changes, failures in some
   (but not all) of the assumed Path-MTU accordingly.

   For IPv6, intermediate systems do paths may elicit ICMP error messages that would
   likely not fragment packets.  Thus,
   there's an "implicit" DF bit set in every packet sent on cause a network.
   If connection abort if any of the datagrams is too large to counter-measures
   described in this section were implemented.  However, aborting the
   connection would be forwarded without
   fragmentation by some intermediate router, to ignore the router will discard valuable feature of the corresponding datagram, and will return an ICMPv6 "Packet Too
   Big" (type 2, code 0) error message to sending system.  This message
   will report the MTU Internet
   that for many internal failures it reconstructs its function without
   any disruption of the constricting hop, so that end points [RFC0816].  That is, communication
   should survive if there is still a working path to the sending destination
   system can reduce [DClark].  Additionally, applications may still be notified
   asynchronously about the assumed Path-MTU accordingly.

   As discussed error condition, and thus may still abort
   their connections on their own if they consider it appropriate.

   This counter-measure has been implemented in both [RFC1191] BSD-derived TCP/IP
   implementations (e.g., [FreeBSD], [NetBSD], and [RFC1981], the Path-MTU Discovery
   mechanism can be used to [OpenBSD]) for more
   than ten years [Wright][McKusick].  The Linux kernel has also
   implemented this policy for more than ten years [Linux].

6.  Blind throughput-reduction attack TCP.  An

6.1.  Description

   The Host requirements RFC [RFC1122] states in Section 4.2.3.9 that
   hosts MUST react to ICMP Source Quench messages by slowing
   transmission on the connection.  Thus, an attacker could send a forged ICMP "Destination Unreachable, fragmentation needed and DF set"
   packet (or their ICMPv6 counterpart)
   Source Quench (type 4, code 0) messages to the sending system,
   advertising a small Next-Hop MTU.  As a result, the attacked system
   would TCP endpoint to make it
   reduce the size of the packets rate at which it sends for data to the corresponding
   connection accordingly.

   The effect other end-point of this attack is two-fold.  On one hand, it will increase the headers/data ratio, thus increasing
   connection.  [RFC1122] further adds that the overhead needed to send
   data RECOMMENDED procedure is
   to put the remote TCP end-point.  On corresponding connection in the other hand, if slow-start phase of TCP's
   congestion control algorithm [RFC2581].  In the attacked
   system wanted to keep case of those
   implementations that use an initial congestion window of one segment,
   a sustained attack would reduce the same throughput it was achieving before
   being attacked, it would have to increase of the packet rate.  On
   virtually all systems this will lead attacked
   connection to about SMSS (Sender Maximum Segment Size) [RFC2581]
   bytes per RTT (round-trip time).  The throughput achieved during an increase
   attack might be a little higher if a larger initial congestion window
   is in use [RFC3390].

6.2.  Attack-specific counter-measures

   As discussed in the IRQ
   (Interrrupt ReQuest) rate and protocol processing time, thus
   increasing processor utilization, and degrading the overall system
   performance.

   A particular scenario Requirements for IP Version 4 Routers RFC
   [RFC1812], research seems to suggest that may take place ICMP Source Quench is an
   ineffective (and unfair) antidote for congestion.  [RFC1812] further
   states that routers SHOULD NOT send ICMP Source Quench messages in which an
   attacker reports a Next-Hop MTU smaller than or equal
   response to the amount
   of bytes needed for headers (IP header, plus congestion.  Furthermore, TCP header).  For
   example, if the attacker reports implements its own
   congestion control mechanisms [RFC2581] [RFC3168], that do not depend
   on ICMP Source Quench messages.

   Based on this reasoning, a Next-Hop MTU of 68 bytes, and the
   amount large number of bytes used implementations completely
   ignore ICMP Source Quench messages meant for headers (IP header, plus TCP header) is
   larger than 68 bytes, the assumed Path-MTU will not even allow the
   attacked system to send a single byte of application data without
   fragmentation. connections.  This particular scenario might lead to unpredictable
   results.  Another posible scenario is that
   behavior has been implemented in, at least, Linux [Linux] since 2004,
   and in which a TCP connection
   is being secured by means of IPSec.  If FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD]
   since 2005.  However, it must be noted that this behaviour violates
   the Next-Hop MTU reported requirement in [RFC1122] to react to ICMP Source Quench messages
   by slowing transmission on the attacker is smaller than the connection.

7.  Blind performance-degrading attack

7.1.  Description

   When one IP system has a large amount of bytes needed for headers
   (IP and IPSec, in this case), data to send to another
   system, the assumed Path-MTU 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 even
   allow require fragmentation anywhere along the attacked system path from the
   source to send a single byte of the TCP header
   without fragmentation. destination.  This datagram size is another scenario that may lead referred to
   unpredictable results.

   For IPv4, as the reported Next-Hop
   Path MTU could be as low as 68 octets, as
   [RFC0791] requires every internet module to be able (PMTU), and is equal 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

   This section describes a modification to of the PMTUD mechanism
   specified MTUs of each hop
   in the path.  A technique called "Path MTU Discovery" (PMTUD) lets IP
   systems determine the Path MTU of an arbitrary internet path.
   [RFC1191] and [RFC1981] that has been implemented in a
   variety of TCP implementations to improve TCP's resistance to specify the
   blind performance-degrading attack described PMTUD mechanism for IPv4 and
   IPv6, respectively.

   The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in Section 7.1. the
   IP header to dynamically discover the Path MTU.  The
   described basic idea
   behind the PMTUD mechanism basically disregards ICMP messages when is that a
   connection makes progress.  This modification does not violate source system assumes that the
   MTU of the path is that of the first hop, and sends all its datagrams
   with the DF bit set.  If any of the requirements stated in [RFC1191] datagrams is too large to be
   forwarded without fragmentation by some intermediate router, the
   router will discard the corresponding datagram, and [RFC1981].

   Henceforth, we will refer to both return an
   ICMP "Destination Unreachable" (type 3) "fragmentation needed neeed and DF
   bit
   set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too
   Big" messages.

   In addition (code 4) error message to the general validation check described sending system.  This message will
   report the MTU of the constricting hop, so that the sending system
   can reduce the assumed Path-MTU accordingly.

   For IPv6, intermediate systems do not fragment packets.  Thus,
   there's an "implicit" DF bit set in Section 4.1,
   these implementations include every packet sent on a modification to TCP's reaction network.
   If any of the datagrams is too large to
   ICMP 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 messages message to sending system.  This message
   will report the MTU of the constricting hop, so that disregards them when a
   connection makes progress, the sending
   system can reduce the assumed Path-MTU accordingly.

   As discussed in both [RFC1191] and honors them only after [RFC1981], the
   corresponding data have been retransmitted Path-MTU Discovery
   mechanism can be used to attack TCP.  An attacker could send a specified number of
   times.  This means that upon receipt of an forged
   ICMP "Packet Too Big"
   error message, TCP just records this information, "Destination Unreachable, fragmentation needed and honors it only
   when DF set"
   packet (or their ICMPv6 counterpart) to the corresponding data have already been retransmitted sending system,
   advertising a
   specified number of times.

   While this basic policy would greatly mitigate the impact of the
   attack against small Next-Hop MTU.  As a result, the PMTUD mechanism, it attacked system
   would also mean that it might
   take TCP more time to discover reduce 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 size of the corresponding timeouts) before packets it discovers the PMTU sends for the corresponding connection.  Thus,
   connection accordingly.

   The effect of this policy would attack is two-fold.  On one hand, it will increase
   the time
   it takes for data headers/data ratio, thus increasing the overhead needed to begin send
   data to be received at the destination host.

   In order to protect remote TCP from end-point.  On the attack against other hand, if the PMTUD mechanism,
   while still allowing TCP attacked
   system wanted to quickly determine the initial Path-MTU
   for a connection, keep the aforementioned implementations same throughput it was achieving before
   being attacked, it would have divided to increase the
   traditional PMTUD mechanism into two stages: Initial Path-MTU
   Discovery, and Path-MTU Update.

   The Initial Path-MTU Discovery stage is when TCP tries to send
   segments that are larger than the ones that have so far been sent and
   acknowledged for packet rate.  On
   virtually all systems this connection.  That is, in the Initial Path-MTU
   Discovery stage TCP has no record of these large segments getting will lead to an increase in the destination host, IRQ
   (Interrrupt ReQuest) rate and protocol processing time, thus these implementations believe
   increasing processor utilization, and degrading the
   network when it reports overall system
   performance.

   A particular scenario that these packets are too large to reach the
   destination host without being fragmented.

   The Path-MTU Update stage may take place is when TCP tries to send segments that are
   equal to or in which an
   attacker reports a Next-Hop MTU smaller than or equal to the ones that have already been sent and
   acknowledged amount
   of bytes needed for this connection.  During the Path-MTU Update stage, headers (IP header, plus TCP already has knowledge header).  For
   example, if the attacker reports a Next-Hop MTU of 68 bytes, and the estimated Path-MTU
   amount of bytes used for headers (IP header, plus TCP header) is
   larger than 68 bytes, the given
   connection.  Thus, in this case these implementations are more
   cautious with assumed Path-MTU will not even allow the errors
   attacked system 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 network.

   In order to allow TCP to distinguish segments between those
   performing Initial Path-MTU Discovery attacker is smaller than the amount of bytes needed for headers
   (IP and those performing IPSec, in this case), the assumed Path-MTU
   Update, two new variables are introduced to TCP: maxsizeacked and
   maxsizesent.

   maxsizesent holds will not even
   allow the size (in octets) attacked system to send a single byte of the largest packet that has
   so far been sent for this connection.  It TCP header
   without fragmentation.  This is initialized another scenario that may lead to 68 (the
   minimum IPv4 MTU) when
   unpredictable results.

   For IPv4, the underlying reported Next-Hop MTU could be as low as 68 octets, as
   [RFC0791] requires every internet protocol is IPv4, and
   is initialized 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) when the underlying
   internet protocol is IPv6.  Whenever [RFC2460].

7.2.  Attack-specific counter-measures

   The IETF has standardized a packet larger than maxsizesent
   octets is sent, maxsizesent is set to Path-MTU Discuvery mechanism called
   "Packetization Layer Path MTU Discovery" that value.

   On does not depend on ICMP
   error messages.  Implementation of the other hand, maxsizeacked holds aforementioned mechanism in
   replacement of the size (in octets) traditional PMTUD (specified in [RFC1191] and
   [RFC1981]) would eliminate this vulnerability.  However, it might
   also lead to an increase of the
   largest packet PMTUD convergence time.

   This section describes a modification to the PMTUD mechanism
   specified in [RFC1191] and [RFC1981] that has so far been acknowledged for this connection.
   It is initialized implemented in a
   variety of TCP implementations to 68 (the minimum IPv4 MTU) when the underlying
   internet protocol is IPv4, and is initialized improve TCP's resistance to 1280 (the minimum
   IPv6 MTU) when the underlying internet protocol is IPv6.  Whenever an
   acknowledgement for
   blind performance-degrading attack described in Section 7.1.  The
   described mechanism basically disregards ICMP messages when a packet larger than maxsizeacked octets is
   received, maxsizeacked is set
   connection makes progress.  This modification does not violate any of
   the requirements stated in [RFC1191] and [RFC1981].

   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 size general validation check described in Section 4.1,
   these implementations include a modification to TCP's reaction to
   ICMP "Packet Too Big" error messages that disregards them when a
   connection makes progress, and honors them only after the
   corresponding data have been retransmitted a specified number of
   times.  This means that acknowledged
   packet.

   Upon upon receipt of an ICMP "Packet Too Big"
   error message, TCP just records this information, and honors it only
   when the Next-Hop
   MTU claimed by corresponding data have already been retransmitted a
   specified number of times.

   While this basic policy would greatly mitigate the ICMP message (henceforth "claimedmtu") is compared
   with maxsizesent.  If claimedmtu is equal to or larger than
   maxsizesent, then impact of the ICMP error message is silently discarded.  The
   rationale for this is that
   attack against the ICMP error message cannot be
   legitimate if PMTUD mechanism, it claims would also mean that it might
   take TCP more time to have been elicited by a packet larger than discover the largest packet we have so far sent Path-MTU for this connection.

   If this check is passed, claimedmtu is compared with maxsizeacked.
   If claimedmtu is equal to or larger than maxsizeacked, a TCP is
   supposed connection.
   This would be particularly annoying for connections that have just
   been established, as it might take TCP several transmission attempts
   (and the corresponding timeouts) before it discovers the PMTU for the
   corresponding connection.  Thus, this policy would increase the time
   it takes for data to begin to be received at the destination host.

   In order to protect TCP from the attack against the PMTUD mechanism,
   while still allowing TCP to quickly determine the initial Path-MTU
   for a connection, the aforementioned implementations have divided the
   traditional PMTUD mechanism into two stages: Initial Path-MTU Discovery stage,
   Discovery, and thus the
   ICMP "Packet Too Big" error message Path-MTU Update.

   The Initial Path-MTU Discovery stage is honored immediately. 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 assumed Initial Path-MTU is updated according
   Discovery stage TCP has no record of these large segments getting to
   the Next-Hop MTU claimed
   in destination host, and thus these implementations believe the ICMP error message.  Also, maxsizesent is reset
   network when it reports that these packets are too large to reach the minimum
   MTU of
   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 internet protocol in use (68 for IPv4, ones that have already been sent and 1280
   acknowledged for IPv6).

   On this connection.  During the other hand, if claimedmtu is smaller than maxsizeacked, Path-MTU Update stage,
   TCP is
   supposed to be in already has knowledge of the estimated Path-MTU Update stage.  At for the given
   connection.  Thus, in this stage, case these implementations are more
   cautious with the errors being reported by the network, and therefore just record the received error message,
   and delay the update of the assumed Path-MTU.

   To perform this delay, one new variable network.

   In order to allow TCP to distinguish segments between those
   performing Initial Path-MTU Discovery and one those performing Path-MTU
   Update, two new parameter is variables are introduced to TCP: nsegrto maxsizeacked and MAXSEGRTO. nsegrto
   maxsizesent.

   maxsizesent holds the number size (in octets) of
   times a specified segment the largest packet that has timed out.
   so far been sent for this connection.  It is initialized to zero, 68 (the
   minimum IPv4 MTU) when the underlying internet protocol is IPv4, and
   is incremented by one every time the corresponding segment times
   out.  MAXSEGRRTO specifies initialized to 1280 (the minimum IPv6 MTU) when the number of times underlying
   internet protocol is IPv6.  Whenever 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 packet larger than or equal maxsizesent
   octets is sent, maxsizesent is set to
   0.

   Thus, if nsegrto that value.

   On the other hand, maxsizeacked holds the size (in octets) of the
   largest packet that has so far been acknowledged for this connection.
   It is greater than or equal initialized to MAXSEGRTO, 68 (the minimum IPv4 MTU) when the underlying
   internet protocol is IPv4, and there's is initialized to 1280 (the minimum
   IPv6 MTU) when the underlying internet protocol is IPv6.  Whenever an
   acknowledgement for a
   pending packet larger than maxsizeacked octets is
   received, maxsizeacked is set to the size of that acknowledged
   packet.

   Upon receipt of an ICMP "Packet Too Big" error message, the corresponding error Next-Hop
   MTU claimed by the ICMP message (henceforth "claimedmtu") is processed.  At that point, maxsizeacked is set to
   claimedmtu, and maxsizesent compared
   with maxsizesent.  If claimedmtu is set equal to 68 (for IPv4) or 1280 (for
   IPv6).

   If while there is a pending larger than
   maxsizesent, then the ICMP "Packet Too Big" error message the
   TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK
   that acknowledges that sequence number is received), then the
   "pending error" condition is cleared. silently discarded.  The
   rationale behind performing for 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 error message cannot be
   legitimate if it claims to have been elicited by a false claim.
   By checking for progress on the connection, rather packet larger than just for
   staleness of
   the received ICMP messages, TCP largest packet we have so far sent for this connection.

   If this check is protected from attack
   even if the offending ICMP messages are "in window", and as a
   corollary, passed, claimedmtu is compared with maxsizeacked.
   If claimedmtu is made more robust to spurious ICMP messages elicited by,
   for example, corrupted TCP segments.

   MAXSEGRTO can be set, in principle, to any value greater than or equal to 0.  Setting MAXSEGRTO to 0 would make or larger than maxsizeacked, TCP perform the
   traditional PMTUD mechanism defined in [RFC1191] and [RFC1981].  A
   MAXSEGRTO of 1 provides enough protection for most cases.  In any
   case, implementations are free is
   supposed to choose higher values for this
   constant.  MAXSEGRTO could be a function of at the Next-Hop MTU claimed
   in Initial Path-MTU Discovery stage, and thus the received
   ICMP "Packet Too Big" message. error message is honored immediately.  That is, higher
   values for MAXSEGRTO could be imposed when
   the received ICMP "Packet
   Too Big" message claims a assumed Path-MTU is updated according to the Next-Hop MTU that is smaller than some
   specified value.

   In claimed
   in the event a higher level of protection ICMP error message.  Also, maxsizesent is desired at reset to the expense minimum
   MTU of a higher delay in the discovery of internet protocol in use (68 for IPv4, and 1280 for IPv6).

   On the Path-MTU, an implementation
   could consider other hand, if claimedmtu is smaller than maxsizeacked, TCP is
   supposed to always be in the Path-MTU Update stage.  At this stage, thus
   always delaying these
   implementations are more cautious with the errors being reported by
   the network, and therefore just record the received error message,
   and delay the update of the assumed Path-MTU.

   Section 7.3 shows the proposed counter-measure in action.
   Section 7.4 shows the proposed counter-measure in pseudo-code.

   This behavior has been implemented in NetBSD [NetBSD]

   To perform this delay, one new variable and OpenBSD
   [OpenBSD] since 2005.

   It one new parameter is important
   introduced to note that TCP: nsegrto and MAXSEGRTO. nsegrto holds the mechanism proposed in this section number of
   times a specified segment has timed out.  It is an improvement to the current Path-MTU discovery mechanism, initialized to
   mitigate its security implications.  The current PMTUD mechanism, as
   specified by [RFC1191] zero,
   and [RFC1981], still suffers from some
   functionality problems [RFC2923] that this document does not aim to
   address.  A mechanism that addresses those issues is described in
   [RFC4821].

7.3.  The counter-measure for the PMTUD attack in action

   This SECTION shows incremented by one every time the proposed counter-measure for corresponding segment times
   out.  MAXSEGRRTO specifies the number of times a given segment must
   timeout before an ICMP attack
   against the PMTUD mechanism in action.  It shows both how the fix
   protects TCP from being attacked "Packet Too Big" error message can be honored,
   and how the counter-measure works in
   normal scenarios.  As discussed can be set, in Section 7.2, this section assumes 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 PMTUD-specific counter-measure corresponding error
   message is implemented in addition processed.  At that point, maxsizeacked is set to
   claimedmtu, and maxsizesent is set to 68 (for IPv4) or 1280 (for
   IPv6).

   If while there is a pending ICMP "Packet Too Big" error message the
   TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK
   that acknowledges that sequence number 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 is received), then the
   MTU
   "pending error" condition is cleared.

   The rationale behind performing this delayed processing of each hypothetical hop.  All ICMP
   "Packet Too Big" messages is that if there is progress on the following subsections assume
   connection, the network setup of this figure.

   Also, for simplicity sake, all subsections assume an IP header of 20
   octets and ICMP "Packet Too Big" errors must be a TCP header of 20 octets.  Thus, false claim.

   By checking for example, when progress on the
   PMTU is assumed to be 1500 octets, TCP will send segments that
   contain, at most, 1460 octets connection, rather than just for
   staleness of data.

   For simplicity sake, all the following subsections assume the received ICMP messages, TCP
   implementation at Host 1 has chosen a is protected from attack
   even if the offending ICMP messages are "in window", and as a
   corollary, is made more robust to spurious ICMP messages elicited by,
   for example, corrupted TCP segments.

   MAXSEGRTO can be set, in principle, to any value greater than or
   equal to 0.  Setting MAXSEGRTO to 0 would make TCP perform the
   traditional PMTUD mechanism defined in [RFC1191] and [RFC1981].  A
   MAXSEGRTO of 1.

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

                      Figure 1: Hypothetical scenario

7.3.1.  Normal operation 1 provides enough protection for bulk transfers

   This subsection shows most cases.  In any
   case, implementations are free to choose higher values for this
   constant.  MAXSEGRTO could be a function of the proposed counter-measure Next-Hop MTU claimed
   in normal
   operation, when a TCP connection is used for bulk transfers. the received ICMP "Packet Too Big" message.  That is, it shows how the proposed counter-measure works higher
   values for MAXSEGRTO could be imposed when there the received ICMP "Packet
   Too Big" message claims a Next-Hop MTU that is no
   attack taking place, and smaller than some
   specified value.

   In the event a TCP connection higher level of protection is used for transferring
   large amounts desired at the expense
   of data.  This section assumes that just after a higher delay in the
   connection is established, one discovery of the Path-MTU, an implementation
   could consider TCP endpoints begins to
   transfer data always be in packets that are as large as possible.

      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 Path-MTU Update stage, thus
   always delaying the internet protocol being
   used (68 for IPv4, and 1280 for IPv6).

   In lines 1 to 3 update of the three-way handshake takes place, assumed Path-MTU.

   Section 7.3 shows the proposed counter-measure in action.
   Section 7.4 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
   connection mechanism proposed in this section
   is established.  In line 4, H1 tries an improvement to send a full-sized
   TCP segment.  As described the current Path-MTU discovery mechanism, to
   mitigate its security implications.  The current PMTUD mechanism, as
   specified by [RFC1191] and [RFC1981], in still suffers from some
   functionality problems [RFC2923] that this case
   TCP will try document does not aim to send a segment with 4424 bytes of data, which will
   result in an IP packet of 4464 octets.  Therefore, maxsizesent
   address.  A mechanism that addresses those issues is set
   to 4464.  When described in
   [RFC4821].

7.3.  The counter-measure for the packet reaches R1, it elicits an ICMP "Packet Too
   Big" error message.

   In line 5, H1 receives PMTUD attack in action

   This SECTION shows the proposed counter-measure for the ICMP error message, which reports a Next-
   Hop MTU of 2048 octets.  After performing attack
   against the TCP sequence number
   check described PMTUD mechanism 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 action.  It shows both how the check, fix
   protects TCP from being attacked and thus is then
   compared with maxsizeacked. how the counter-measure works in
   normal scenarios.  As claimedmtu is larger than
   maxsizeacked, TCP discussed in Section 7.2, this section assumes that the corresponding TCP segment was
   performing
   the Initial PMTU Discovery.  Therefore, PMTUD-specific counter-measure is implemented in addition to the
   TCP at H1
   honors the ICMP message sequence number checking described in Section 4.1.

   Figure 1 illustrates an hypothetical scenario in which two hosts are
   connected by updating the assumed Path-MTU. maxsizesent
   is reset to means of three intermediate routers.  It also shows the minimum
   MTU of each hypothetical hop.  All the internet protocol in use (68 for
   IPv4, and 1280 for IPv6).

   In line 6, following subsections assume
   the TCP at H1 sends a segment with 2008 bytes network setup of data,
   which results in this figure.

   Also, for simplicity sake, all subsections assume an IP packet header 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 20
   octets and a Next-
   Hop MTU TCP header of 1500 20 octets.  After performing the TCP sequence number
   check, the Next-Hop MTU reported by  Thus, for example, when the ICMP error message
   (claimedmtu)
   PMTU 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, assumed to be 1500 octets, TCP assumes will send segments that the corresponding TCP segment was performing the Initial PMTU
   Discovery.  Therefore, the TCP
   contain, at H1 honors the ICMP message by
   updating the assumed Path-MTU. maxsizesent is reset to the minimum
   MTU most, 1460 octets of data.

   For simplicity sake, all the internet protocol in use.

   In line 8, following subsections assume the TCP
   implementation at H1 sends Host 1 has chosen a segment with 1460 bytes of data,
   which results in an IP packet a MAXSEGRTO of 1500 octets. maxsizesent is thus set
   to 1500.  This packet reaches H2, where it elicits an acknowledgement
   (ACK) segment.

   In line 9, 1.

   +----+        +----+        +----+        +----+        +----+
   | H1 finally gets the acknowledgement |--------| R1 |--------| R2 |--------| R3 |--------| H2 |
   +----+        +----+        +----+        +----+        +----+
         MTU=4464      MTU=2048      MTU=1500      MTU=4464

                      Figure 1: Hypothetical scenario

7.3.1.  Normal operation for bulk transfers

   This subsection shows the data segment.
   As the corresponding packet was larger than maxsizeacked, proposed counter-measure in normal
   operation, when a TCP updates
   maxsizeacked, setting connection is used for bulk transfers.  That
   is, it to 1500.  At this point TCP has discovered shows how the Path-MTU for this TCP connection.

7.3.2.  Operation during Path-MTU changes

   Let us suppose proposed counter-measure works when there is no
   attack taking place, and a TCP connection between H1 and H2 has already been
   established, and that the PMTU is used for transferring
   large amounts of data.  This section assumes that just after 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 established, one of the link
   between R2 and R3 has decreased from 1500 TCP endpoints begins to 1492.  Figure 3
   illustrates how the proposed counter-measure would work
   transfer data in this
   scenario. packets that are as large as possible.

      Host 1                                         Host 2

   1.                     (Path-MTU decreases)
   2.    -->  <SEQ=100><ACK=X><CTL=ACK><DATA=1500>           <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=1492, TCPseq#=100 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
   4.                     (Segment times out)
   5.
   8.    -->  <SEQ=100><ACK=X><CTL=ACK><DATA=1452> <SEQ=101><ACK=X+1><CTL=ACK><DATA=1460>  -->
   6.
   9.    <--      <SEQ=X><ACK=1552><CTL=ACK>      <SEQ=X+1><ACK=1561><CTL=ACK>       <--

               Figure 3: Operation during Path-MTU changes

   In line 1, 2: Normal operation for bulk transfers

   nsegrto is initialized to zero.  Both maxsizeacked and maxsizesent
   are initialized to the Path-MTU minimum MTU for this connection decreases from 1500 the internet protocol being
   used (68 for IPv4, and 1280 for IPv6).

   In lines 1 to
   1492. 3 the three-way handshake takes place, and the
   connection is established.  In line 2, the 4, H1 tries to send a full-sized
   TCP at H1, without being aware of the Path-MTU
   change, sends segment.  As described by [RFC1191] and [RFC1981], in this case
   TCP will try to send a 1500-byte segment with 4424 bytes of data, which will
   result in an IP packet of 4464 octets.  Therefore, maxsizesent is set
   to H2. 4464.  When the packet reaches R2, R1, it elicits an ICMP "Packet Too
   Big" error message.

   In line 3, 5, H1 receives the ICMP error message, which reports a Next-
   Hop MTU of 1492 2048 octets.  After performing the TCP sequence number
   check,
   check described in Section 4.1, the Next-Hop MTU reported by the ICMP
   error message (claimedmtu) is compared with maxsizesent.  As claimedmtu it is
   smaller than maxsizesent, it is then passes the check, and thus is then
   compared with maxsizeacked.  As claimedmtu is smaller larger than maxsizeacked (full-sized packets were
   getting to
   maxsizeacked, TCP assumes that the remote end-point), this packet is assumed to be corresponding TCP segment was
   performing Path-MTU Update.  And a "pending error" condition is
   recorded.

   In line 4, the segment times out.  Thus, nsegrto is incremented Initial PMTU Discovery.  Therefore, the TCP at H1
   honors the ICMP message by 1.
   As nsegrto is greater than or equal to MAXSEGRTO, updating the assumed Path-
   MTU is updated. nsegrto is reset to 0, and maxsizeacked is set to
   claimedmtu, and Path-MTU. maxsizesent
   is set reset to the minimum MTU of the internet protocol in use. use (68 for
   IPv4, and 1280 for IPv6).

   In line 5, H1 retransmits the data using 6, the updated PMTU, and thus 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 1492.  The resulting 2008 bytes.  When the packet reaches H2, where R2, it elicits an acknowledgement (ACK) segment. ICMP
   "Packet Too Big" error message.

   In line 6, 7, H1 finally gets receives the acknowledgement for ICMP error message, which reports a Next-
   Hop MTU of 1500 octets.  After performing the data segment.
   At this point TCP has discovered sequence number
   check, the new Path-MTU for this 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
   connection.

7.3.3.  Idle connection being attacked

   Let us suppose a assumes
   that the corresponding TCP connection between H1 and H2 has already been
   established, and segment was performing the Initial PMTU for
   Discovery.  Therefore, the connection has 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.

7.3.2.  Operation during Path-MTU changes

   Let us suppose a TCP connection between H1 and H2 has already been
   established, and that the PMTU for the connection has already been
   discovered to be 1500.  Figure 4 shows a sample time-line diagram  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 an idle connection being attacked. 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=50>  <SEQ=100><ACK=X><CTL=ACK><DATA=1500>   -->
   2.     <--         <SEQ=X><ACK=150><CTL=ACK>           <--
   3.         <--- ICMP "Packet Too Big" MTU=68, MTU=1492, TCPseq#=100 <--- R2
   4.         <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---                     (Segment times out)
   5.         <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---      -->  <SEQ=100><ACK=X><CTL=ACK><DATA=1452>   -->
   6.      <--      <SEQ=X><ACK=1552><CTL=ACK>         <--

                Figure 4: Idle connection being attacked 3: Operation during Path-MTU changes

   In line 1, H1 sends its last bunch of data.  At the Path-MTU for this connection decreases from 1500 to
   1492.  In line 2, H2
   acknowledges the receipt TCP at H1, without being aware of these data.  Then the connection becomes
   idle.  In lines 3, 4, and 5, an attacker Path-MTU
   change, sends forged a 1500-byte packet to H2.  When the packet reaches R2,
   it elicits an ICMP "Packet Too Big" error messages to H1.  Regardless of how many packets it
   sends and message.

   In line 3, H1 receives the TCP sequence number each ICMP packet includes, none of
   these ICMP error messages will pass message, which reports a Next-
   Hop MTU of 1492 octets.  After performing the TCP sequence number check
   described in Section 4.1, as H1 has no unacknowledged data in flight
   to H2.  Therefore,
   check, the attack does not succeed.

7.3.4.  Active connection being attacked after discovery of Next-Hop MTU reported by the Path-MTU

   Let us suppose an attacker attacks a TCP connection for which 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
   PMTU has already been discovered.  In remote end-point), this case, as illustrated in
   Figure 1, the PMTU would be found packet is assumed to be 1500 bytes.  Figure 5 shows
   performing Path-MTU Update.  And a
   possible packet exchange.

       Host 1                                           Host 2 "pending error" condition is
   recorded.

   In line 4, the segment times out.  Thus, nsegrto is incremented by 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 nsegrto is greater than or equal to 1500.  We assume MAXSEGRTO, the assumed Path-
   MTU is updated. nsegrto is equal reset to zero, as there have been no segment timeouts.

   In lines 1, 2, 3, 0, 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 maxsizeacked is lucky enough set to guess both the four-tuple that identifies
   the connection
   claimedmtu, and a valid TCP sequence number.  As maxsizesent is set to the Next-Hop minimum MTU
   claimed of the internet
   protocol in use.

   In line 5, H1 retransmits the ICMP "Packet Too Big" message (claimedmtu) is smaller
   than maxsizeacked, this packet is assumed to be performing Path-MTU
   Update.  Thus, data using the error message updated PMTU, and thus
   maxsizesent is recorded. set to 1492.  The resulting packet reaches H2, where
   it elicits an acknowledgement (ACK) segment.

   In line 6, H1 receives an finally gets the acknowledgement for the segment sent in
   line 1, before it times out. data segment.
   At this point, the "pending error"
   condition is cleared, and the recorded ICMP "Packet Too Big" error
   message is ignored.  Therefore, point TCP has discovered the attack does not succeed.

7.3.5. new Path-MTU for this TCP peer
   connection.

7.3.3.  Idle connection being attacked when sending small packets just after the
        three-way handshake

   This section analyzes an scenario in which

   Let us suppose a TCP peer that is sending
   small segments just after the connection between H1 and H2 has already been
   established, is
   attacked.  The connection could be being used by protocols such as
   SMTP [RFC2821] and HTTP [RFC2616], the PMTU for example, which usually behave
   like this. the connection has already been
   discovered to be 1500.  Figure 6 4 shows a possible packet exchange for such scenario. sample time-line diagram
   that illustrates an idle connection being attacked.

        Host 1                                           Host 2

   1.     -->          <SEQ=100><CTL=SYN>     <SEQ=100><ACK=X><CTL=ACK><DATA=50>      -->
   2.     <--     <SEQ=X><ACK=101><CTL=SYN,ACK>         <SEQ=X><ACK=150><CTL=ACK>           <--
   3.   -->      <SEQ=101><ACK=X+1><CTL=ACK>        -->         <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
   4.   -->  <SEQ=101><ACK=X+1><CTL=ACK><DATA=100>  -->         <--- ICMP "Packet Too Big" MTU=68, TCPseq#=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 MTU=68, TCPseq#=100 <---

                 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 4: Idle 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. being attacked

   In line 5 this segment is acknowledged, and thus maxsizeacked is set
   to 140.

   In lines 6 and 7, 1, H1 sends two small segments to H2.  In its last bunch of data.  At line 8,
   while 2, H2
   acknowledges the segments from receipt of these data.  Then the connection becomes
   idle.  In lines 6 3, 4, and 7 are still in flight to H2, 5, an attacker sends a forged ICMP "Packet
   Too Big" error message messages to H1.
   Assuming  Regardless of how many packets it
   sends and the attacker is lucky enough to guess a valid TCP sequence
   number, this number each ICMP message packet includes, none of
   these ICMP error messages 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. check
   described in Section 4.1, as H1 has no unacknowledged data in flight
   to H2.  Therefore, the attack does not succeed.

7.4.  Pseudo-code for the counter-measure for the blind performance-
      degrading attack

   This section contains a pseudo-code version of the counter-measure
   described in Section 7.2 for the blind performance-degrading attack
   described in Section 7.  It is meant as guidance for developers on
   how to implement this counter-measure.

   The pseudo-code makes use

7.3.4.  Active connection being attacked after discovery of the following variables, constants, and
   functions:

   ack
      Variable holding the acknowledgement number contained in the Path-MTU

   Let us suppose an attacker attacks a TCP
      segment that has just been received.

   acked_packet_size
      Variable holding the packet size (data, plus headers) connection for which the ACK that
   PMTU has just already been received is acknowledging.

   adjust_mtu()
      Function that adjusts the MTU for discovered.  In 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 case, as illustrated in
   Figure 1, the payload
      of 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" 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 MTU=68, TCPseq#=100 <---
   6.    <--        <SEQ=X><CTL=ACK><ACK=1560>          <--

    Figure 5: Active connection being processed.

   initial_mtu
      Variable holding the MTU for new connections, as explained in
      [RFC1191] and [RFC1981].

   maxsizeacked
      Variable holding attacked after discovery of PMTU

   As we assume the largest packet size (data, plus headers) that PMTU has so far already been acked for this connection, as explained in
      Section 7.2. discovered, we also assume
   both maxsizesent
      Variable holding the largest packet size (data, plus headers) that
      has so far been sent for this connection, as explained in
      Section 7.2. and maxsizeacked are equal to 1500.  We assume
   nsegrto
      Variable holding the number of times this segment has timed out, is equal to zero, as explained in Section 7.2.

   packet_size
      Variable holding 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 size of
   attacker is lucky enough to guess both the IP datagram being sent.

   pending_message
      Variable (flag) four-tuple that indicates whether there is identifies
   the connection and a pending 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 processed.

   save_message()
      Function that records performing Path-MTU
   Update.  Thus, the ICMP "Packet Too Big" error message that has
      just been received.

   MINIMUM_MTU
      Constant holding the minimum MTU is recorded.

   In line 6, H1 receives an acknowledgement for the internet protocol segment sent in use
      (68 for IPv4,
   line 1, before it times out.  At this point, the "pending error"
   condition is cleared, and 1280 for IPv6).

   MAXSEGRTO
      Constant holding the number of times a given segment must timeout
      before an recorded ICMP "Packet Too Big" error
   message can be honored.

   EVENT: New is ignored.  Therefore, the attack does not succeed.

7.3.5.  TCP connection

        current_mtu = initial_mtu;
        maxsizesent = MINIMUM_MTU;
        maxsizeacked = MINIMUM_MTU;
        nsegrto = 0;
        pending_message = 0;

   EVENT: Segment peer attacked when sending small packets just after the
        three-way handshake

   This section analyzes an scenario in which a TCP peer that is sent
        if (packet_size > maxsizesent)
             maxsizesent = packet_size;

   EVENT: Segment sending
   small segments just after the connection has been established, is received

        if (acked_packet_size > maxsizeacked)
             maxsizeacked = acked_packet_size;

        if (pending_message)
             if (ack > claimedtcpseq){
                  pending_message = 0;
                  nsegrto = 0;
             }

   EVENT:
   attacked.  The connection could be being used by protocols such as
   SMTP [RFC2821] and HTTP [RFC2616], for example, which usually behave
   like this.

   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" message MTU=150, TCPseq#=101 <---

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

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

        else {
             if (claimedmtu >= initialized to zero.  Both 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; and 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
   are initialized to the mechanism described in Section 7.2, minimum MTU for the TCP sequence number checking described in Section 4.1, internet protocol being
   used (68 for IPv4, and 1280 for IPv6).

   In lines 1 to 3 the
      validation check on three-way handshake takes place, and the advertised Next-Hop MTU described
   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
      [RFC1191] a 140-byte packet) to H2. maxsizesent is thus set to 140.
   In line 5 this segment is acknowledged, and [RFC1981].

8.  Security Considerations

   This document describes thus maxsizeacked is set
   to 140.

   In lines 6 and 7, H1 sends two small segments to H2.  In line 8,
   while the use of segments from lines 6 and 7 are still in flight to H2, an
   attacker sends a forged ICMP "Packet Too Big" error messages message to perform H1.
   Assuming the attacker is lucky enough to guess a
   number of attacks against valid TCP sequence
   number, this ICMP message will pass the TCP protocol, and describes a sequence number of
   widely-implemented counter-measures that either eliminate or reduce
   the impact of these attacks when they are performed check.
   The Next-Hop MTU reported by off-path
   attackers.

9.  Acknowledgements

   This document was inspired by Mika Liljeberg, while discussing some
   issues related to [I-D.ietf-tcpm-tcp-soft-errors] by private e-mail.
   The author would like to thank (in alphabetical order): Bora Akyol,
   Mark Allman, Ran Atkinson, James Carlson, Alan Cox, Theo de Raadt,
   Ted Faber, Juan Fraschini, Markus Friedl, Guillermo Gont, John
   Heffner, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, Mika
   Liljeberg, Matt Mathis, David Miller, Miles Nordin, Eloy Paris,
   Kacheong Poon, Andrew Powell, Pekka Savola, Pyda Srisuresh, Fred
   Templin, and Joe Touch for contributing many valuable comments.

   Juan Fraschini and the author of this document implemented freely-
   available audit tools to help vendors audit their systems by
   reproducing ICMP error message (claimedmtu) is
   then compared with maxsizesent.  As claimedmtu is larger than
   maxsizesent, the attacks discussed in this document.  This tools are
   available at http://www.gont.com.ar/tools/index.html .

   Markus Friedl, Chad Loder, and ICMP error message is silently discarded.
   Therefore, the author of this document, produced
   and tested in OpenBSD [OpenBSD] attack does not succeed.

7.4.  Pseudo-code for the first implementation counter-measure for the blind performance-
      degrading attack

   This section contains a pseudo-code version of the counter-measure
   described in Section 7.2.  This first implementation
   helped to test the effectiveness of 7.2 for the ideas introduced blind performance-degrading attack
   described in this
   document, and has served Section 7.  It is meant as a reference implementation guidance for other
   operating systems.

   The author would like developers on
   how to thank implement this counter-measure.

   The pseudo-code makes use of the UK's National Infrastructure
   Security Co-ordination Centre (NISCC) for coordinating following variables, constants, and
   functions:

   ack
      Variable holding the disclosure
   of these issues with a large acknowledgement 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 contained in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) 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 Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

10.2.  Informative References

   [DClark]   Clark, D., "The Design Philosophy of ICMP "Packet Too Big" that was last received.

   claimedmtu
      Variable holding the Next-Hop MTU advertised by the DARPA Internet
              Protocols", Computer Communication Review Vol. 18, No. 4,
              1988.

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

   [I-D.ietf-tcpm-tcp-soft-errors]
              Gont, F., "TCP's Reaction to Soft Errors",
              draft-ietf-tcpm-tcp-soft-errors-09 (work in progress),
              November 2008.

   [I-D.ietf-tcpm-tcpsecure]
              Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
              Robustness to Blind In-Window Attacks",
              draft-ietf-tcpm-tcpsecure-11 (work in progress),
              November 2008.

   [I-D.ietf-tsvwg-port-randomization]
              Larsen, M. and F. Gont, "Port Randomization",
              draft-ietf-tsvwg-port-randomization-03 (work in progress),
              March 2009.

   [ICMP-Filtering]
              Gont, F., "Filtering of ICMP error messages",  http://
              www.gont.com.ar/papers/
              filtering-of-icmp-error-messages.pdf.

   [IP-filtering]
              NISCC, "NISCC Technical Note 01/2006: Egress and Ingress
              Filtering",  http://www.niscc.gov.uk/niscc/docs/
              re-20060420-00294.pdf?lang=en, 2006.

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

   [McKusick]
              McKusick, M., Bostic, K., Karels, M., and J. Quarterman,
              "The Design and Implementation of the 4.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".

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

   [OpenBSD-PF]
              The OpenBSD Packet Filter,
              "http://www.openbsd.org/faq/pf/".

   [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.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, March 2007.

   [RFC4907]  Aboba, B., "Architectural Implications of Link
              Indications", RFC 4907, June 2007.

   [RFC4953]  Touch, J., "Defending TCP Against Spoofing Attacks",
              RFC 4953, July 2007.

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

   [Watson]   Watson, P., "Slipping in message.

   claimedtcpseq
      Variable holding the Window: TCP Reset Attacks",
              2004 CanSecWest Conference , 2004.

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

Appendix A.  An analysis of ICMP hard errors

   This appendix contains an analysis sequence number contained in the payload
      of the ICMP hard errors.

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

      This ICMP error "Packet Too Big" message indicates that has just been received
      or was last recorded.

   current_mtu
      Variable holding the host sending assumed Path-MTU for this connection.

   drop_message()
      Function that performs the necessary actions to drop the ICMP
      error
      message received a being processed.

   initial_mtu
      Variable holding the MTU for new connections, as explained in
      [RFC1191] and [RFC1981].

   maxsizeacked
      Variable holding the largest packet meant size (data, plus headers) that
      has so far been acked for a transport protocol it
      does not support.  For connection-oriented protocols such this connection, as TCP,
      one could expect to receive such an error explained in
      Section 7.2.

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

   nsegrto
      Variable holding the result number of a
      connection-establishment attempt.  However, it would be strange to
      get such an error during times this segment has timed out,
      as explained in Section 7.2.

   packet_size
      Variable holding the life size of the IP datagram being sent.

   pending_message
      Variable (flag) that indicates whether there is a connection, as this would
      indicate pending ICMP
      "Packet Too Big" message to be processed.

   save_message()
      Function that support for records the ICMP "Packet Too Big" message that transport protocol has
      just been removed
      from received.

   MINIMUM_MTU
      Constant holding the system sending minimum MTU for the error message during internet protocol in use
      (68 for IPv4, and 1280 for IPv6).

   MAXSEGRTO
      Constant holding the life number of the
      corresponding connection. times a given segment must timeout
      before an ICMP type 3 (Destination Unreachable), code 3 (port unreachable)

      This "Packet Too Big" error message indicates that the system sending the can be honored.

   EVENT: New TCP connection

        current_mtu = initial_mtu;
        maxsizesent = MINIMUM_MTU;
        maxsizeacked = MINIMUM_MTU;
        nsegrto = 0;
        pending_message = 0;

   EVENT: Segment is sent
        if (packet_size > maxsizesent)
             maxsizesent = packet_size;

   EVENT: Segment is received

        if (acked_packet_size > maxsizeacked)
             maxsizeacked = acked_packet_size;

        if (pending_message)
             if (ack > claimedtcpseq){
                  pending_message = 0;
                  nsegrto = 0;
             }

   EVENT: ICMP
      error "Packet Too Big" 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 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 receiving these error messages, as performed using
      sequence number arithmethic.
      The pseudo-code implements the mechanism described in Section 7.2,
      the protocol would signal TCP sequence number checking described in Section 4.1, and the port unreachable condition by means
      of its own messages.  Assuming that once a connection is
      established it is not usual for
      validation check on the transport protocol to change
      (or be reloaded), it should be unusual to get these error
      messages.

   ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed advertised Next-Hop MTU described in
      [RFC1191] and DF bit set) [RFC1981].

8.  Security Considerations

   This document describes the use of ICMP error message indicates that an intermediate node needed messages to
      fragment perform a datagram, but the DF (Don't Fragment) bit in
   number of attacks against the IP
      header was set.  It is considered a soft error when TCP implements
      PMTUD, protocol, and describes a hard error if TCP does not implement PMTUD.  Those
      TCPs number of
   widely-implemented counter-measures that do not implement either eliminate or reduce
   the PMTUD mechanism should not be
      sending impact of these attacks when they are performed by off-path
   attackers.

9.  Acknowledgements

   This document was inspired by Mika Liljeberg, while discussing some
   issues related to [I-D.ietf-tcpm-tcp-soft-errors] by private e-mail.
   The author would like to thank (in alphabetical order): Bora Akyol,
   Mark Allman, Ran Atkinson, James Carlson, Alan Cox, Theo de Raadt,
   Wesley Eddy, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo
   Gont, John Heffner, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk,
   Mika Liljeberg, Matt Mathis, David Miller, Miles Nordin, Eloy Paris,
   Kacheong Poon, Andrew Powell, Pekka Savola, Pyda Srisuresh, Fred
   Templin, and Joe Touch for contributing many valuable comments.

   Juan Fraschini and the author of this document implemented freely-
   available audit tools to help vendors audit their IP packets with systems by
   reproducing the DF bit set, attacks discussed in this document.  This tools are
   available at http://www.gont.com.ar/tools/index.html .

   Markus Friedl, Chad Loder, and thus should not
      be receiving these ICMP error messages.

   ICMPv6 type 1 (Destination Unreachable), code 1 (communication with
   destination administratively prohibited) the author of this document, produced
   and tested in OpenBSD [OpenBSD] the first implementation of the
   counter-measure described in Section 7.2.  This error message indicates that first implementation
   helped to test the destination is unreachable
      because effectiveness of an administrative policy.  For connection-oriented
      protocols such the ideas introduced in this
   document, and has served as TCP, one could expect a reference implementation for other
   operating systems.

   The author would like to receive such an error
      as thank the result UK's Centre for the Protection of
   National Infrastructure (CPNI) -- formerly National Infrastructure
   Security Co-ordination Centre (NISCC) -- for coordinating the
   disclosure of these issues with a connection-establishment attempt.  Receiving
      such an error 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 a connection 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 any of the synchronized states
      would mean that RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the administrative policy changed during
              Internet Protocol", RFC 4301, December 2005.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the life Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

10.2.  Informative References

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

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

   [I-D.ietf-tcpm-tcp-auth-opt]
              Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", draft-ietf-tcpm-tcp-auth-opt-05
              (work in the same way this error condition
      (which was not present when the conenction was established)
      appeared, it could get solved solved progress), July 2009.

   [I-D.ietf-tcpm-tcp-soft-errors]
              Gont, F., "TCP's Reaction to Soft Errors",
              draft-ietf-tcpm-tcp-soft-errors-09 (work in the near term.

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

      This error message is analogous progress),
              November 2008.

   [I-D.ietf-tcpm-tcpsecure]
              Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
              Robustness to the Blind In-Window Attacks",
              draft-ietf-tcpm-tcpsecure-11 (work in progress),
              November 2008.

   [I-D.ietf-tsvwg-port-randomization]
              Larsen, M. and F. Gont, "Port Randomization",
              draft-ietf-tsvwg-port-randomization-04 (work in progress),
              July 2009.

   [ICMP-Filtering]
              Gont, F., "Filtering of ICMP type 3 (Destination
      Unreachable), code 3 (Port unreachable) error message discussed
      above.  Therefore, the same considerations apply. messages",  http://
              www.gont.com.ar/papers/
              filtering-of-icmp-error-messages.pdf.

   [IP-filtering]
              NISCC, "NISCC Technical Note 01/2006: Egress and Ingress
              Filtering",  http://www.niscc.gov.uk/niscc/docs/
              re-20060420-00294.pdf?lang=en, 2006.

   [Linux]    The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that
   TCP SHOULD abort Linux Project, "http://www.kernel.org".

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

   [NISCC]    NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP:
              Vulnerability Issues in response to ICMP
   messages of type 3, codes 2 (protocol unreachable), 3 (port
   unreachable), 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".

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

   [OpenBSD-PF]
              The OpenBSD Packet Filter,
              "http://www.openbsd.org/faq/pf/".

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

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

   [RFC1323]  Jacobson, V., Braden, B., and DF bit set).  However,
   Section 3.2.2.1 states that TCP MUST accept an ICMP port unreachable
   (type 3, code 3) for the same purpose as an RST.  Therefore, D. Borman, "TCP Extensions
              for ICMP
   messages High Performance", RFC 1323, May 1992.

   [RFC2385]  Heffernan, A., "Protection of type 3 codes 2 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 4 there is room to go against the
   advice provided in the existing specifications, while in the case of
   ICMP messages D. Black, "The Addition
              of type 3 code 3 there is ambiguity in the
   specifications that may or may not provide some room to go against
   that advice.

Appendix B.  Advice and guidance to vendors

   Vendors are urged to contact CPNI (vulteam@cpni.gsi.gov.uk) if they
   think they may be affected by the issues described in this document.
   As the lead coordination center for these issues, CPNI is well placed Explicit Congestion Notification (ECN) to give advice IP",
              RFC 3168, September 2001.

   [RFC3390]  Allman, M., Floyd, S., and guidance as required.

   CPNI works extensively with government departments C. Partridge, "Increasing TCP's
              Initial Window", RFC 3390, October 2002.

   [RFC4271]  Rekhter, Y., Li, T., and agencies,
   commercial organizations S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, March 2007.

   [RFC4907]  Aboba, B., "Architectural Implications of Link
              Indications", RFC 4907, June 2007.

   [RFC4953]  Touch, J., "Defending TCP Against Spoofing Attacks",
              RFC 4953, July 2007.

   [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 academic community to research
   vulnerabilities Window: TCP Reset Attacks",
              2004 CanSecWest Conference , 2004.

   [Wright]   Wright, G. and potential threats to IT systems especially where
   they may have an impact on Critical National Infrastructure's (CNI).

   Other ways to contact CPNI, plus CPNI's PGP public key, are available
   at http://www.cpni.gov.uk . W. Stevens, "TCP/IP Illustrated, Volume 2:
              The Implementation", Addison-Wesley , 1994.

Appendix C. A.  Changes from previous versions of the draft (to be removed
             by the RFC Editor before publishing this document as an
             RFC)

C.1.

A.1.  Changes from draft-ietf-tcpm-icmp-attacks-05

   o  Addresses feedback submitted by Wes Eddy
      (http://www.ietf.org/mail-archive/web/tcpm/current/msg04573.html
      and
      http://www.ietf.org/mail-archive/web/tcpm/current/msg04574.html)
      and Joe Touch (on June 8th... couldn't find online ref, sorry) on
      the TCPM WG mailing-list.

A.2.  Changes from draft-ietf-tcpm-icmp-attacks-04

   o  The draft had expired and thus is resubmitted with no further
      changes.  Currently working on a rev of the document (Please send
      feedback!).

C.2.

A.3.  Changes from draft-ietf-tcpm-icmp-attacks-03

   o  The draft had expired and thus is resubmitted with no further
      changes.

C.3.

A.4.  Changes from draft-ietf-tcpm-icmp-attacks-02

   o  Added a disclaimer to indicate that this document does not update
      the current specifications.

   o  Addresses feedback sent off-list by Alfred Hoenes.

   o  The text (particulary that which describes the counter-measures)
      was reworded to document what current implementations are doing,
      rather than "proposing" the implementation of the counter-
      measures.

   o  Some text has been removed: we're just documenting the problem,
      and what existing implementations have done.

   o  Miscelaneous editorial changes.

C.4.

A.5.  Changes from draft-ietf-tcpm-icmp-attacks-01

   o  Fixed references to the antispoof documents (were hardcoded and
      missing in the References Section).

   o  The draft had expired and thus is resubmitted with only a minor
      editorial change.

C.5.

A.6.  Changes from draft-ietf-tcpm-icmp-attacks-00

   o  Added references to the specific sections of each of the
      referenced specifications

   o  Corrected the threat analysys

   o  Added clarification about whether the counter-measures violate the
      current specifications or not.

   o  Changed text so that the document fits better in the Informational
      path

   o  Added a specific section on IPsec (Section 2.3)

   o  Added clarification and references on the use of ICMP filtering
      based on the ICMP payload

   o  Updated references to obsoleted RFCs

   o  Added a discussion of multipath scenarios, and possible lose in
      responsiveness resulting from the reaction to hard errors as soft
      errors

   o  Miscellaneous editorial changes

C.6.

A.7.  Changes from draft-gont-tcpm-icmp-attacks-05

   o  Removed RFC 2119 wording to make the draft suitable for
      publication as an Informational RFC.

   o  Added additional checks that should be performed on ICMP error
      messages (checksum of the IP header in the ICMP payload, and
      others).

   o  Added clarification of the rationale behind each the TCP SEQ check

   o  Miscellaneous editorial changes

C.7.

A.8.  Changes from draft-gont-tcpm-icmp-attacks-04

   o  Added section on additional considerations for validating ICMP
      error messages

   o  Added reference to (draft) [RFC4907]

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

   o  Miscellaneous editorial changes

C.8.

A.9.  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 of the blind connection-reset vulnerability was
      expanded and improved

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

   o  Section 7.4 was added

   o  Miscellaneous editorial changes

C.9.

A.10.  Changes from draft-gont-tcpm-icmp-attacks-02

   o  Fixed errors in in the discussion of the blind connection-reset
      attack

   o  The proposed counter-measure for the attack against the PMTUD
      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
      counter-measure for the attack against the PMTUD mechanism

   o  Added Appendix B CPNI contact information.

   o  Miscellaneous editorial changes

C.10.

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

   o  Fixed typo in the ICMP types, in several places

   o  Fixed typo in the TCP sequence number check formula

   o  Miscellaneous editorial changes

C.11.

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

Author's Address

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

   Phone: +54 11 4650 8472
   Email: fernando@gont.com.ar
   URI:   http://www.gont.com.ar