Loading ...
Sorry, an error occurred while loading the content.

Re: RSTs and Half Duplex Close bug

Expand Messages
  • Ian Heavens
    ... Sorry about the delay in replying. I meant delivered to the peer TCP . I agree that delivery to an application is unlikely. I was making the point that
    Message 1 of 10 , Dec 1, 1997
    • 0 Attachment
      Vern Paxson wrote:
      >
      > > The client was offering a window of 8760, so it's possible that all
      > > the subsequent segments were in transit when the RST was transmitted.
      > >
      > > By the way, this is what makes the lack of TIME-WAIT after RST more
      > > dangerous : it is very likely that up to an entire window of data
      > > will be delivered after the connection has closed down, whereas
      > > after a FIN exchange data is unlikely to be delivered.
      >
      > I'm confused by this comment. If by delivered you mean to the application,
      > then this seems unlikely - it requires that a new connection is very quickly
      > established with the same ephemeral port and insufficient ISN advance.
      > I guess the combination of a proxy that reuses ephemeral ports plus bad luck
      > with randomized ISN generation could do this; I wouldn't consider that
      > "very likely", though.
      >
      > If by delivered you mean transmitted over the network, then since it's
      > already in flight, a FIN exchange wouldn't prevent that, right?
      >


      Sorry about the delay in replying. I meant "delivered to the peer TCP".
      I agree that delivery to an application is unlikely. I was making the
      point that after a RST, one is much more likely to get data than after
      a FIN exchange. So RSTs are more dangerous than reducing the MSL after
      FIN exchange; if you worry about the latter, you might might to want
      to worry about RSTS, unless RST use is very unlikely.

      The current mechanisms rely on no data arriving after the connection
      closes...even if it does, the ISN and port sequence numbers provide
      further protection. So the dangers are relatively low. I guess the
      issue is whether they are less than the probability of data corruption
      which does not modify the checksum.

      ian



      --
      Ian Heavens, Spider Software Ltd., http://www.spider.com/
      8 John's Place, Leith, Edinburgh EH6 7EL.
      Tel +44 131 475 7015 fax. +44 131 475 7001 ian@...
    • Vern Paxson
      ... I still don t see why this is. It takes half an RTT (roughly) for either the RST or the first FIN to travel to the other peer. At that point, in either
      Message 2 of 10 , Dec 1, 1997
      • 0 Attachment
        > ... I meant "delivered to the peer TCP".
        > I agree that delivery to an application is unlikely. I was making the
        > point that after a RST, one is much more likely to get data than after
        > a FIN exchange.

        I still don't see why this is. It takes half an RTT (roughly) for either
        the RST or the first FIN to travel to the other peer. At that point, in
        either case the peer should stop sending new data. So I don't see why one
        is much more likely to get data with a RST.

        Vern
      • Ian Heavens
        ... It s only a problem if data arrives in CLOSED state. For the RST case, while the RST is in transit, up to a window of data may arrive in CLOSED state,
        Message 3 of 10 , Dec 2, 1997
        • 0 Attachment
          Vern Paxson wrote:
          >
          > > ... I meant "delivered to the peer TCP".
          > > I agree that delivery to an application is unlikely. I was making the
          > > point that after a RST, one is much more likely to get data than after
          > > a FIN exchange.
          >
          > I still don't see why this is. It takes half an RTT (roughly) for either
          > the RST or the first FIN to travel to the other peer. At that point, in
          > either case the peer should stop sending new data. So I don't see why one
          > is much more likely to get data with a RST.

          It's only a problem if data arrives in CLOSED state.

          For the RST case, while the RST is in transit, up to a window of
          data may arrive in CLOSED state, since it may have already left
          the peer before the RST arrives.

          For the FIN case, a window of data may be in transit - but it will
          arrive in FIN_WAIT_1. The other end can continue transmitting until
          it sends a FIN (this data will arrive in FIN_WAIT_2). To arrive in
          TIME-WAIT, the data has to be reordered with the second FIN, or
          duplicated in the network, or have been lost and retransmitted.
          (if the peer sends a FIN before it receives our FIN, the data arrives in
          CLOSING or LAST-ACK state at one or both peers). So even if TIME-WAIT
          state is omitted, the chance of data arriving in CLOSED state at one
          end or the other is small - roughly the probability of a segment being
          reordered, lost or duplicated.

          I might have got the above analysis not quite right, but I think
          that's roughly how it works. After a RST, you often get a lot of
          segments in CLOSED state (e.g. the correct implementation of half
          duplex close in the Known Bugs I-D). After a FIN, a single segment
          is unlikely to arrive in TIME-WAIT (or CLOSED state if TIME-WAIT is
          omitted).

          Then the chance of actual data corruption is factored by the chance
          of a new application opening with the port/sequence number space
          overlapping that of one or more of the segments that arrived in
          CLOSED state, which makes it a low probability event for either case.

          Awaiting corrections...

          cheers

          ian


          Ian Heavens, Spider Software Ltd., http://www.spider.com/
          8 John's Place, Leith, Edinburgh EH6 7EL.
          Tel +44 131 475 7015 fax. +44 131 475 7001 ian@...
        Your message has been successfully submitted and would be delivered to recipients shortly.