From owner-freebsd-current Fri Sep 4 13:06:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA24377 for freebsd-current-outgoing; Fri, 4 Sep 1998 13:06:03 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from lunacity.ne.mediaone.net (lunacity.ne.mediaone.net [24.128.118.236]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA24285 for ; Fri, 4 Sep 1998 13:06:00 -0700 (PDT) (envelope-from mycroft@lunacity.ne.mediaone.net) Received: (from mycroft@localhost) by lunacity.ne.mediaone.net (8.8.8/8.8.8) id QAA01407; Fri, 4 Sep 1998 16:05:01 -0400 (EDT) Date: Fri, 4 Sep 1998 16:05:01 -0400 (EDT) Message-Id: <199809042005.QAA01407@lunacity.ne.mediaone.net> From: "Charles M. Hannum" To: Jos Backus Cc: freebsd-current@FreeBSD.ORG Cc: tcp-impl@cthulu.engr.sgi.com Subject: Re: Should FreeBSD-3.0 ship with RFC 1644 (T/TCP) turned off by default? Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Bellovin's RFC instead uses a hash based on everything *except* the > time-based ISS to rotate the ISS space into a different position for > each possible pair of addresses and ports. This preserves the correct > TCP behaviour, while frustrating sequence number attacks by preventing > rapid testing of possible ISNs -- because an ISS learned from probing > one pair of addresses and ports is not useful in predicting the ISS > for another pair, and you can't test a particular pair again until the > previous SYN has timed out. Is occurs to me that the latter part of this probably isn't true, if the attacker interleaves SYNs and RSTs. I'm left wondering if any of these hashes actually provides a security benefit beyond a randomized increment, except against a completely naive attacker using an old exploit program. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message