From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 00:01:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50676106567B for ; Mon, 17 Nov 2008 00:01:58 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id CBE808FC19 for ; Mon, 17 Nov 2008 00:01:57 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so282884ugs.39 for ; Sun, 16 Nov 2008 16:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=0MvPiWlGGxA4ubCaD5dr7wZhRJ24IuAJbq8QIqpl6dE=; b=NcPw8MQhoFikJnJkFp7/2IBdY3h6UCLzhXrwabaxBuxvVE8E5d2DyvqP8xih89awDa Xq99jF4J1NPPT76nCJTliElSsT3rxIBD7Behl9D75XX8jcuULzBt7XUPU7kr4PPnH0g7 jRy7rzeAUZT+KkhMA2wcv/TAvG3BxzaO3WZgE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=I0rVF7Crj/nf6UI2sXhxbIYInHu4vEhugzAw1F47xYWAext834F7dDUasiOPbvrZ1K LLeA4VYtB3r1IKDvu2MrR71HZxODRbAgFT5ljRPLPeIlEenO9l8KlkfOIn2vBaP42ahx QA2dECL2oNNQHrf0g0LeZcPSN7f5YOT+c9D7M= Received: by 10.66.252.18 with SMTP id z18mr1024964ugh.30.1226880116483; Sun, 16 Nov 2008 16:01:56 -0800 (PST) Received: from epsilon.lan (bl6-146-52.dsl.telepac.pt [82.155.146.52]) by mx.google.com with ESMTPS id m38sm1788510ugd.51.2008.11.16.16.01.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Nov 2008 16:01:55 -0800 (PST) Message-Id: <27C5037E-25AB-4EA5-B4DA-445A4B4218F1@freebsd.org> From: Rui Paulo To: Hartmut Brandt In-Reply-To: <49201859.2080605@dlr.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 00:01:52 +0000 References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> X-Mailer: Apple Mail (2.929.2) Sender: Rui Paulo Cc: freebsd-net@freebsd.org Subject: Re: TCP and syncache question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 00:01:58 -0000 On 16 Nov 2008, at 12:55, Hartmut Brandt wrote: > Rui Paulo wrote: >> >> On 15 Nov 2008, at 20:08, Hartmut Brandt wrote: >> >>> Hi, >>> >>> in tcp_syncache.c:syncache_expand() there is a test that the >>> acknowledgement number and the sequence number of an incoming ACK >>> segment are in the expected range. If they are not, >>> syncache_expand() returns 0 and tcp_input drops the segment and >>> sets a reset. So far so good. But syncache_expand() also deletes >>> the syncache entry, and so destroys the connection. I cannot see >>> why it does it. It seems to me that such a wrong segment should be >>> interpreted as to be from another connection and as such the >>> segment should be ignored (but a reset sent). When the correct ACK >>> comes, the connection could still be established. As it is now, >>> the establishment of incoming connections can seriously be >>> disturbed by someone sending fake ACK packets. >>> >>> The same test (for the ack number, not for the sequence number) is >>> also further down in tcp_input.c:tcp_do_segment() (just after the >>> header prediction stuff) and here the handling is correct: the >>> goto dropwithreset just sends a reset and drops the segment but >>> leaves the connection in the SYN-RECEIVED state. This test is >>> probably never reached now, because of syncache_expand(), though. >>> >>> Maybe I fail to see something obvious, though... >> >> >> Well, if the RST is sent, why should we keep the syncache entry? > > Because this effectively destroys the connection in SYN-RECEIVED > which is wrong according to RFC793. On page 69 the handling of > incoming segments for connections in SYN-RECEIVED is described: > first you check the sequence number and, if it is wrong, you send an > RST (unless the RST bit is set in the incoming segment), but > otherwise ignore the segment. > > A segment with a bad sequence number in SYN-RECEIVED is either > forged or from an old connection. In both cases you don't want to > destroy the embryonic connection, because the correct ACK from the > correct peer may still arrive. That clarifies your initial email. You're probably right, I'll try to find out when the bug was introduced. Thanks, -- Rui Paulo