Date: Thu, 14 Dec 2006 11:43:11 -0800 From: Julian Elischer <julian@elischer.org> To: Andre Oppermann <andre@freebsd.org> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: question for TCP gurus (in ipfw) Message-ID: <4581A94F.7030301@elischer.org> In-Reply-To: <45812E01.9060200@freebsd.org> References: <458094E7.1060806@elischer.org> <45812E01.9060200@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4581A94F.7030301>