From owner-freebsd-net Sun Mar 23 13:33:23 2003 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 4B32C37B407 for ; Sun, 23 Mar 2003 13:33:21 -0800 (PST) Received: from jfitz.com (adsl-63-194-217-126.dsl.snfc21.pacbell.net [63.194.217.126]) by mx1.FreeBSD.org (Postfix) with SMTP id C43E543F75 for ; Sun, 23 Mar 2003 13:33:19 -0800 (PST) (envelope-from fitz@jfitz.com) Received: (qmail 45409 invoked from network); 23 Mar 2003 21:33:17 -0000 Received: from localhost.jfitz.com (HELO fitzlt.jfitz.com) (127.0.0.1) by localhost.jfitz.com with SMTP; 23 Mar 2003 21:33:16 -0000 Content-Type: text/plain; charset="iso-8859-1" From: John Fitzgibbon To: Giorgos Keramidas Subject: Re: Repeated ACKs - possible DoS? Date: Sun, 23 Mar 2003 13:33:17 -0800 User-Agent: KMail/1.4.3 Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: <200303201408.53238.fitz@jfitz.com> <200303201715.32293.fitz@jfitz.com> <20030321020253.GA3174@gothmog.gr> In-Reply-To: <20030321020253.GA3174@gothmog.gr> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200303231333.17886.fitz@jfitz.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Note to "freebsd-net" readers: I'm cc'ing this email because this seems like a "net" issue - full thread is in freebsd-questions. I've been looking at the code in sys/netinet/tcp_input.c. The behavior seems consistent with inducing tcp_input() to jump to the "dropafterack" label for every incoming ACK. The most promising way to do this seems to be to set the T/TCP options when initializing the connection, then just stop using them on some subsequent ACK, (or give the wrong CC value). The code is around line 1420: /* * T/TCP mechanism * If T/TCP was negotiated and the segment doesn't have CC, * or if its CC is wrong then drop the segment. * RST segments do not have to comply with this. */ if ((tp->t_flags & (TF_REQ_CC|TF_RCVD_CC)) == (TF_REQ_CC|TF_RCVD_CC) && ((to.to_flags & TOF_CC) == 0 || tp->cc_recv != to.to_cc)) goto dropafterack; It may also be possible to cause the jump to "dropafterack" with the timestamp option, (RFC 1323 - the code is just above the previous T/TCP code). This would "jive" with the fact that the client connection seemed to be a Windows 98 machine, (from the Apache logs), and apparently the Windows 98 implementation of RFC 1323 is flawed. However, I'm less sure what kind of invalid options scenario would be required. In any case, I haven't done enough research to be 100% sure that either of these approaches can cause the behavior I observed. All I AM sure of is that I observed the repeated ACK situation, and it was a pretty darn effective DoS. I'm also sure that banging ACKs back and forth at full speed is NOT how TCP/IP is supposed to work. Hopefully this might be enough of a lead to get someone's thought processes going. Fitz. On Thursday 20 March 2003 06:02 pm, Giorgos Keramidas wrote: > On 2003-03-20 17:15, John Fitzgibbon wrote: > >On Thursday 20 March 2003 04:43 pm, Giorgos Keramidas wrote: > >>> X is remote. Y is server, (FreeBSD 4.7-STABLE, built 2003/01/06) > >>> > >>> tcpdump shows 2 remote connections repeatedly sending "ack 1": > >>> > >>> 09:16:10.236812 X.64670 > Y.http: . ack 1 win 32589 > >>> 09:16:10.236879 Y.http > X.64670: . ack 489 win 58400 (DF) > >> > >> Hmmm, is this repeatable? Can you try to grab the output of the > >> following command in a log file while it happens? > >> > >> # tcpdump -n -v -s 128 -XX port 80 > > > > I haven't seen this behavior before, and I don't know how to recreate it > > :( > > Damn :( > > If this is a bug that you've hit upon, please note that command and > run it if it ever happens to appear again. The log file is going to > be large, but I'll help a lot to have it around when trying to find > out what happens. > > - Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message