Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd)

From: Darren Reed (avalon_at_caligula.anu.edu.au)
Date: 04/22/04

  • Next message: Mike Silbersack: "Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd)" 
    To: silby@silby.com (Mike Silbersack)
Date: Thu, 22 Apr 2004 18:29:51 +1000 (Australia/ACT)

    In some mail from Mike Silbersack, sie said:
    > On Thu, 22 Apr 2004, Darren Reed wrote:
    > > > 1. RSTs exactly at last_ack_sent (always accepted)
    > >
    > > To pursue this thought further, if a FIN has been sent or received
    > > (connection has migrated from ESTABLISHED to CLOSE_WAIT or something
    > > else) then receiving an RST at this point should be much less of a
    > > problem, yes ?
    > >
    > > The only drawback is I've seen sessions where there's a last ditch
    > > attempt to get data through even though a FIN has been received.
    > >
    > > Darren
    >
    > Are you suggesting that we use the strict check during the ESTABLISHED
    > phase, and the window-wide check during all other phases?

    Possibly :)

    I don't think it is important for session setup, but at the end of a
    session, you generally want it to disappear from your connection table
    sooner rather than later, right ?

    Furthermore, you're more likely to get a RST after a FIN has been
    sent, by either party, if you send another ACK because the other
    guy has decided to remove the socket already. Does this make
    sense ?

    Although this makes me wonder, what's the implication here for FIN
    packets - is there none ? The draft refers to SYNs (which do get
    special treatment) and RSTs (just more violent FIN packets.)

    If someone injects a FIN packet the way they would have done a RST,
    what are the implications ?
    Does a packet storm ensue ?
    Does the FIN get ignored ?
    Do FIN packets also need to be challenge-responsed now ?

    Darren
    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"

  • Next message: Mike Silbersack: "Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd)"

    Relevant Pages

    • Re: SSL/TCP Connection termination results in RST
      ... What I saw was that the side sending the FIN ... The OS then cleans up the socket structures. ... When the OS gets a packet for that connection it no longer has any place to ... that it is done sending data and then loop receiving data until it gets an ...
      (comp.dcom.sys.cisco)
    • Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd)
      ... The only report of this that I saw was from jayanth. ... Judging by ... if a FIN has been sent or received ... else) then receiving an RST at this point should be much less of a ...
      (FreeBSD-Security)
    • Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd)
      ... > (connection has migrated from ESTABLISHED to CLOSE_WAIT or something ... > else) then receiving an RST at this point should be much less of a ... > attempt to get data through even though a FIN has been received. ... Mike "Silby" Silbersack ...
      (FreeBSD-Security)
    • Re: How can I detect a carriage return using java.net
      ... At the 'C' level a reador recvor recvmsgwill return 0 meaning EOF on receiving a FIN, and -1 with an errno of ECONNRESET on receiving an RST. ...
      (comp.lang.java.programmer)
    • Re: TCP socket close problem
      ... So, indeed, the packets with the FIN and RST (and also, a preceeding ... ACK) are dropped by tcp_input. ... Since the server has not acked the FIN packet, ...
      (comp.unix.bsd.freebsd.misc)