From owner-freebsd-net@FreeBSD.ORG Fri Jan 16 15:34:51 2004 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 0BF2116A4CE for ; Fri, 16 Jan 2004 15:34:51 -0800 (PST) Received: from starburst.demon.co.uk (adsl-02-163.abel.net.uk [193.109.51.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE97243D2F for ; Fri, 16 Jan 2004 15:34:48 -0800 (PST) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id XAA04091; Fri, 16 Jan 2004 23:36:02 GMT From: Richard Wendland Message-Id: <200401162336.XAA04091@starburst.demon.co.uk> To: kfaiczak@sandvine.com (Ken Faiczak) Date: Fri, 16 Jan 2004 23:36:01 +0000 (GMT) In-Reply-To: from "Ken Faiczak" at Jan 16, 2004 11:26:11 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: forged tsecr giving -ve numbers in rtt calculation causing retran X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rw@codeburst.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 23:34:51 -0000 > it seems there is no protection from TCP session > mucking up the tsecr values > in some cases [t_rxtcur] ends up as say -450000000 > because the secr has been forged. I looked into this a couple of months ago, and thought at that time that the "max allowable REXMT value" TCPTV_REXMTMAX (64 secs) would defend against the worst effects of inappropriate TSECRs. I was wrong, as TCPT_RANGESET works in an unfortunate way if strangely tvmin > tvmax, and fails to limit t_rxtcur to TCPTV_REXMTMAX. I'd hazard a guess that you are seeing zero, not forged, TSECRs. Windows sets TSECR zero on SYN-ACK when it does a passive open. This is established Windows behaviour for several years, and there is a reading of RFC1323 that might justify this. I've raised this issue with the RFC1323 authors, who are drafting an update to RFC1323: http://www.ietf.org/mail-archive/working-groups/tsvwg/current/msg04501.html To work around the problem for now you could obviously set net.inet.tcp.rfc1323=0. To validate TSECR properly I think the decision to use the timestamp option or not for SRTT calculation should be moved into tcp_xmit_timer() rather than done inline in tcp_input(); so the logic isn't duplicated. Another approach is to get the TCPTV_REXMTMAX limit implemented properly, by changing TCPT_RANGESET to prefer to pin result to tvmax rather than tvmin if there is a conflict. ie move the tvmax test before the tvmin test (or remove the else so both tests are made). I doubt if fixing TCPT_RANGESET is a complete answer for this problem though, as t_srtt and t_rttvar are used for more than the retransmit timer. Probably worth doing both. NB In terms of validating TSECR another risk is that an aggressive remote endpoint might manipulate it to artificially reduce SRTT, eg to get faster retransmits. I'm not sure what could easily be done against this. NB2 This problem with Windows only occurs when FreeBSD is acting as client (active open) to a Windows server. I believe, luckily, it doesn't affect the more common situation of Windows as client to a FreeBSD server. Richard -- Richard Wendland richard@wendland.org.uk