forged tsecr giving -ve numbers in rtt calculation causing retran

[Richard Wendland]

> 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 at wendland.org.uk