On Fri, 23 Apr 2004, Leo Bicknell wrote: : I point out NetBSD released this: : : ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2004-006.txt.asc Yes. I made reference to this in the "Vendor TCP oops-es" thread where I explained the conveniently forgotten magnitude scale of the problem. I find it rather amusing that so many folks are talking about various paper-over methods as The Fix (and that it's somehow only a threat to BGP4), rather than discussing the real issue: how to fix the underlying TCP *implementation* problems. As designed, TCPv4 still provides reasonable threat avoidance for non-AH sessions -- even on a 10GE link. Fixing the vendor stacks and putting in proper random source port allocation would alleviate a lot more than just this problem. Then, if desired, AH/MD5/whatever could stack on top of that for even more magnitude bits. : ] Additionally, the 4.4BSD stack from which NetBSD's stack is derived, did : ] not even check that a RST's sequence number was inside the window. : It's a good thing the 4.4BSD stack was unpopular, Several embedded OS's used the Net/2 (post-4.3-Tahoe) stack for a while and may still be maintaining license-cleansed forks of it. I haven't checked directly, but if the problem was in 4.4, it was probably also in 4.3. I know I'd done some sort of RST attack against a SunOS4.0 box in the past (silly IRC games, of course; see my other post), and that was a 4.2BSD fork. But, this could have been sarcasm on your part. If so, it went right over my head. 8-) -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>