rfc1337.txt

RFC 的详细文档！

      TCP A's next connection attempt, as illustrated in Figure 4.  Here
      <W=...> indicates the TCP window field SEG.WIND.*

        TCP A                                                     TCP B

    1.  CLOSED                                                   LISTEN

    2.  SYN-SENT    --> <SEQ=100><CTL=SYN>                 --> SYN-RCVD

    3.         ... <SEQ=400><ACK=101><CTL=SYN,ACK><W=800>  <-- SYN-RCVD

    4.  SYN-SENT    <-- <SEQ=300><ACK=123><CTL=ACK> ... (old duplicate)

    5.  SYN-SENT    --> <SEQ=123><CTL=RST>                   --> LISTEN

    6.  ESTABLISHED <-- <SEQ=400><ACK=101><CTL=SYN,ACK><W=900> ...

    7.  ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK>          --> LISTEN

    8.  CLOSED      <--  <SEQ=401><CTL=RST>                  <-- LISTEN


           Figure 4: Connection Failure from Old Duplicate




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


      The key to the failure in Figure 4 is that the RST segment 5 is
      acceptable to TCP B in SYN-RECEIVED state, because the sequence
      space of the earlier connection that produced this old duplicate
      overlaps the new connection space.  Thus, <SEQ=123> in segment #5
      falls within TCP B's receive window [101,900).  In experiments,
      this failure mode was very easy to demonstrate.  (Kurt Matthys has
      pointed out that this scenario is time-dependent:  if TCP A should
      timeout and retransmit the initial SYN after segment 5 arrives and
      before segment 6, then the open will complete successfully.)

3. Fixes for TWA Hazards

   We discuss three possible fixes to TCP to avoid these hazards.

   (F1) Ignore RST segments in TIME-WAIT state.

        If the 2 minute MSL is enforced, this fix avoids all three
        hazards.

        This is the simplest fix.  One could also argue that it is
        formally the correct thing to do; since allowing time for old
        duplicate segments to die is one of TIME-WAIT state's functions,
        the state should not be truncated by a RST segment.

   (F2) Use PAWS to avoid the hazards.

        Suppose that the TCP ignores RST segments in TIME-WAIT state,
        but only long enough to guarantee that the timestamp clocks on
        both ends have ticked.  Then the PAWS mechanism [RFC-1323] will
        prevent old duplicate data segments from interfering with the
        new incarnation, eliminating hazard H1.  For reasons explained
        below, however, it may not eliminate all old duplicate ACK
        segments, so hazards H2 and H3 will still exist.

        In the language of the TCP Extensions RFC [RFC-1323]:

           When processing a RST bit in TIME-WAIT state:

               If (Snd.TS.OK is off) or (Time.in.TW.state() >= W)
                   then enter the CLOSED state, delete the TCB,
                   drop the RST segment, and return.

               else simply drop the RST segment and return.

        Here "Time.in.TW.state()" is a function returning the elapsed
        time since TIME-WAIT state was entered, and W is a constant that
        is at least twice the longest possible period for timestamp
        clocks, i.e., W = 2 secs [RFC-1323].



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


        This assumes that the timestamp clock at each end continues to
        advance at a constant rate whether or not there are any open
        connections.  We do not have to consider what happens across a
        system crash (e.g., the timestamp clock may jump randomly),
        because of the assumed Quiet Time at system startup.

        Once this change is in place, the initial timestamps that occur
        on the SYN and {SYN,ACK} segments reopening the connection will
        be larger than any timestamp on a segment from earlier
        incarnations.  As a result, the PAWS mechanism operating in the
        new connection incarnation will avoid the H1 hazard, ie.
        acceptance of old duplicate data.

        The effectiveness of fix (F2) in preventing acceptance of old
        duplicate data segments, i.e., hazard H1, has been demonstrated
        in the Sun OS TCP mentioned earlier.  Unfortunately, these tests
        revealed a somewhat surprising fact:  old duplicate ACKs from
        the earlier incarnation can still slip past PAWS, so that (F2)
        will not prevent failures H2 or H3.  What happens is that TIME-
        WAIT state effectively regenerates the timestamp of an old
        duplicate ACK.  That is, when an old duplicate arrives in TIME-
        WAIT state, an extended TCP will send out its own ACK with a
        timestamp option containing its CURRENT timestamp clock value.
        If this happens immediately before the TWA mechanism kills
        TIME-WAIT state, the result will be a "new old duplicate"
        segment with a current timestamp that may pass the PAWS test on
        the reopened connection.

        Whether H2 and H3 are critical depends upon how often they
        happen and what assumptions the applications make about TCP
        semantics.  In the case of the H3 hazard, merely trying the open
        again is likely to succeed.  Furthermore, many production TCPs
        have (despite the advice of the researchers who developed TCP)
        incorporated a "keep-alive" mechanism, which may kill
        connections unnecessarily.  The frequency of occurrence of H2
        and H3 may well be much lower than keep-alive failures or
        transient internet routing failures.

   (F3) Use 64-bit Sequence Numbers

        O'Malley and Peterson [RFC-1264] have suggested expansion of the
        TCP sequence space to 64 bits as an alternative to PAWS for
        avoiding the hazard of wrapped sequence numbers within the same
        incarnation.  It is worthwhile to inquire whether 64-bit
        sequence numbers could be used to avoid the TWA hazards as well.

        Using 64 bit sequence numbers would not prevent TWA - the early
        termination of TIME-WAIT state.  However, it appears that a



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


        combination of 64-bit sequence numbers with an appropriate
        modification of the TCP parameters could defeat all of the TWA
        hazards H1, H2, and H3.  The basis for this is explained in an
        appendix to this memo.  In summary, it could be arranged that
        the same sequence space would be reused only after a very long
        period of time, so every connection would be "slow" and "short".

4.  Conclusions

   Of the three fixes described in the previous section, fix (F1),
   ignoring RST segments in TIME-WAIT state, seems like the best short-
   term solution.  It is certainly the simplest.  It would be very
   desirable to do an extended test of this change in a production
   environment, to ensure there is no unexpected bad effect of ignoring
   RSTs in TIME-WAIT state.

   Fix (F2) is more complex and is at best a partial fix.  (F3), using
   64-bit sequence numbers, would be a significant change in the
   protocol, and its implications need to be thoroughly understood.
   (F3) may turn out to be a long-term fix for the hazards discussed in
   this note.

APPENDIX: Using 64-bit Sequence Numbers

   This appendix provides a justification of our statement that 64-bit
   sequence numbers could prevent the TWA hazards.

   The theoretical ISN calculation used by TCP is:

       ISN = (R*T) mod 2**n.

   where T is the real time in seconds (from an arbitrary origin, fixed
   when the system is started), R is a constant, currently 250 KBps, and
   n = 32 is the size of the sequence number field.

   The limitations of current TCP are established by n, R, and the
   maximum segment lifetime MSL = 4 minutes.  The shortest time Twrap to
   wrap the sequence space is:

       Twrap = (2**n)/r

   where r is the maximum transfer rate.  To avoid old duplicate
   segments in the same connection, we require that Twrap > MSL (in
   practice, we need Twrap >> MSL).







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


   The clock-driven ISN numbers wrap in time TwrapISN:

       TwrapISN = (2**n)/R

   For current TCP, TwrapISN = 4.55 hours.

   The cases for old duplicates from previous connections can be divided
   into four regions along two dimensions:

   *    Slow vs. fast connections, corresponding to r < R or r >= R.

   *    Short vs. long connections, corresponding to duration E <
        TwrapISN or E >= TwrapISN.

   On short slow connections, the clock-driven ISN selection rejects old
   duplicates.  For all other cases, the TIME-WAIT delay of 2*MSL is
   required so old duplicates can expire before they infect a new
   incarnation.  This is discussed in detail in the Appendix to [RFC-
   1185].

   With this background, we can consider the effect of increasing n to
   64.  We would like to increase both R and TwrapISN far enough that
   all connections will be short and slow, i.e., so that the clock-
   driven ISN selection will reject all old duplicates.  Put another
   way, we want to every connection to have a unique chunk of the
   seqence space.  For this purpose, we need R larger than the maximum
   foreseeable rate r, and TwrapISN greater than the longest foreseeable
   connection duration E.

   In fact, this appears feasible with n = 64 bits.  Suppose that we use
   R = 2**33 Bps; this is approximately 8 gigabytes per second, a
   reasonable upper limit on throughput of a single TCP connection.
   Then TwrapISN = 68 years, a reasonable upper limit on TCP connection
   duration.  Note that this particular choice of R corresponds to
   incrementing the ISN by 2**32 every 0.5 seconds, as would happen with
   the Berkeley BSD implementation of TCP.  Then the low-order 32 bits
   of a 64-bit ISN would always be exactly zero.

   REFERENCES

      [RFC-793]  Postel, J., "Transmission Control Protocol", RFC-793,
      USC/Information Sciences Institute, September 1981.

      [RFC-1185]  Jacobson, V., Braden, R., and Zhang, L., "TCP
      Extension for High-Speed Paths", RFC-1185, Lawrence Berkeley Labs,
      USC/Information Sciences Institute, and Xerox Palo Alto Research
      Center, October 1990.




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


      [RFC-1263]  O'Malley, S. and L. Peterson, "TCP Extensions
      Considered Harmful", RFC-1263, University of Arizona, October
      1991.

      [RFC-1323]  Jacobson, V., Braden, R. and D. Borman "TCP Extensions
      for High Performance", RFC-1323, Lawrence Berkeley Labs,
      USC/Information Sciences Institute, and Cray Research, May 1992.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address:

   Bob Braden
   University of Southern California
   Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone: [phone]
   EMail: [e-mail]





























Braden                                                         [Page 11]