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

From: Mike Silbersack (silby_at_silby.com)
Date: 01/04/05

  • Next message: Don Lewis: "Re: Fixing "Slipping in the window" before 4.11-release" 
    Date: Mon, 3 Jan 2005 23:21:55 -0600 (CST)
To: Don Lewis <truckman@FreeBSD.org>

    On Mon, 3 Jan 2005, Don Lewis wrote:

    >> 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.
    >
    > It can happen if one side of the connection crashes and tries to
    > reconnect using the same source port. The BGP case, which is the case
    > where attacks are of most concern, likes to connect from port 179 to
    > port 179.

    Argh. I was assuming that the client would be using ephemeral ports, and
    therefore pick a different one after the crashed. Apps like BGP throw a
    wrench into this, I guess. :)

    I just went and took a look at the REVISED version of the draft for this
    issue:

    http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-02.txt

    And it turns out that I should have looked at it earlier; this version
    actually provides useful advice on the SYN case. Specifically, it
    suggests that in response to all SYNs, an ACK for the left edge of the
    window be sent; no SYNs are allowed to reset the connection.

    Sounds like that's the way to go, with the addition of rate limiting those
    ACKs.

    The TCP state machine is pretty complex, so it seems like we'd better
    use something which does not alter the state in any way to send out the
    ACKs here. Does this look like it'd do the trick? (Stolen from the
    keepalive code):

                     t_template = tcpip_maketemplate(inp);
                     if (t_template) {
                             tcp_respond(tp, t_template->tt_ipgen,
                                         &t_template->tt_t, (struct mbuf *)NULL,
                                         tp->rcv_nxt, tp->snd_una - 1, 0);
                             (void) m_free(dtom(t_template));
                     }

    Mike "Silby" Silbersack
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: Don Lewis: "Re: Fixing "Slipping in the window" before 4.11-release"

    Relevant Pages

    • Re: [fw-wiz] Post connection SYN
      ... drop the connection request treating it as Post Connection SYN attack. ...
      (Firewall-Wizards)
    • [NEWS] Hardware Defenses against SYN Flooding
      ... Hardware Defenses against SYN Flooding ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... Establishing a TCP connection requires the exchange of three packets: ... return from the Web server, and finally ACK back from ...
      (Securiteam)
    • RE: managing a SYN flood
      ... the server sees that, it responds with a packet with SYN and ACK set. ... Connection tables are often of fixed size. ...
      (Security-Basics)
    • RE: managing a SYN flood
      ... the server sees that, it responds with a packet with SYN and ACK set. ... Connection tables are often of fixed size. ...
      (Security-Basics)
    • Bad winsock behavior with SynAttackProtect and listen backlog exceeded
      ... "The listen function is typically used by servers that can have more than one connection ... RESET back from the server immediately after the 3-way handshake (SYN, SYN-ACK, ACK). ... documentation. ...
      (microsoft.public.win32.programmer.networks)