Network Working Group                                         R. Stewart
Internet-Draft                                                  M. Dalal
Internet-Draft                                                    Editor
Expires: November 19, 2005                                  May 18, 2005 August 17, 2006                                          Editor
                                                       February 13, 2006

         Improving TCP's Robustness to Blind In-Window Attacks
                    draft-ietf-tcpm-tcpsecure-03.txt
                    draft-ietf-tcpm-tcpsecure-04.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with
   section Section 6 of 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 November 19, 2005. August 17, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005). (2006).

Abstract

   A recent study indicates that some types of TCP (RFC793 [1]) connections have an
   increased vulnerability to spoofed packet injection attacks than
   previously believed [SITW].  TCP has historically been considered
   protected against spoofed packet injection attacks by relying on the
   fact that it is widely deployed difficult to guess the 4-tuple (the source and one
   destination IP addresses and the source and destination ports) in
   combination with the 32 bit sequence number(s).  A combination of
   increasing window sizes and applications using a longer term
   connections (e.g.  H-323 or Border Gateway Protocol [RFC1771]) have
   left modern TCP implementation more vulnerable to these types of
   spoofed packet injection attacks.

   Note: Both [SITW] and [DTASA] provide charts which can give the most often used
   reliable end
   reader an idea as to end protocols for data communication.  Yet when the time it
   was defined over 20 years ago takes to penetrate an unprotected
   system.

   Many of these long term TCP applications tend to have predictable IP
   addresses and ports which makes it far easier for the internet, as we know it, was 4-tuple to be
   guessed.  Having guessed the 4-tuple correctly, an attacker can
   inject a
   different place lacking many RST, SYN or DATA segment into a TCP connection by carefly
   crafting the sequence number of the threats that are now common.
   Recently several rather serious threats have been detailed that spoofed segment to be in the
   current receive window.  This can
   pose new methods for both denial of service and cause the connection to either
   abort or possibly cause data
   injection by blind attackers. corruption.  This document details those threats
   and also proposes some
   small changes modifications to the way TCP handles inbound segments that either eliminate can
   reduce the threats or at least minimize them
   to a more acceptable level. probability of such an attack.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Blind reset  4
     1.1.  The RESET attack using the RST bit . . . . . . . . . . . . .  5
     2.1   Description of the attack . . . . . . . .  4
     1.2.  Attack probabilities . . . . . . . . . . . . . . . . . . .  5
     2.2   Solution
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5  8
   3.  Blind reset attack using the SYN RST bit . . . . . . . . . . . . .  7
     3.1  9
     3.1.  Description of the attack  . . . . . . . . . . . . . . . .  7
     3.2   Solution .  9
     3.2.  Mitigation . . . . . . . . . . . . . . . . . . . . . . . .  7  9
   4.  Blind data injection reset attack using the SYN bit . . . . . . . . . . . . . 11
     4.1.  Description of the attack  . . . .  9
     4.1 . . . . . . . . . . . . . 11
     4.2.  Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Blind data injection attack  . . . . . . . . . . . . . . . . . 13
     5.1.  Description of the attack  . . . . . . . . . . . . . . . .  9
     4.2   Solution 13
     5.2.  Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  ACK throttling . . .  9
   5. . . . . . . . . . . . . . . . . . . . . . 15
   7.  Backward Compatibility and Other considerations  . . . . . . . 11
   6. 16
   8.  Middlebox considerations . . . . . . . . . . . . . . . . . . . 13
     6.1 17
     8.1.  Middlebox that cache resend RST's  . . . . . . . . . . . . . . . . 13
     6.2 17
     8.2.  Middleboxes that advance sequence numbers  . . . . . . . . 13
   7. 17
   9.  Interoperability Testing . . . . . . . . . . . . . . . . . . . 19
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
   8. 23
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   9. 24
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1 25
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2 25
     14.2. Informative References . . . . . . . . . . . . . . . . . . 17
       Author's Address 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 . 26
   Intellectual Property and Copyright Statements . . . . . . . . 18 . . 27

1.  Introduction

   TCP (RFC793 [1]) [RFC0793] is widely deployed and one of the most often used common reliable end to
   end protocols transport protocol used for data communication. communication in todays
   Internet.  Yet when it was defined over 20 years ago the internet, Internet, as
   we know it, was a different place lacking many of the threats that
   are now common.
   Recently several rather serious threats have been detailed  TCP spoofing attacks are one such attack that can
   pose new methods for both denial of service and possibly data
   injection are
   seen on the Internet today.

   In a TCP spoofing attack, an off-path attacker crafts TCP packets by blind attackers.  This document details those threats
   forging the IP source and also proposes some small changes to destination addresses as well as the way TCP handles inbound
   segments source
   and destination ports (commonly referred to as a 4-tuple value) so
   that either eliminate the threats or at least minimize them
   to a more acceptable level.

   Most of these proposals modify handling procedures for DATA, RST and
   SYN's as defined target TCP endpoint can associate such a packet with an
   existing TCP connection.  Note that in RFC793 [1] but do and of itself guessing this
   4-tuple value is not cause interoperability
   issues.  The authors feel always easy for an attacker.  But there are some
   applications (e.g.  BGP [RFC1771]) that many may have a tendency to use
   the same set(s) of ports on either endpoint making the odds of
   guessing correctly the changes proposed 4-tuple value much easier.  When an attacker
   is successful in this
   document would, if TCP were being standardized today, guessing the 4-tuple value, one of three types of
   injection attacks may be required waged against a long-lived connection.

   RST - Where an attacker injects a reset segment hoping to cause the
      connection to be in torn down.

   SYN - Where an attacker injects a 'SYN' hoping to cause the base TCP document receiver
      to believe the peer has restarted and so tear down the lack of these procedures is more connection
      state.

   DATA - Where an  artifact of attacker tries to inject a "DATA" segment to corrupt
      the time when TCP was developed than any strict
   requirement contents of the protocol.

   For some uses of TCP, an alternative protection against transmission.

1.1.  The RESET attack

   Focusing upon the threats
   that these changes address has already been implemented and deployed RESET attack, let's examine this attack in more
   detail to get an overview as to how it works and how this document
   proposes addressing the TCP MD5 Signature Option (RFC2385 [2]).  Because issue.  For this option
   is not negotiated  and attack the goal is implemented with a manually established
   shared key or password, it has been used for protecting uses to cause
   one of TCP
   in which the two endpoints are managed, such as for BGP peers.  RFC3562
   [3] provides importance guidance for users of RFC2385 [2] for
   decreasing their vulnerability to key-guessing.

   Yet another commonly known mitigation technique is cryptography,
   especially IPSec.  For IPSec to work, both ends of the connection
   need to agree on the properties to use for incorrectly tear down
   the connection and also
   agree upon a pre-shared key.  In state, effectively closing the absence of PKI infrastructure, connection.  To do this may be inconvenient.  IPSec with manual keys can be used to
   avoid using ISAKMP.  However, this adds considerable burden on
   the
   administration of such solution.  If ISAKMP were attacker needs to be used, this
   would typically require all firewalls in the path between have or guess several pieces of information
   (namely):

   1) The 4-tuple value containing the two TCP
   endpoints to allow UDP traffic for at least ISAKMP to function.
   Further, IPSec IP address and NAT have long been known to have interoperability
   issues. TCP implementations SHOULD also introduce ephemeral port
   randomization.  By randomizing ephemeral ports number of
      both ends of the connection.  For one side (usually the server)
      guessing the port number is a trivial exercise.  The client side
      may or may not be easy for an attacker would have to guess depending on a less easy time
      number of factors most notably the operating system and
      application involved.

   2) A sequence number that will be used in guessing the four tuples needed RST.  This sequence
      number will be a starting point for a series of guesses to mount attempt
      to present a
   successful attack.  Since ephemeral ports are 16 bit values and RST segment to a connection endpoint that would be
      acceptable to it.  Any random value may be used to guess the
      initial sequence number.

   3) The window size that the two endpoints are using.  This value does
      NOT have to be the exact window size since a
   subset smaller value used in
      lieu of the entire available port numbers, it is correct one will just cause the attacker to generate
      more segments before succeeding in his mischieve.  Most modern
      operating systems have a weaker defense
   than an exact sequence number match as proposed here default window size which usually is a 32-
   bit value and changes dramatically within
      applied to most connections.  Some applications however may change
      the window size to better suit the life needs of the application.  So
      often times the attacker, with a connection.
   Nevertheless, both fair degree of them are complimentary solutions certainty (knowing
      the application that will make
   it difficult is under attack), can come up with a very
      close approximation as to launch attacks discussed below.

   Alternative proposals, including the actual window size in use on the
      connection.

   After assembling the above set of cookies (or, use of information the
   timestamp option as attacker begins
   sending spoofed TCP segments with the RST bit set and a cookie) require guessed TCP
   sequence number.  Each time a new RST segment is sent, the sequence
   number guess is incremented by the window size.  Without mitigation
   [SITW] has shown that such an attack is much easier to accomplish
   then previously assumed.  This is because RFC793 [RFC0793] specifies
   that any RST within the current window is acceptable.

   A slight modification to the TCP state machine can be made which
   makes such an attack much more difficult to accomplish.  If the
   receiver examines the incoming RST segment and validates that the
   sequence number exactly matches the sequence number that is next
   expected, then such an attack becomes much more difficult then
   outlined in [SITW] (i.e. the attacker would have to generate 1/2 the
   entire sequence space, on average).  This document will discuss the
   exact details of what needs to be changed within TCP's state machine
   to mitigate all three types of attacks (RST, SYN and DATA).

1.2.  Attack probabilities

   Every application has control of a number of factors that effect
   drastically the probability of a successful spoofing attack.  These
   factors include such things as:

   Window Size - Normally settable by the application but often times
      defaulting to 32,768 or 65,535 depending upon the operating system
      (Medina05 [Medina05]).

   Server Port number - This value is normally a fixed value so that a
      client will know where to connect to the peer at.  Thus this value
      normally provides no additional protection.

   Client Port number - This value may be a random ephemeral value, if
      so, this makes a spoofing attack more difficult.  There are some
      clients, however, that for whatever reason either pick a fixed
      client port or have a very guessable one (due to the range of
      ephemeral ports available with their operating system or other
      application considerations) for such applications a spoofing
      attack becomes less difficult.

   For the purposes of the rest of this discussion we will assume that
   the attacker knows the 4-tuple values.  This assumption will help us
   focus on the effects of the window size verses the number of TCP
   packets an attacker must generate.  This assumption will rarely be
   true in the real Internet since at least the client port number will
   provide us with some amount of randomness (depending on operating
   system).

   To successfully inject a spoofed packet (RST, SYN or DATA), in the
   past, the entire sequence space (i.e. 2^32) was often considered
   available to make such an attack unlikely.  [SITW] demonstrated that
   this assumption was incorrect and that instead of [1/2 X 2^32]
   packets (assuming a random distribution) [1/2 X (2^32/window)]
   packets is required.

   Placing real numbers on this formula we see that for a window size of
   32,768, an average of 65,536 packets would need to be transmitted in
   order to "spoof" a TCP segment that would be acceptable to a TCP
   receiver.  A window size of 65,535 reduces this even further to
   32,768 packets.  With rises in bandwidth to both peers the home and office,
   it can only be expected that the values for default window sizes will
   continue to implement rise in order to better take advantage of the
   changes before any newly
   available bandwidth.

   As we can see from the above discussion this weakness lowers the bar
   quite considerably for likely attacks.  But there is one additional protection
   dependency which is the duration of the TCP connection.  A TCP
   connection that lasts only a few brief packets, as often is the case
   for web traffic, would not be subject to such an attack since the
   connection may not be established long enough for an attacker to
   generate enough traffic.  However there is a set of applications such
   as BGP [RFC1771] which is judged to be potentially most affected by
   this vulnerability.  BGP relies on a persistent TCP session between
   BGP peers.  Resetting the connection can result in medium term
   unavailability due to the need to rebuild routing tables and route
   flapping see [NISCC] for further details.

   It should be noted that there are existing alternative protection
   against the threats that this document addresses.  For further
   details regarding the attacks and the existing techniques, please
   refer to draft [DTASA]

2.  Terminology

   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 RFC2119 [RFC2119].
   TCP terminology should be realized.

2. interpreted as described in RFC793
   [RFC0793].

3.  Blind reset attack using the RST bit

2.1

3.1.  Description of the attack

   It has been traditionally thought that for a blind attacker to reset
   a TCP connection the attacker would have to guess a single sequence
   number

   As described in the TCP sequence space.  This would in effect require introduction, it is possible for an attacker to
   generate (2^^32) segments in order to reset a connection.
   Recent papers have shown this to not necessarily "RST" segment that would be the case.  An
   attacker need only guess acceptable to a number that lies between the last TCP receiver
   by guessing a "in-window" sequence
   number acknowledged and numbers.  In particulary RFC 793,
   p37, states the last following:

   "In all states except SYN-SENT, all reset (RST) segments are
   validated by checking their SEQ-fields [sequence numbers].  A reset
   is valid if its sequence number acknowledged added
   to is in the receiver window (RCV.WND)[4].  Modern operating systems
   normally default window.  In the RCV.WND to about 32,768 bytes.  This means that
   a blind attacker need only guess 65,535 SYN-SENT
   state (a RST segments (2^^32/RCV.WND) received in order response to reset a connection.  At DSL speeds this means that most
   connections (assuming an initial SYN), the attacker can accurately guess both ports)
   can be reset in under 200 seconds (usually far less).  With RST is
   acceptable if the rise
   of broadband availability and increasing available bandwidth, many
   Operating Systems have raised their default RCV.WND to as much as
   64k, thus making these attacks even easier.

2.2  Solution ACK field acknowledges the SYN."

3.2.  Mitigation

   RFC793 [1] [RFC0793] currently requires handling of a segment with the
   RST bit when in a synchronized state to be processed as follows:

   1) If the RST bit is set and the sequence number is outside the
      expected window,
      current receive window (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+
      RCV.WND) , silently drop the segment.

   2) If the RST bit is set and the sequence number is acceptable i.e.:
      (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND) then reset the connection.

   Instead, this document proposes the following changes should be made
   to provide some protection against such an attack.

   A) If the RST bit is set and the sequence number is outside the
      expected
      current receive window, silently drop the segment.

   B) If the RST bit is set and the sequence number exactly matches the
      next expected sequence number, reset the connection.

   C) number (RCV.NXT), then TCP MUST reset the
      connection.

   C) If the RST bit is set and the sequence number does not exactly
      match the next expected sequence value, yet is within the current
      receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST
      send an acknowledgment (challenge ACK):

      <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

      After sending the challenge ACK, TCP MUST drop the unacceptable
      segment and stop processing the incoming packet further.

      The previous text,quoted from RFC793 pg 37 would thus become:

      In all states except SYN-SENT, all reset (RST) segments are
      validated by checking their SEQ-fields [sequence numbers].  A
      reset is valid if its sequence number exactly matches the next
      expected sequence number.  If the the RST bit is set arrives and the its sequence
      number field does not exactly NOT match the next expected sequence value, yet number but
      is within the
      acceptable window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND) send an
      acknowledgment:

      <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

      After sending the acknowledgment, drop window, then the unacceptable segment
      and return.

      This solution forms a challenge/response with any RST receiver should generate an ACK.
      In all other cases where the
      value SEQ-field does not exactly match the expected value and yet is
      outside the window, the receiver MUST silently discard the
      segment.

      In the SYN-SENT state (a RST received in response to an initial
      SYN), the RST is
      within acceptable if the window. ACK field acknowledges the SYN.
      In all other cases of a legitimate reset without the
      exact sequence number, receiver MUST silently discard the consequences of this new challenge/
      response will be that segment.

      With the peer requires an extra round trip time
      before above slight change to the connection can be reset. TCP state machine, it becomes
      much harder for an attacker to generate an acceptable reset
      segment.

      In order cases where the remote peer did generate a RST but it fails to alleviate multiple RSTs/SYNs from triggering multiple
      meet the above criteria (the RST sequence number was within the
      window but NOT the exact expected sequence number) when the
      challenge ACKs, a ACK throttling mechanism SHOULD be implemented.
   Suggested values are is sent back, it will no longer have the
      transmission control block (TCB) related to this connection and
      hence as per RFC793 [RFC0793], the remote peer will send no more than 10 challenge ACKs in a 5 second window.  These values MUST be tunable to accommodate different
   requirements.  ACK throttling if implemented successfully can lead to
   several advantages.  Besides preventing
      RST back.  The sequence number of the second RST is derived from
      the RST/ACK war outlined in acknowledgment number of the section below, incoming ACK.  This second RST if
      it can also alleviate spurious fast retransmits at reaches the remote end caused by flood of duplicate ACKs and also save
   spurious processing required sender will cause the connection to send be aborted
      since the sequence number would now be an ACK on exact match.

   Note that the victim side.

3. above mitigation may cause a non-amplification ACK
   exchange.  This concern is detailed in

4.  Blind reset attack using the SYN bit

3.1

4.1.  Description of the attack

   Analysis of the reset attack, which uses attack using the RST flag bit, highlights another
   possible avenue for a blind attacker. attacker using a similar set of sequence
   number guessing.  Instead of using the RST bit an attacker can use
   the SYN bit as well with the exact same symantics to tear down a connection.  Using the same guessing technique, repeated SYN's can be
   generated with sequence numbers incrementing by an amount not larger
   than the window size apart and thus eventually cause the connection
   to be terminated.

3.2  Solution

4.2.  Mitigation

   RFC793 [1] [RFC0793] currently requires handling of a segment with the
   SYN bit set in the synchronized state to be as follows:

   1) If the SYN bit is set and the sequence number is outside the
      expected window, send an ACK back to the sender.

   2) If the SYN bit is set and the sequence number is acceptable i.e.:
      (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then send a RST segment to
      the sender.

   Instead, changing the handling of the SYN in the synchronized state
   to the following will
   provide complete protection from mitigate this attack:

   1)

   A) If the SYN bit is set, irrespective of the sequence number, TCP
      MUST send an ACK (also referred to as challenge ACK) to the remote
      peer:

      <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

      After sending the acknowledgment, TCP MUST drop the unacceptable
      segment and return.

      This solution again forms a challenge response with the peer as in
      the previous section. stop processing further.

   By always sending an ACK to ACK, the sender, a challenge/response remote end sender is setup
   with challenged to confirm the peer.
   loss of the previous connection and the request to start a new
   connection.  A legitimate peer, after restart, would not have a TCB
   in the synchronized state.  Thus when the ACK arrives the peer should
   send a RST segment back with the sequence number derived from the ACK
   field that caused the RST.

   Note, there is one corner case for

   This RST will confirm that the remote TCP endpoint has indeed closed
   the previous connection.  Upon receipt of a valid RST, the local TCP
   endpoint MUST terminate its connection.  The local TCP endpoint
   should then rely on SYN attack problem retransmission from the remote end to re-
   establish the connection.

   A spoofed SYN, on the other hand, will then have generated an
   additional ACK which the peer will discarded as a duplicate ACK and
   will not affect the established connection.

   Note that this mitigation does leave one corner case un-handled which
   will prevent the successful reset of the connection.  This a connection when it should be reset (i.e.
   it is a result of non spoofed SYN wherein a peer really did restart).  This
   problem occurs when the RFC793 [1] specification restarting host chooses the exact same IP
   address and is nothing port number that it was using prior to do with its restart.  By
   chance the proposed
   solution.  In this problem, if a restarting restarted host generates a SYN with must also choose an initial sequence number that is
   of exactly equal to RCV.NXT (RCV.NXT - 1 1) of the remote TCP endpoint that is still in
   the established state and if
   the SYN arrives at state.  Such a case would cause the peer that is still holding receiver to
   generate a "challenge" ack as described above.  But since the stale
   connection, an ACK will
   would be generated.  This within the outgoing connections window the inbound ACK will have an ack
   value of RCV.NXT would
   be acceptable, and the sender of the SYN will be acceptable to do nothing with the restarting host which
   response ACK.  This sequence will accept continue as the ACK and do nothing.  The SYN will then be
   retransmitted sender
   continually times out and retransmits the SYN until such time as the behavior will repeat.  This could lead to an
   initialization failure.  Subsequent
   connection attempts will
   hopefully succeed by choosing attempt fails.

   This corner case is a new ISN that result of the RFC793 [RFC0793] specification
   and is not equal to RCV.NXT
   - 1.  A similar problem will be seen should introduced by the SYN contain data.

4. proposed mitigations.

   Note that the above mitigation may cause a non-amplification ACK
   exchange.  This concern is detailed in Section 10

5.  Blind data injection attack

4.1

5.1.  Description of the attack

   A third type of attack is also highlighted by both the RST and SYN
   attacks.  It is quite also possible to inject data into a TCP connection by
   simply guessing the a sequence value that is number within the window. current receive
   window of the victim.  The ACK value of any data segment is
   considered valid as long as it does not acknowledge data ahead of the
   next segment to send.  In other words an ACK value is acceptable if
   it is (SND.UNA-(2^^31-1)) (SND.UNA-(2^31-1)) <= SEG.ACK <= SND.NXT).  This means that an
   attacker simply need has to guess two ACK values with every guessed sequence
   number so that the chances
   of successfully injecting data into a
   connection are 1 in ((2^^32 ((2^32 / RCV.WND) * 2).

   When an attacker successfully injects data into a connection the data
   will sit in the receiver's re-assembly queue until the peer sends
   enough data to bridge the gap between the RCV.NXT value and the
   injected data.  At that point one of two things will occur either:

   a) An ACK packet war will ensue with the receiver indicating that it has
      received data up until RCV.NXT (which includes the attackers data)
      and the sender sending a corrective an ACK with a value an acknowledgment number less
      than
      RCV.NXT (the real sequence number of the last byte sent). RCV.NXT.

   b) The sender will send enough data to the peer which will move
      RCV.NXT even further along past the injected data.

   In either case the injected data will be made readable to

   Depending upon the upper
   layer and TCP implementation in question and the TCP traffic
   characteristics at that time, data corruption may result.  In case <a>
   (a) the connection will eventually be reset by one of the sides. sides
   unless the sender produces more data that will transform the ACK war
   into case (b).  The reset will usually occur via User Time Out (UTO)
   (see section 4.2.3.5 of [RFC1122]).

   Note that the protections illustrated in this section neither cause
   an ACK war nor prevent one from occurring if data is actually
   injected into a connection.  The ACK war is a natural
   consequence of any data injection that is successful.

4.2  Solution a product of the attack
   itself and cannot be prevented (other than by preventing the data
   from being injected).

5.2.  Mitigation

   An additional input check should be added to any incoming segment.
   The ACK value should MUST be acceptable only if it is in the range of
   ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT).  MAX.SND.WND is
   defined as the largest window that the local receiver has ever
   advertised to it's its peer.  This window is the may be a scaled value i.e. the
   value may be larger than 65,535 bytes. bytes (RFC1323 [RFC1323]).  This
   small check will greatly reduce the vulnerability of to an attacker
   guessing a valid sequence number since not only must he/she guess the
   sequence number in window, but must also guess a proper ACK value
   within a scoped range.  This solution mitigation reduces but does not
   eliminate the ability to generate false segments.  It does however
   reduce the probability that invalid data will be injected to a more acceptable level.  For those
   applications injected.

   Note that wish to close this attack completely RFC2385 [2]
   should be deployed between the two endpoints.

5.  Backward Compatibility and Other considerations

   1) The proposed solution above mitigation may cause a non-amplification ACK
   exchange.  This concern is backward compatible as it uses the
      semantics laid down detailed in RFC793 [1] to defend against it's own
      weakness.  Referring

6.  ACK throttling

   In order to the figure below, if we assume that the
      RST (1.c) was in flight when the alleviate multiple RSTs/SYNs from triggering multiple
   challenge ACKs, an ACK (2) left TCP A, TCP B has throttling mechanism SHOULD be implemented.
   Suggested values are to send no
      way of knowing what triggered the ACK.  For all it cares, the ACK
      might have been a result of the data or the RST that it had sent
      earlier.  Hence more than 10 challenge ACKs in either case, TCP B must reply to this ACK with
      an appropriate RST that is a 5
   second window.  These numbers are empirical in keeping with RFC793 [1].

   2) Concerns nature and have been raised that
   obtained from the challenge response RST throttling mechanism
      will lead to implemented in some OS's.
   These value MUST be tunable by a reflector kind of attack.  In this attack, it is
      believed system administrator to accommodate
   different preceived threats.

   An alternative mechanism may also be used that does not involve an attacker with higher bandwidth can potentially
      spoof SYN or RST packets within the window and cause ACK flooding
      to
   additional timer.  In such an implementation a remote peer sender would only send
   X acks between any window advancment.  Note that may have such a lower bandwidth.  These concerns
      are misplaced because it is trivial limitation
   will not require a timer but must be implemented with care to cause avoid a victim
   deadlock in the face of ack loss.

   An implementation SHOULD include a ACK throttling mechanism to generate
      an ACK.  A spoofer can simply send packets with sequence numbers be
   conservative.  Currently there is no known bad behavior that are outside can be
   attributed to the acceptable window lack of the attacker or send an ACK that acknowledges throttling, but as a general principle,
   if ever invoked, something that incorrect is not yet sent.  Further, an
      attacker can also simply generate data packets occuring and such a mechanisn
   will act as a failsafe that fall within protects both the window to cause an sender and the network.

   An administrator who is more concerned about protecting his bandwidth
   and CPU utilization may set smaller ACK to be sent.  RFC793 [1] also mandates
      that thottling values whereas an ACK be sent if the incoming SYN
   administrator who is more interested in faster cleanup of stale
   connections (i.e. concerned about excess TCP state) may decide to set
   a higher value thus allowing more RST's to an established
      connection falls outside the acceptable window.  All these
      scenarios can be used processed in any given
   time period.

   The time limit SHOULD be tunable to launch help timeout brute force attacks
   faster than a flood attack.  However, the potential harm legitimate flood of such attacks are low RSTs.

7.  Backward Compatibility and can be easily detected
      due to the volume Other considerations

   1) All of packets generated.  The latter is a strong
      deterrent to such attacks.

   3) the proposed mitigation techniques in this document are
      totally compatible with existing (RFC793 [RFC0793]) compliant TCP
      implementations as this document introduces no new assumptions or
      conditions.

   2) There is a corner scenario in the above proposed solutions mitigations which
      will require more than one round trip time to successfully abort
      the connection as per the figure below.  This scenario is similar
      to the one in which the original RST was lost in the network.

          TCP A                                                 TCP B
   1.a. ESTABLISHED ESTAB        <-- <SEQ=300><ACK=101><CTL=ACK><DATA> <--  ESTABLISHED  ESTAB
     b. (delayed)    ... <SEQ=400><ACK=101><CTL=ACK><DATA> <--  ESTABLISHED  ESTAB
     c. (in flight)  ... <SEQ=500><ACK=101><CTL=RST>       <--  CLOSED
   2.   ESTABLISHED   ESTAB        --> <SEQ=101><ACK=400><CTL=ACK>       -->  CLOSED
       (ACK for 1.a)
                     ... <SEQ=400><ACK=0><CTL=RST>         <--  CLOSED
   3.   CHALLENGE    --> <SEQ=101><ACK=400><CTL=ACK>       -->  CLOSED
        (for 1.c)
                     ... <SEQ=400><ACK=0><CTL=RST>         <--  RESPONSE
   4.a. ESTABLISHED ESTAB        <-- <SEQ=400><ACK=101><CTL=ACK><DATA> 1.b reaches A
     b. ESTABLISHED ESTAB        --> <SEQ=101><ACK=500><CTL=ACK>
     c. (in flight)  ... <SEQ=500><ACK=0><CTL=RST>         <--  CLOSED
   5.   RESPONSE arrives at A, but is dropped because of being out since its outside of window.
   6.   ESTABLISHED   ESTAB        <-- <SEQ=500><ACK=0><CTL=RST>         4.c reaches A
   7.   CLOSED                                                   CLOSE

   4)                                                   CLOSED

   3) For the solution mitigation to be totally maximally effective against the
      vulnerabilities discussed in this document, both ends of the TCP
      connection need to have the fix.  Although, having it the mitagations
      at one end might prevent that end from being exposed to the
      attack, the connection is still vulnerable at the other end.

6.

8.  Middlebox considerations

   The following scenarios were brought to notice by the tcpm working
   group members as middlebox issues which may cause the proposed
   solution to behave in an unexpected manner.

6.1

8.1.  Middlebox that cache resend RST's

   Consider a middlebox B M-B tracking connection between two TCP endhosts A
   E-A and C. E-C.  If C E-C sends a RST with a sequence number that is
   within the window but not an exact match to reset the connection and if B
   M-B does not have the fix proposed here, it will may clear the connection
   and ask
   A to do forward the same. RST to E-A saving an incorrect sequence number.  If A
   E-A does not have the fix it will clear the connection and everything
   will be fine.  However if A E-A does have the proposed fix above, it
   will send a challenge ACK.  B ACK to E-C.  M-B, being a
   middlebox will middlebox, may
   intercept this ACK and resend the RST cached earlier
   that was responsible for bringing down the connection.  However, on behalf of E-C with the
   RST old
   sequence number.  This RST, will again be again, not acceptable and will may
   trigger a challenge ACK
   again. ACK.

   This will may cause a RST/ACK war to happen.  However, occur.  However we believe that if
   such a case exists in the Internet the middle box design itself is
   flawed.  Consider a similar scenario where the RST from M-B to E-A
   gets lost, E-A will continue to hold the connection and E-A might
   send an ACK an arbitrary time later after the connection state was
   destroyed at M-B.  For this case, M-B will have to cache the RST for
   an arbitrary amount of time till until it is confirmed that the
   connection has been cleared at E-A.  Further, this is not compliant
   to RFC793 which dictates that the sequence number of a RST has to be
   derived from the acknowledgment number of the incoming ACK segment.

8.2.  Middleboxes that advance sequence numbers

   Some middleboxes may compute RST sequence numbers at the higher end
   of the acceptable window.  The scenario is the same as the earlier
   case, but in this case instead of sending the cached RST, the
   middlebox (M-B) sends a RST that computes its sequence number as a
   sum of the ack field in the ACK and the window advertised by the ACK
   that was sent by E-A to challenge the RST as depicted below.  The
   difference in the sequence numbers between step 1 and 2 below is due
   to data lost in the network.

      TCP A                                                   Middlebox

   1. ESTABLISHED  <-- <SEQ=500><ACK=100><CTL=RST>          <--  CLOSED

   2. ESTABLISHED  --> <SEQ=100><ACK=300><WND=500><CTL=ACK> -->  CLOSED

   3. ESTABLISHED  <-- <SEQ=800><ACK=100><CTL=RST>          <--  CLOSED

   4. ESTABLISHED  --> <SEQ=100><ACK=300><WND=500><CTL=ACK> -->  CLOSED
   5. ESTABLISHED  <-- <SEQ=800><ACK=100><CTL=RST>          <--  CLOSED

   Although the authors are not aware of middleboxes an implementation that actually do this and believe does the design
   itself is flawed in that given
   above, it could be mitigated by implementing the scenario that ACK throttling
   mechanism described earlier.

9.  Interoperability Testing

   Interoperability testing was performed among the RST operating systems
   from B to Juniper Networks, WindRiver Systems, QNX Software and Cisco
   Systems.  The following topology was used:

   +---------+           +---------+
   |TCP    A
   got lost on |----+------|Victim B |
   +---------+    |      +---------+
                  |
   +---------+    |
   |Attacker |----+
   +---------+

   In the way, A will continue to hold above topology B is the connection and unit under test.  TCP A
   might send an ACK is a remote
   peer and the attacker workstation is used to generate malicious
   spoofed packets.

   First, an arbitrary time after unmodifed stack had the following tests performed upon it.
   A TCP connection was brought
   down at up between TCP endpoint A and B. In this case, B will have to cache the RST for an
   arbitrary amount The
   4-tuple of time till it's confirmed that the connection has
   been cleared at A.

6.2  Middleboxes that advance sequence numbers

   Some Middleboxes may compute RST sequence numbers at was manually populated in the higher end
   of brute force
   attack script running on the acceptable window. attacker workstation.  The setup is script
   crafted TCP packets by using the same as 4-tuple and by generating sequence
   numbers that incremented from 0 to the earlier case,
   but max permissible sequence
   number (2^32 -1) in this case instead varying increments of sending window size of 8K to 64K
   (the window size agreed by A and B was larger than 8K, but was
   ignored to make the cached RST, test conservative).  The time it took to cause
   the middlebox
   sends connection to reset/corrupt was then recorded.

   The test was repeated by then generating sequence numbers that were
   window (the one agreed between endpoints A and B) size apart.  It was
   observed that increasing the window size caused the connection to be
   reset faster than with a RST smaller window.  Further, it was also
   observed that computes it's the initial sequence number as (ISN) selection also played
   a sum role in how fast a connection was aborted, with ISN selection in
   the lower half of the ack
   field sequence space aborting sooner than an ISN in
   the ACK upper half.  Results were also found to be influenced by any
   active data transfer on the connection.

   Active data transfer sometimes caused the connection to be reset
   faster and some other times to slow the attack.  The window advertised by size
   selection at the ACK that was sent
   by A attacker workstation and how it compares to challenge the RST as depicted below.
   actual window size between A and B was also found to be a factor.
   The difference in tests were repeated with a stack that did have the
   sequence numbers between step 1 fix and 2 below is due as
   expected it became difficult as compared to data lost in the network.

      TCP previous results to
   cause the connection to abort.

   [Editors Note: Add time test data gathered at inter-op here!!]

10.  Security Considerations

   A                                                   Middlebox

   1. ESTABLISHED  <-- <SEQ=500><ACK=100><CTL=RST>          <--  CLOSED

   2. ESTABLISHED  --> <SEQ=100><ACK=300><WND=500><CTL=ACK> -->  CLOSED

   3. ESTABLISHED  <-- <SEQ=800><ACK=100><CTL=RST>          <--  CLOSED

   4. ESTABLISHED  --> <SEQ=100><ACK=300><WND=500><CTL=ACK> -->  CLOSED
   5. ESTABLISHED  <-- <SEQ=800><ACK=100><CTL=RST>          <--  CLOSED

   Although reflector attack is possible with the authors are not aware of proposed RST/SYN mitigation
   techniques.  Here an off-path attacker can cause a working implementation victim to send an
   ACK segment for each spoofed RST/SYN segment that lies within the
   current receive window of the victim.  This, however, does not cause
   any sort of amplification since the above, it could be mitigated by implementing attacker must generate a segment
   for each one that the RST
   throttling mechanism described earlier.

7. victim will generate.

11.  IANA Considerations

   This document contains no IANA considerations.

12.  Contributors

   Mitesh Dalal and Amol Khare of Cisco Systems came up with the
   solution for the RST/SYN attacks.  Anantha Ramaiah and Randall
   Stewart of Cisco Systems discovered the data injection vulnerability
   and together with Patrick Mahan and Peter Lei of Cisco Systems found
   solutions for the same.  Paul Goyette, Mark Baushke, Frank
   Kastenholz, Art Stine and David Wang of Juniper Networks provided the
   insight that apart from RSTs, SYNs could also result in formidable
   attacks.  Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of
   Wind River Systems and Xiaodan Tang of QNX Software along with the
   folks above helped in ratifying and testing the interoperability of
   the suggested solutions.

8.

13.  Acknowledgments

   Special thanks to Sharad Ahlawat, Mark Allman, Ted Faber, Steve Bellovin, Vern
   Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong and
   the tcpm WG members for suggestions and comments.

9.  Some of the text
   in this document has been derived from

14.  References

9.1

14.1.  Normative References

   [1]

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

   [2]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
        Signature Option",

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2385, August 1998.

9.2 2119, March 1997.

14.2.  Informative References

   [3]

   [DTASA]    Touch, J., "Defending TCP Against Spoofing Attacks",
              draft-touch-tcp-antispoof-00 (work in progress),
              July 2004.

   [Medina05]
              Medina, A., Allman, M., and S. Floyd, "Measuring the
              Evolution of Transport Protocols in the Internet. ACM
              Computer Communication Review, 35(2), April 2005.
              http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps
              (figure 6)".

   [NISCC]    NISCC, "NISCC Vulnerability Advisory 236929 -
              Vulnerability Issues in TCP".

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

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

   [RFC1771]  Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
              (BGP-4)", RFC 1771, March 1995.

   [RFC3562]  Leech, M., "Key Management Considerations for the TCP MD5
              Signature Option", RFC 3562, July 2003.

   [4]

   [SITW]     Watson, P., ""Slipping "Slipping in the Window: TCP Reset attacks"".

Author's Address attacks".

Authors' Addresses

   Randall R. Stewart
   Editor
   4875 Forest Drive
   Suite 200
   Columbia, SC  29206
   USA

   Phone:
   Email: rrs@cisco.com

   Mitesh Dalal
   Editor
   170 Tasman Drive
   San Jose, CA  95134
   USA

   Phone: +1-408-853-5257
   Email: mdalal@cisco.com

Intellectual Property Statement

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

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

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

Disclaimer of Validity

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

Copyright Statement

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

Acknowledgment

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