[dab@BSDI.COM: Re: [e2e] TCP-SYN and delayed TCB allocation]

From: Barney Wolff (barney_at_databus.com)
Date: 05/28/03

  • Next message: Garrett Wollman: "turning off TCP_NOPUSH" 
    Date: Wed, 28 May 2003 11:59:14 -0400
To: freebsd-net@freebsd.org

    I found this message interesting.
    Can someone point me to the rationale for putting all conns through
    the syncache?
    Thanks,
    Barney

    ----- Forwarded message from David Borman <dab@BSDI.COM> -----

    To: end2end-interest@postel.org
    Date: Wed, 28 May 2003 09:46:00 -0500 (CDT)

    > > B) has it been modified that it is now done after the 1st ACK?

    It all depends on what OS you are talking about... FreeBSD makes use
    of the syncaching code that I wrote back in the days of the the original
    SYN flood attacks. They now use it for all their incoming connections,
    so only minimal state is kept for connections in SYN-RCVD state. When
    the ACK is received in response to the SYN,ACK, the full blown TCP is
    created.

    However, since the original syncache code was only used when the normal
    mechanism overflowed, it did not do any SYN,ACK retransmissions for
    connections in the syncache. But since FreeBSD now sends all their
    connections through the SYN cache, they had to add timers so that they
    can do SYN,ACK retransmissions out of the syncache. But that means
    that during a real synflood attack, they are doing more work sending
    out SYN,ACK retransmissions for all those bogus connections. And for
    most connections, you are eventually going to create a full blown
    TCB anyway, so there really isn't any cost savings in defering the
    full TCB creation until transition from SYN-RCVD to ESTABLISHED.
    BSD/OS still uses the standard creation of a full TCB block when
    a SYN is received, and only when that queue overflows do connections
    get created in the syncache, and we don't do SYN,ACK retransmissions
    out of the syncache. So, we can hang valid connections in the syncache
    if our SYN,ACK is received by the other side, but the returning ACK is
    lost. (If our SYN,ACK is lost, the other side will retransmit the
    SYN, causing us to generate another SYN,ACK). But when you are under
    attack, I figure its better to be able to maintain connectivity for
    the majority of the valid connections, rather than buckle over and
    die.

    > > if not, any reason why not B? we would so the same if we had a
    > > "NAT/Firewall" with delayed binding etc
    >
    > If B), where do you put the data that could have been sent in the SYN?
    > I'm not sure you can ACK the SYN without ACKing the data therein (though
    > you don't deliver it until receiving the ACK and transitioning to
    > ESTABLISHED)...

    As long as you don't ACK the data, you don't need to save it. Throw
    away the data and just ACK the SYN. The other side will have retained
    a copy of the data, and will have to retransmit it. Slow, but it will
    work.
                            -David Borman

    ----- End forwarded message ----- 

    -- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.
_______________________________________________
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: Garrett Wollman: "turning off TCP_NOPUSH"