Re: Fixing "Slipping in the window" before 4.11-release

From: Mark Allman (mallman_at_icir.org)
Date: 01/05/05

  • Next message: Olivier Nicole: "Packet drop in bridging" 
    To: Mike Silbersack <silby@silby.com>, net@freebsd.org
Date: Wed, 05 Jan 2005 10:13:52 -0500

    Folks-

    > > The SYN side of the equation, however, is a bit more tricky. The
    > > proposed RFC recommends ACKing SYN packets in the window, just like
    > > we do to SYN packets to the left of the window right now.
    > >
    > > For the life of me, I can't figure out why SYN packets (other than
    > > delayed retransmissions of the original SYN) would ever show up once
    > > a connection is in the ESTABLISHED state. So, I'm proposing the
    > > attached patch, which simply ignores any packet with the SYN flag on
    > > it while a connection is in the ESTABLISHED state. This means that
    > > SYN packets left of the window will no longer receive an ACK, and
    > > SYN packets in the window will no longer reset the connection. In
    > > all states other than ESTABLISHED, SYN packets are handled as they
    > > were before, in case there's some edge case where that could happen.
    >
    > This sounds OK to me. FWIW.

    I ran this idea by Randall Stewart who has done a bunch of thinking on
    this topic (and, helped produce one of the current internet-drafts on
    the topic). He swayed me that my initial hit (above) might not be quite
    right. Below is Randall's response to my forward of Mike's note
    (forwarded with permission). This is a case that had not occurred to me
    and leaves me thinking maybe ignoring SYNs is not quite the right
    approach. However, I think there could be times when ignoring SYNs
    might be fine. E.g., if the connection is moving right along and there
    are other packets being transmitted and ACKed and we see a SYN that it
    should be ignored.

    FWIW.

    allman

    --- Begin Randall's note ---

    Anyway.. we discussed this very option in GORY detail last year about
    this time.. and we discarded the idea for a number of important
    reasons..

    a) It is NOT uncommon for a machine to be rebooted (there are a
        lot of windoz boxes out there.. not everyone uses FreeBSD)

    b) When a machine reboots that was a client, it is likely to pick
        the same starting port... so say if not many connections have been
        made.. I make some connection out of my windoz box to my
        favorite server "telnet my.favorite.server" .. and start working..
        Of course my windoz box crashes.. chances are that if I do
        the same telnet again.. I get the same starting port (if port
        randomization is not in place.. which most O/S's dont' do). Guess
        what happens to my SYN ->>... dumpper. Now this means I must
        depend on the TCP endpoint that still has the hanging TCB to
        cleanup before I can connect on that port set.

    c) This is a nasty inconvience for a lot of apps.. for our internal
        ones that use the same ports often on each side.. (don't ask why
        since i don't understand all the reasoning.. but its the way
        it is) and guess what I get things that can't connect since all
        my SYN's upon reboot are ignored (not that a router ever crashes :-D)

    So... this is when we came up with the SYN idea... yes its possible you
    would never notice the SYN being dropped.. but, there will be SOME
    apps that do.. especially the more long term things such as
    banking ... routing... ip telephoney... etc. It might work
    ok most of the time.. but when it does not work and a crash as
    occured it will fail at the MOST miserable time.

    It would be far better to send back the ACK .. thus cleaning up
    the TCB and then allowing the connection to progress... at least
    IMO...

  • Next message: Olivier Nicole: "Packet drop in bridging"

    Relevant Pages

    • Re: repeated SYN packets to port 80
      ... >>eye to be simple SYN packets. ... why attack my piddly server? ... describing this sort of behavior in my reading on NIMDA nor Code Red. ... of the machines which are sending the SYN packets. ...
      (comp.security.unix)
    • Re: shooting up a FreeBSD Server
      ... FreeBSD has methods to reduce the inpact of Syn flooding. ... > more TCP port open is to send a bunch of SYN packets. ... > a new TCP connection, and your computer must keep the information ... you can't accept legitimate TCP connections. ...
      (comp.unix.bsd.freebsd.misc)
    • Re: Fixing "Slipping in the window" before 4.11-release
      ... > For the life of me, I can't figure out why SYN packets (other than delayed ... > retransmissions of the original SYN) would ever show up once a connection ... > they respond to unexpected SYN packets? ...
      (freebsd-net)
    • Re: Kernel code of reseting/ignoring tcp SYN packets
      ... > I was looking around for the files of Kernel code where SYN messages are sent, ... > so we can simply inject some code to send back a reset messages or ignore the SYN requests. ... > I am having a bit of trouble in finding out the way of injecting code in the kernel to deal with SYN packets. ...
      (freebsd-hackers)
    • Re: Fixing "Slipping in the window" before 4.11-release
      ... I'm going to commit FreeBSD's fix for the RST part ... > of the slipping in the window attack to 4.11 in the next few days. ... > SYN packets to the left of the window right now. ... It can happen if one side of the connection crashes and tries to ...
      (freebsd-net)