From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 19:44:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3B2D16A416 for ; Thu, 14 Dec 2006 19:44:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outJ.internet-mail-service.net (outJ.internet-mail-service.net [216.240.47.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ACE443D95 for ; Thu, 14 Dec 2006 19:41:53 +0000 (GMT) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 14 Dec 2006 11:28:11 -0800 Received: from [10.251.18.229] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBEJhIot089973; Thu, 14 Dec 2006 11:43:19 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <4581A94F.7030301@elischer.org> Date: Thu, 14 Dec 2006 11:43:11 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Andre Oppermann References: <458094E7.1060806@elischer.org> <45812E01.9060200@freebsd.org> In-Reply-To: <45812E01.9060200@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: question for TCP gurus (in ipfw) 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: Thu, 14 Dec 2006 19:44:14 -0000 Andre Oppermann wrote: > Julian Elischer wrote: >> in the ipfw function send_reject6() we go to great length to calculate >> the sequence number to put into the ack field of the reject packet.. >> >> but it's a RESET we are generating.. >> >> do we need to go to all the work of setting the ACK value etc? > > Yes, at least some of it. > >> could we do either of: >> 1/ not set the ACK bit and just not do the extra work. Just send a >> reset? > > Doesn't work. > >> or >> 2/ instead of ACKing all the data in the packet we are resetting, >> how about just ACKing the sequence number it starts with >> and saving ourselves from doing the work of ACKing all the data >> up to the current packet end. (which is the packet we are rejecting >> anyhow) (It takes some calculation to work out the new ack value >> which seems pointless as we are rejecting it..) > > Section 3 of this document describes the situation and requirements > quite accurately: > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-06.txt it sounds to me from this document that the SEQUENCE NUMBER of the RST needs to be the expected value but the calculations seem to be calculating the ACK value.. ie it is taking the sequence number, adding the amount of data to find the new sequence number, and sending that back in the ACK field..This seems un-needed. (?) i.e shouldn't the RST have a sequence number that is the value of the received ACK (minus 1?) and an ACK value of the received data is only checked (if at all) to be in the window. (It doesn't talk about the ACK value at all in the section you referenced. in fact it says: A legitimate peer, after restart, would not have a TCB in the synchronized state. Thus when the ACK arrives the peer should send a RST segment back with the sequence number derived from the ACK field that caused the RST. however in the code I an pointing to in send_reject6() in ip_fw2.c it seems that it is the ACK that is being calculated, and not the SEQUENCE number.