home *** CD-ROM | disk | FTP | other *** search
/ Internet Access: To the Information Highway / InternetAccessToTheInformationHighway1994.disc1of1.iso / internet / rfc4 / rfc1337.txt < prev    next >
Text File  |  1994-06-03  |  23KB  |  619 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          R. Braden
  8. Request for Comments: 1337                                           ISI
  9.                                                                 May 1992
  10.  
  11.  
  12.                  TIME-WAIT Assassination Hazards in TCP
  13.  
  14. Status of This Memo
  15.  
  16.    This memo provides information for the Internet community.  It does
  17.    not specify an Internet standard.  Distribution of this memo is
  18.    unlimited.
  19.  
  20. Abstract
  21.  
  22.    This note describes some theoretically-possible failure modes for TCP
  23.    connections and discusses possible remedies.  In particular, one very
  24.    simple fix is identified.
  25.  
  26. 1. INTRODUCTION
  27.  
  28.    Experiments to validate the recently-proposed TCP extensions [RFC-
  29.    1323] have led to the discovery of a new class of TCP failures, which
  30.    have been dubbed the "TIME-WAIT Assassination hazards".  This note
  31.    describes these hazards, gives examples, and discusses possible
  32.    prevention measures.
  33.  
  34.    The failures in question all result from old duplicate segments.  In
  35.    brief, the TCP mechanisms to protect against old duplicate segments
  36.    are [RFC-793]:
  37.  
  38.    (1)  The 3-way handshake rejects old duplicate initial <SYN>
  39.         segments, avoiding the hazard of replaying a connection.
  40.  
  41.    (2)  Sequence numbers are used to reject old duplicate data and ACK
  42.         segments from the current incarnation of a given connection
  43.         (defined by a particular host and port pair).  Sequence numbers
  44.         are also used to reject old duplicate <SYN,ACK> segments.
  45.  
  46.         For very high-speed connections, Jacobson's PAWS ("Protect
  47.         Against Wrapped Sequences") mechanism [RFC-1323] effectively
  48.         extends the sequence numbers so wrap-around will not introduce a
  49.         hazard within the same incarnation.
  50.  
  51.    (3)  There are two mechanisms to avoid hazards due to old duplicate
  52.         segments from an earlier instance of the same connection; see
  53.         the Appendix to [RFC-1185] for details.
  54.  
  55.  
  56.  
  57.  
  58. Braden                                                          [Page 1]
  59.  
  60. RFC 1337                 TCP TIME-WAIT Hazards                  May 1992
  61.  
  62.  
  63.         For "short and slow" connections [RFC-1185], the clock-driven
  64.         ISN (initial sequence number) selection prevents the overlap of
  65.         the sequence spaces of the old and new incarnations [RFC-793].
  66.         (The algorithm used by Berkeley BSD TCP for stepping ISN
  67.         complicates the analysis slightly but does not change the
  68.         conclusions.)
  69.  
  70.    (4)  TIME-WAIT state removes the hazard of old duplicates for "fast"
  71.         or "long" connections, in which clock-driven ISN selection is
  72.         unable to prevent overlap of the old and new sequence spaces.
  73.         The TIME-WAIT delay allows all old duplicate segments time
  74.         enough to die in the Internet before the connection is reopened.
  75.  
  76.    (5)  After a system crash, the Quiet Time at system startup allows
  77.         old duplicates to disappear before any connections are opened.
  78.  
  79.    Our new observation is that (4) is unreliable: TIME-WAIT state can be
  80.    prematurely terminated ("assassinated") by an old duplicate data or
  81.    ACK segment from the current or an earlier incarnation of the same
  82.    connection.  We refer to this as "TIME-WAIT Assassination" (TWA).
  83.  
  84.    Figure 1 shows an example of TIME-WAIT assassination.  Segments 1-5
  85.    are copied exactly from Figure 13 of RFC-793, showing a normal close
  86.    handshake.  Packets 5.1, 5.2, and 5.3 are an extension to this
  87.    sequence, illustrating TWA.   Here 5.1 is *any* old segment that is
  88.    unacceptable to TCP A.  It might be unacceptable because of its
  89.    sequence number or because of an old PAWS timestamp.  In either case,
  90.    TCP A sends an ACK segment 5.2 for its current SND.NXT and RCV.NXT.
  91.    Since it has no state for this connection, TCP B reflects this as RST
  92.    segment 5.3, which assassinates the TIME-WAIT state at A!
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Braden                                                          [Page 2]
  115.  
  116. RFC 1337                 TCP TIME-WAIT Hazards                  May 1992
  117.  
  118.  
  119.  
  120.        TCP A                                                TCP B
  121.  
  122.    1.  ESTABLISHED                                          ESTABLISHED
  123.  
  124.        (Close)
  125.    2.  FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  --> CLOSE-WAIT
  126.  
  127.    3.  FIN-WAIT-2  <-- <SEQ=300><ACK=101><CTL=ACK>      <-- CLOSE-WAIT
  128.  
  129.                                                             (Close)
  130.    4.  TIME-WAIT   <-- <SEQ=300><ACK=101><CTL=FIN,ACK>  <-- LAST-ACK
  131.  
  132.    5.  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>      --> CLOSED
  133.  
  134.   - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  135.  
  136.    5.1. TIME-WAIT   <--  <SEQ=255><ACK=33> ... old duplicate
  137.  
  138.    5.2  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>    -->  ????
  139.  
  140.    5.3  CLOSED      <-- <SEQ=301><CTL=RST>             <--  ????
  141.       (prematurely)
  142.  
  143.                          Figure 1.  TWA Example
  144.  
  145.  
  146.    Note that TWA is not at all an unlikely event if there are any
  147.    duplicate segments that may be delayed in the network.  Furthermore,
  148.    TWA cannot be prevented by PAWS timestamps; the event may happen
  149.    within the same tick of the timestamp clock.  TWA is a consequence of
  150.    TCP's half-open connection discovery mechanism (see pp 33-34 of
  151.    [RFC-793]), which is designed to clean up after a system crash.
  152.  
  153. 2. The TWA Hazards
  154.  
  155.    2.1 Introduction
  156.  
  157.       If the connection is immediately reopened after a TWA event, the
  158.       new incarnation will be exposed to old duplicate segments (except
  159.       for the initial <SYN> segment, which is handled by the 3-way
  160.       handshake).  There are three possible hazards that result:
  161.  
  162.       H1.  Old duplicate data may be accepted erroneously.
  163.  
  164.       H2.  The new connection may be de-synchronized, with the two ends
  165.            in permanent disagreement on the state.  Following the spec
  166.            of RFC-793, this desynchronization results in an infinite ACK
  167.  
  168.  
  169.  
  170. Braden                                                          [Page 3]
  171.  
  172. RFC 1337                 TCP TIME-WAIT Hazards                  May 1992
  173.  
  174.  
  175.            loop.  (It might be reasonable to change this aspect of RFC-
  176.            793 and kill the connection instead.)
  177.  
  178.            This hazard results from acknowledging something that was not
  179.            sent.  This may result from an old duplicate ACK or as a
  180.            side-effect of hazard H1.
  181.  
  182.       H3.  The new connection may die.
  183.  
  184.            A duplicate segment (data or ACK) arriving in SYN-SENT state
  185.            may kill the new connection after it has apparently opened
  186.            successfully.
  187.  
  188.       Each of these hazards requires that the seqence space of the new
  189.       connection overlap to some extent with the sequence space of the
  190.       previous incarnation.  As noted above, this is only possible for
  191.       "fast" or "long" connections.  Since these hazards all require the
  192.       coincidence of an old duplicate falling into a particular range of
  193.       new sequence numbers, they are much less probable than TWA itself.
  194.  
  195.       TWA and the three hazards H1, H2, and H3 have been demonstrated on
  196.       a stock Sun OS 4.1.1 TCP running in an simulated environment that
  197.       massively duplicates segments.  This environment is far more
  198.       hazardous than most real TCP's must cope with, and the conditions
  199.       were carefully tuned to create the necessary conditions for the
  200.       failures.  However, these demonstrations are in effect an
  201.       existence proof for the hazards.
  202.  
  203.       We now present example scenarios for each of these hazards.  Each
  204.       scenario is assumed to follow immediately after a TWA event
  205.       terminated the previous incarnation of the same connection.
  206.  
  207.    2.2  HAZARD H1: Acceptance of erroneous old duplicate data.
  208.  
  209.       Without the protection of the TIME-WAIT delay, it is possible for
  210.       erroneous old duplicate data from the earlier incarnation to be
  211.       accepted.  Figure 2 shows precisely how this might happen.
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Braden                                                          [Page 4]
  227.  
  228. RFC 1337                 TCP TIME-WAIT Hazards                  May 1992
  229.  
  230.  
  231.  
  232.            TCP A                                                 TCP B
  233.  
  234.       1. ESTABL.  --> <SEQ=400><ACK=101><DATA=100><CTL=ACK> --> ESTABL.
  235.  
  236.       2. ESTABL.  <--     <SEQ=101><ACK=500><CTL=ACK>     <--   ESTABL.
  237.  
  238.       3.  (old dupl)...<SEQ=560><ACK=101><DATA=80><CTL=ACK> --> ESTABL.
  239.  
  240.       4. ESTABL.  <--     <SEQ=101><ACK=500><CTL=ACK>     <--   ESTABL.
  241.  
  242.       5. ESTABL.  --> <SEQ=500><ACK=101><DATA=100><CTL=ACK> --> ESTABL.
  243.  
  244.       6.             ...  <SEQ=101><ACK=640><CTL=ACK>     <--   ESTABL.
  245.  
  246.      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  247.  
  248.       7a. ESTABL. --> <SEQ=600><ACK=101><DATA=100><CTL=ACK> --> ESTABL.
  249.  
  250.       8a. ESTABL.  <--    <SEQ=101><ACK=640><CTL=ACK> ...
  251.  
  252.       9a. ESTABL. --> <SEQ=700><ACK=101><DATA=100><CTL=ACK> --> ESTABL.
  253.  
  254.                     Figure 2: Accepting Erroneous Data
  255.  
  256.       The connection has already been successfully reopened after the
  257.       assumed TWA event.  Segment 1 is a normal data segment and segment
  258.       2 is the corresponding ACK segment.  Old duplicate data segment 3
  259.       from the earlier incarnation happens to fall within the current
  260.       receive window, resulting in a duplicate ACK segment #4.  The
  261.       erroneous data is queued and "lurks" in the TCP reassembly queue
  262.       until data segment 5 overlaps it.  At that point, either 80 or 40
  263.       bytes of erroneous data is delivered to the user B; the choice
  264.       depends upon the particulars of the reassembly algorithm, which
  265.       may accept the first or the last duplicate data.
  266.  
  267.       As a result, B sends segment 6, an ACK for sequence = 640, which
  268.       is 40 beyond any data sent by A.  Assume for the present that this
  269.       ACK arrives at A *after* A has sent segment 7a, the next full data
  270.       segment.  In that case, the ACK segment 8a acknowledges data that
  271.       has been sent, and the error goes undetected.  Another possible
  272.       continuation after segment 6 leads to hazard H3, shown below.
  273.  
  274.    2.3  HAZARD H2: De-synchronized Connection
  275.  
  276.       This hazard may result either as a side effect of H1 or directly
  277.       from an old duplicate ACK that happens to be acceptable but
  278.       acknowledges something that has not been sent.
  279.  
  280.  
  281.  
  282. Braden                                                          [Page 5]
  283.  
  284. RFC 1337                 TCP TIME-WAIT Hazards                  May 1992
  285.  
  286.  
  287.       Referring to Figure 2 above, suppose that the ACK generated by the
  288.       old duplicate data segment arrived before the next data segment
  289.       had been sent.  The result is an infinite ACK loop, as shown by
  290.       the following alternate continuation of Figure 2.
  291.  
  292.      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  293.       7b. ESTABL.  <--    <SEQ=101><ACK=640><CTL=ACK>   ...
  294.      (ACK something not yet
  295.       sent => send ACK)
  296.  
  297.       8b. ESTABL.  -->    <SEQ=600><ACK101><CTL=ACK>       -->   ESTABL.
  298.                                                        (Below window =>
  299.                                                             send ACK)
  300.  
  301.       9b. ESTABL.  <--    <SEQ=101><ACK=640><CTL=ACK>     <--    ESTABL.
  302.  
  303.                                (etc.!)
  304.  
  305.                      Figure 3: Infinite ACK loop
  306.  
  307.  
  308.    2.4  HAZARD H3:  Connection Failure
  309.  
  310.       An old duplicate ACK segment may lead to an apparent refusal of
  311.       TCP A's next connection attempt, as illustrated in Figure 4.  Here
  312.       <W=...> indicates the TCP window field SEG.WIND.*
  313.  
  314.         TCP A                                                     TCP B
  315.  
  316.     1.  CLOSED                                                   LISTEN
  317.  
  318.     2.  SYN-SENT    --> <SEQ=100><CTL=SYN>                 --> SYN-RCVD
  319.  
  320.     3.         ... <SEQ=400><ACK=101><CTL=SYN,ACK><W=800>  <-- SYN-RCVD
  321.  
  322.     4.  SYN-SENT    <-- <SEQ=300><ACK=123><CTL=ACK> ... (old duplicate)
  323.  
  324.     5.  SYN-SENT    --> <SEQ=123><CTL=RST>                   --> LISTEN
  325.  
  326.     6.  ESTABLISHED <-- <SEQ=400><ACK=101><CTL=SYN,ACK><W=900> ...
  327.  
  328.     7.  ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK>          --> LISTEN
  329.  
  330.     8.  CLOSED      <--  <SEQ=401><CTL=RST>                  <-- LISTEN
  331.  
  332.  
  333.            Figure 4: Connection Failure from Old Duplicate
  334.  
  335.  
  336.  
  337.  
  338. Braden                                                          [Page 6]
  339.  
  340. RFC 1337                 TCP TIME-WAIT Hazards                  May 1992
  341.  
  342.  
  343.       The key to the failure in Figure 4 is that the RST segment 5 is
  344.       acceptable to TCP B in SYN-RECEIVED state, because the sequence
  345.       space of the earlier connection that produced this old duplicate
  346.       overlaps the new connection space.  Thus, <SEQ=123> in segment #5
  347.       falls within TCP B's receive window [101,900).  In experiments,
  348.       this failure mode was very easy to demonstrate.  (Kurt Matthys has
  349.       pointed out that this scenario is time-dependent:  if TCP A should
  350.       timeout and retransmit the initial SYN after segment 5 arrives and
  351.       before segment 6, then the open will complete successfully.)
  352.  
  353. 3. Fixes for TWA Hazards
  354.  
  355.    We discuss three possible fixes to TCP to avoid these hazards.
  356.  
  357.    (F1) Ignore RST segments in TIME-WAIT state.
  358.  
  359.         If the 2 minute MSL is enforced, this fix avoids all three
  360.         hazards.
  361.  
  362.         This is the simplest fix.  One could also argue that it is
  363.         formally the correct thing to do; since allowing time for old
  364.         duplicate segments to die is one of TIME-WAIT state's functions,
  365.         the state should not be truncated by a RST segment.
  366.  
  367.    (F2) Use PAWS to avoid the hazards.
  368.  
  369.         Suppose that the TCP ignores RST segments in TIME-WAIT state,
  370.         but only long enough to guarantee that the timestamp clocks on
  371.         both ends have ticked.  Then the PAWS mechanism [RFC-1323] will
  372.         prevent old duplicate data segments from interfering with the
  373.         new incarnation, eliminating hazard H1.  For reasons explained
  374.         below, however, it may not eliminate all old duplicate ACK
  375.         segments, so hazards H2 and H3 will still exist.
  376.  
  377.         In the language of the TCP Extensions RFC [RFC-1323]:
  378.  
  379.            When processing a RST bit in TIME-WAIT state:
  380.  
  381.                If (Snd.TS.OK is off) or (Time.in.TW.state() >= W)
  382.                    then enter the CLOSED state, delete the TCB,
  383.                    drop the RST segment, and return.
  384.  
  385.                else simply drop the RST segment and return.
  386.  
  387.         Here "Time.in.TW.state()" is a function returning the elapsed
  388.         time since TIME-WAIT state was entered, and W is a constant that
  389.         is at least twice the longest possible period for timestamp
  390.         clocks, i.e., W = 2 secs [RFC-1323].
  391.  
  392.  
  393.  
  394. Braden                                                          [Page 7]
  395.  
  396. RFC 1337                 TCP TIME-WAIT Hazards                  May 1992
  397.  
  398.  
  399.         This assumes that the timestamp clock at each end continues to
  400.         advance at a constant rate whether or not there are any open
  401.         connections.  We do not have to consider what happens across a
  402.         system crash (e.g., the timestamp clock may jump randomly),
  403.         because of the assumed Quiet Time at system startup.
  404.  
  405.         Once this change is in place, the initial timestamps that occur
  406.         on the SYN and {SYN,ACK} segments reopening the connection will
  407.         be larger than any timestamp on a segment from earlier
  408.         incarnations.  As a result, the PAWS mechanism operating in the
  409.         new connection incarnation will avoid the H1 hazard, ie.
  410.         acceptance of old duplicate data.
  411.  
  412.         The effectiveness of fix (F2) in preventing acceptance of old
  413.         duplicate data segments, i.e., hazard H1, has been demonstrated
  414.         in the Sun OS TCP mentioned earlier.  Unfortunately, these tests
  415.         revealed a somewhat surprising fact:  old duplicate ACKs from
  416.         the earlier incarnation can still slip past PAWS, so that (F2)
  417.         will not prevent failures H2 or H3.  What happens is that TIME-
  418.         WAIT state effectively regenerates the timestamp of an old
  419.         duplicate ACK.  That is, when an old duplicate arrives in TIME-
  420.         WAIT state, an extended TCP will send out its own ACK with a
  421.         timestamp option containing its CURRENT timestamp clock value.
  422.         If this happens immediately before the TWA mechanism kills
  423.         TIME-WAIT state, the result will be a "new old duplicate"
  424.         segment with a current timestamp that may pass the PAWS test on
  425.         the reopened connection.
  426.  
  427.         Whether H2 and H3 are critical depends upon how often they
  428.         happen and what assumptions the applications make about TCP
  429.         semantics.  In the case of the H3 hazard, merely trying the open
  430.         again is likely to succeed.  Furthermore, many production TCPs
  431.         have (despite the advice of the researchers who developed TCP)
  432.         incorporated a "keep-alive" mechanism, which may kill
  433.         connections unnecessarily.  The frequency of occurrence of H2
  434.         and H3 may well be much lower than keep-alive failures or
  435.         transient internet routing failures.
  436.  
  437.    (F3) Use 64-bit Sequence Numbers
  438.  
  439.         O'Malley and Peterson [RFC-1264] have suggested expansion of the
  440.         TCP sequence space to 64 bits as an alternative to PAWS for
  441.         avoiding the hazard of wrapped sequence numbers within the same
  442.         incarnation.  It is worthwhile to inquire whether 64-bit
  443.         sequence numbers could be used to avoid the TWA hazards as well.
  444.  
  445.         Using 64 bit sequence numbers would not prevent TWA - the early
  446.         termination of TIME-WAIT state.  However, it appears that a
  447.  
  448.  
  449.  
  450. Braden                                                          [Page 8]
  451.  
  452. RFC 1337                 TCP TIME-WAIT Hazards                  May 1992
  453.  
  454.  
  455.         combination of 64-bit sequence numbers with an appropriate
  456.         modification of the TCP parameters could defeat all of the TWA
  457.         hazards H1, H2, and H3.  The basis for this is explained in an
  458.         appendix to this memo.  In summary, it could be arranged that
  459.         the same sequence space would be reused only after a very long
  460.         period of time, so every connection would be "slow" and "short".
  461.  
  462. 4.  Conclusions
  463.  
  464.    Of the three fixes described in the previous section, fix (F1),
  465.    ignoring RST segments in TIME-WAIT state, seems like the best short-
  466.    term solution.  It is certainly the simplest.  It would be very
  467.    desirable to do an extended test of this change in a production
  468.    environment, to ensure there is no unexpected bad effect of ignoring
  469.    RSTs in TIME-WAIT state.
  470.  
  471.    Fix (F2) is more complex and is at best a partial fix.  (F3), using
  472.    64-bit sequence numbers, would be a significant change in the
  473.    protocol, and its implications need to be thoroughly understood.
  474.    (F3) may turn out to be a long-term fix for the hazards discussed in
  475.    this note.
  476.  
  477. APPENDIX: Using 64-bit Sequence Numbers
  478.  
  479.    This appendix provides a justification of our statement that 64-bit
  480.    sequence numbers could prevent the TWA hazards.
  481.  
  482.    The theoretical ISN calculation used by TCP is:
  483.  
  484.        ISN = (R*T) mod 2**n.
  485.  
  486.    where T is the real time in seconds (from an arbitrary origin, fixed
  487.    when the system is started), R is a constant, currently 250 KBps, and
  488.    n = 32 is the size of the sequence number field.
  489.  
  490.    The limitations of current TCP are established by n, R, and the
  491.    maximum segment lifetime MSL = 4 minutes.  The shortest time Twrap to
  492.    wrap the sequence space is:
  493.  
  494.        Twrap = (2**n)/r
  495.  
  496.    where r is the maximum transfer rate.  To avoid old duplicate
  497.    segments in the same connection, we require that Twrap > MSL (in
  498.    practice, we need Twrap >> MSL).
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Braden                                                          [Page 9]
  507.  
  508. RFC 1337                 TCP TIME-WAIT Hazards                  May 1992
  509.  
  510.  
  511.    The clock-driven ISN numbers wrap in time TwrapISN:
  512.  
  513.        TwrapISN = (2**n)/R
  514.  
  515.    For current TCP, TwrapISN = 4.55 hours.
  516.  
  517.    The cases for old duplicates from previous connections can be divided
  518.    into four regions along two dimensions:
  519.  
  520.    *    Slow vs. fast connections, corresponding to r < R or r >= R.
  521.  
  522.    *    Short vs. long connections, corresponding to duration E <
  523.         TwrapISN or E >= TwrapISN.
  524.  
  525.    On short slow connections, the clock-driven ISN selection rejects old
  526.    duplicates.  For all other cases, the TIME-WAIT delay of 2*MSL is
  527.    required so old duplicates can expire before they infect a new
  528.    incarnation.  This is discussed in detail in the Appendix to [RFC-
  529.    1185].
  530.  
  531.    With this background, we can consider the effect of increasing n to
  532.    64.  We would like to increase both R and TwrapISN far enough that
  533.    all connections will be short and slow, i.e., so that the clock-
  534.    driven ISN selection will reject all old duplicates.  Put another
  535.    way, we want to every connection to have a unique chunk of the
  536.    seqence space.  For this purpose, we need R larger than the maximum
  537.    foreseeable rate r, and TwrapISN greater than the longest foreseeable
  538.    connection duration E.
  539.  
  540.    In fact, this appears feasible with n = 64 bits.  Suppose that we use
  541.    R = 2**33 Bps; this is approximately 8 gigabytes per second, a
  542.    reasonable upper limit on throughput of a single TCP connection.
  543.    Then TwrapISN = 68 years, a reasonable upper limit on TCP connection
  544.    duration.  Note that this particular choice of R corresponds to
  545.    incrementing the ISN by 2**32 every 0.5 seconds, as would happen with
  546.    the Berkeley BSD implementation of TCP.  Then the low-order 32 bits
  547.    of a 64-bit ISN would always be exactly zero.
  548.  
  549.    REFERENCES
  550.  
  551.       [RFC-793]  Postel, J., "Transmission Control Protocol", RFC-793,
  552.       USC/Information Sciences Institute, September 1981.
  553.  
  554.       [RFC-1185]  Jacobson, V., Braden, R., and Zhang, L., "TCP
  555.       Extension for High-Speed Paths", RFC-1185, Lawrence Berkeley Labs,
  556.       USC/Information Sciences Institute, and Xerox Palo Alto Research
  557.       Center, October 1990.
  558.  
  559.  
  560.  
  561.  
  562. Braden                                                         [Page 10]
  563.  
  564. RFC 1337                 TCP TIME-WAIT Hazards                  May 1992
  565.  
  566.  
  567.       [RFC-1263]  O'Malley, S. and L. Peterson, "TCP Extensions
  568.       Considered Harmful", RFC-1263, University of Arizona, October
  569.       1991.
  570.  
  571.       [RFC-1323]  Jacobson, V., Braden, R. and D. Borman "TCP Extensions
  572.       for High Performance", RFC-1323, Lawrence Berkeley Labs,
  573.       USC/Information Sciences Institute, and Cray Research, May 1992.
  574.  
  575. Security Considerations
  576.  
  577.    Security issues are not discussed in this memo.
  578.  
  579. Author's Address:
  580.  
  581.    Bob Braden
  582.    University of Southern California
  583.    Information Sciences Institute
  584.    4676 Admiralty Way
  585.    Marina del Rey, CA 90292
  586.  
  587.    Phone: (213) 822-1511
  588.    EMail: Braden@ISI.EDU
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Braden                                                         [Page 11]
  619.