From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 06:03:28 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 D71F416A4CE for ; Tue, 4 Jan 2005 06:03:28 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5191443D1D for ; Tue, 4 Jan 2005 06:03:28 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j0463Kx4003063; Mon, 3 Jan 2005 22:03:25 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200501040603.j0463Kx4003063@gw.catspoiler.org> Date: Mon, 3 Jan 2005 22:03:20 -0800 (PST) From: Don Lewis To: silby@silby.com In-Reply-To: <20050103230259.G68869@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii 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 06:03:28 -0000 On 3 Jan, Mike Silbersack wrote: > > 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. That's pretty much what previous versions of the draft suggested. The earlier versions made some suggestions about how to deal with the corner case by adjusting the sequence number in ACK, but these schemes added a bunch of complexity and had some fatal flaws. I believe that sending the ACK challenge is the Cisco IPR claim. > Sounds like that's the way to go, with the addition of rate limiting those > ACKs. I'm not sure that it makes sense to rate limit the ACKs in this special case. If an attacker has enough information to trigger an ACK response flood from the hardened stack, he could still produce a flood by turning off the SYN bit. A general way of rate limiting ACKs triggered by the reception of out of window data could be a good idea, but this would have to be done very carefully to avoid breaking the algorithms that look at ACKs to sense network congestion. > 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)); > } I was going to suggest just doing a goto dropafterack; but there's a lot of code in tcp_output() that might unnecessarily perturb things. I think you can get away without creating a template for this. Take a look at the code under the dropwithreset label. I'd put this code down with dropafterack and dropwithreset. There may be other cases where it should be used in place of the dropafterack code.