rfc1337.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          R. Braden
Request for Comments: 1337                                           ISI
                                                                May 1992


                 TIME-WAIT Assassination Hazards in TCP

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This note describes some theoretically-possible failure modes for TCP
   connections and discusses possible remedies.  In particular, one very
   simple fix is identified.

1. INTRODUCTION

   Experiments to validate the recently-proposed TCP extensions [RFC-
   1323] have led to the discovery of a new class of TCP failures, which
   have been dubbed the "TIME-WAIT Assassination hazards".  This note
   describes these hazards, gives examples, and discusses possible
   prevention measures.

   The failures in question all result from old duplicate segments.  In
   brief, the TCP mechanisms to protect against old duplicate segments
   are [RFC-793]:

   (1)  The 3-way handshake rejects old duplicate initial <SYN>
        segments, avoiding the hazard of replaying a connection.

   (2)  Sequence numbers are used to reject old duplicate data and ACK
        segments from the current incarnation of a given connection
        (defined by a particular host and port pair).  Sequence numbers
        are also used to reject old duplicate <SYN,ACK> segments.

        For very high-speed connections, Jacobson's PAWS ("Protect
        Against Wrapped Sequences") mechanism [RFC-1323] effectively
        extends the sequence numbers so wrap-around will not introduce a
        hazard within the same incarnation.

   (3)  There are two mechanisms to avoid hazards due to old duplicate
        segments from an earlier instance of the same connection; see
        the Appendix to [RFC-1185] for details.




Braden                                                          [Page 1]

RFC 1337                 TCP TIME-WAIT Hazards                  May 1992


        For "short and slow" connections [RFC-1185], the clock-driven
        ISN (initial sequence number) selection prevents the overlap of
        the sequence spaces of the old and new incarnations [RFC-793].
        (The algorithm used by Berkeley BSD TCP for stepping ISN
        complicates the analysis slightly but does not change the
        conclusions.)

   (4)  TIME-WAIT state removes the hazard of old duplicates for "fast"
        or "long" connections, in which clock-driven ISN selection is
        unable to prevent overlap of the old and new sequence spaces.
        The TIME-WAIT delay allows all old duplicate segments time
        enough to die in the Internet before the connection is reopened.

   (5)  After a system crash, the Quiet Time at system startup allows
        old duplicates to disappear before any connections are opened.

   Our new observation is that (4) is unreliable: TIME-WAIT state can be
   prematurely terminated ("assassinated") by an old duplicate data or
   ACK segment from the current or an earlier incarnation of the same
   connection.  We refer to this as "TIME-WAIT Assassination" (TWA).

   Figure 1 shows an example of TIME-WAIT assassination.  Segments 1-5
   are copied exactly from Figure 13 of RFC-793, showing a normal close
   handshake.  Packets 5.1, 5.2, and 5.3 are an extension to this
   sequence, illustrating TWA.   Here 5.1 is *any* old segment that is
   unacceptable to TCP A.  It might be unacceptable because of its
   sequence number or because of an old PAWS timestamp.  In either case,
   TCP A sends an ACK segment 5.2 for its current SND.NXT and RCV.NXT.
   Since it has no state for this connection, TCP B reflects this as RST
   segment 5.3, which assassinates the TIME-WAIT state at A!





















Braden                                                          [Page 2]

RFC 1337                 TCP TIME-WAIT Hazards                  May 1992



       TCP A                                                TCP B

   1.  ESTABLISHED                                          ESTABLISHED

       (Close)
   2.  FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  --> CLOSE-WAIT

   3.  FIN-WAIT-2  <-- <SEQ=300><ACK=101><CTL=ACK>      <-- CLOSE-WAIT

                                                            (Close)
   4.  TIME-WAIT   <-- <SEQ=300><ACK=101><CTL=FIN,ACK>  <-- LAST-ACK

   5.  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>      --> CLOSED

  - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   5.1. TIME-WAIT   <--  <SEQ=255><ACK=33> ... old duplicate

   5.2  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>    -->  ????

   5.3  CLOSED      <-- <SEQ=301><CTL=RST>             <--  ????
      (prematurely)

                         Figure 1.  TWA Example


   Note that TWA is not at all an unlikely event if there are any
   duplicate segments that may be delayed in the network.  Furthermore,
   TWA cannot be prevented by PAWS timestamps; the event may happen
   within the same tick of the timestamp clock.  TWA is a consequence of
   TCP's half-open connection discovery mechanism (see pp 33-34 of
   [RFC-793]), which is designed to clean up after a system crash.

2. The TWA Hazards

   2.1 Introduction

      If the connection is immediately reopened after a TWA event, the
      new incarnation will be exposed to old duplicate segments (except
      for the initial <SYN> segment, which is handled by the 3-way
      handshake).  There are three possible hazards that result:

      H1.  Old duplicate data may be accepted erroneously.

      H2.  The new connection may be de-synchronized, with the two ends
           in permanent disagreement on the state.  Following the spec
           of RFC-793, this desynchronization results in an infinite ACK



Braden                                                          [Page 3]

RFC 1337                 TCP TIME-WAIT Hazards                  May 1992


           loop.  (It might be reasonable to change this aspect of RFC-
           793 and kill the connection instead.)

           This hazard results from acknowledging something that was not
           sent.  This may result from an old duplicate ACK or as a
           side-effect of hazard H1.

      H3.  The new connection may die.

           A duplicate segment (data or ACK) arriving in SYN-SENT state
           may kill the new connection after it has apparently opened
           successfully.

      Each of these hazards requires that the seqence space of the new
      connection overlap to some extent with the sequence space of the
      previous incarnation.  As noted above, this is only possible for
      "fast" or "long" connections.  Since these hazards all require the
      coincidence of an old duplicate falling into a particular range of
      new sequence numbers, they are much less probable than TWA itself.

      TWA and the three hazards H1, H2, and H3 have been demonstrated on
      a stock Sun OS 4.1.1 TCP running in an simulated environment that
      massively duplicates segments.  This environment is far more
      hazardous than most real TCP's must cope with, and the conditions
      were carefully tuned to create the necessary conditions for the
      failures.  However, these demonstrations are in effect an
      existence proof for the hazards.

      We now present example scenarios for each of these hazards.  Each
      scenario is assumed to follow immediately after a TWA event
      terminated the previous incarnation of the same connection.

   2.2  HAZARD H1: Acceptance of erroneous old duplicate data.

      Without the protection of the TIME-WAIT delay, it is possible for
      erroneous old duplicate data from the earlier incarnation to be
      accepted.  Figure 2 shows precisely how this might happen.














Braden                                                          [Page 4]

RFC 1337                 TCP TIME-WAIT Hazards                  May 1992



           TCP A                                                 TCP B

      1. ESTABL.  --> <SEQ=400><ACK=101><DATA=100><CTL=ACK> --> ESTABL.

      2. ESTABL.  <--     <SEQ=101><ACK=500><CTL=ACK>     <--   ESTABL.

      3.  (old dupl)...<SEQ=560><ACK=101><DATA=80><CTL=ACK> --> ESTABL.

      4. ESTABL.  <--     <SEQ=101><ACK=500><CTL=ACK>     <--   ESTABL.

      5. ESTABL.  --> <SEQ=500><ACK=101><DATA=100><CTL=ACK> --> ESTABL.

      6.             ...  <SEQ=101><ACK=640><CTL=ACK>     <--   ESTABL.

     - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

      7a. ESTABL. --> <SEQ=600><ACK=101><DATA=100><CTL=ACK> --> ESTABL.

      8a. ESTABL.  <--    <SEQ=101><ACK=640><CTL=ACK> ...

      9a. ESTABL. --> <SEQ=700><ACK=101><DATA=100><CTL=ACK> --> ESTABL.

                    Figure 2: Accepting Erroneous Data

      The connection has already been successfully reopened after the
      assumed TWA event.  Segment 1 is a normal data segment and segment
      2 is the corresponding ACK segment.  Old duplicate data segment 3
      from the earlier incarnation happens to fall within the current
      receive window, resulting in a duplicate ACK segment #4.  The
      erroneous data is queued and "lurks" in the TCP reassembly queue
      until data segment 5 overlaps it.  At that point, either 80 or 40
      bytes of erroneous data is delivered to the user B; the choice
      depends upon the particulars of the reassembly algorithm, which
      may accept the first or the last duplicate data.

      As a result, B sends segment 6, an ACK for sequence = 640, which
      is 40 beyond any data sent by A.  Assume for the present that this
      ACK arrives at A *after* A has sent segment 7a, the next full data
      segment.  In that case, the ACK segment 8a acknowledges data that
      has been sent, and the error goes undetected.  Another possible
      continuation after segment 6 leads to hazard H3, shown below.

   2.3  HAZARD H2: De-synchronized Connection

      This hazard may result either as a side effect of H1 or directly
      from an old duplicate ACK that happens to be acceptable but
      acknowledges something that has not been sent.



Braden                                                          [Page 5]

RFC 1337                 TCP TIME-WAIT Hazards                  May 1992


      Referring to Figure 2 above, suppose that the ACK generated by the
      old duplicate data segment arrived before the next data segment
      had been sent.  The result is an infinite ACK loop, as shown by
      the following alternate continuation of Figure 2.

     - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      7b. ESTABL.  <--    <SEQ=101><ACK=640><CTL=ACK>   ...
     (ACK something not yet
      sent => send ACK)

      8b. ESTABL.  -->    <SEQ=600><ACK101><CTL=ACK>       -->   ESTABL.
                                                       (Below window =>
                                                            send ACK)

      9b. ESTABL.  <--    <SEQ=101><ACK=640><CTL=ACK>     <--    ESTABL.

                               (etc.!)

                     Figure 3: Infinite ACK loop


   2.4  HAZARD H3:  Connection Failure

      An old duplicate ACK segment may lead to an apparent refusal of