From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 05:21:58 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62D8616A4CE for ; Tue, 4 Jan 2005 05:21:58 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id CA71F43D46 for ; Tue, 4 Jan 2005 05:21:57 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 16555 invoked from network); 4 Jan 2005 05:21:57 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 4 Jan 2005 05:21:57 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 3 Jan 2005 23:21:55 -0600 (CST) From: Mike Silbersack To: Don Lewis In-Reply-To: <200501031855.j03Itnmh002076@gw.catspoiler.org> Message-ID: <20050103230259.G68869@odysseus.silby.com> References: <200501031855.j03Itnmh002076@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: net@FreeBSD.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 05:21:58 -0000 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