Questions arose while trying to explain proposed TCP fixes to my students. Can y'all help me with these? We were going over the "Transmission Control Protocol security considerations draft-ietf-tcpm-tcpsecure-00.txt" document here when the questions arose: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt The questions have to do with this from the document: the following changes should be made to provide some protection against such an attack. A) If the RST bit is set and the sequence number is outside the expected window, silently drop the segment. B) If the RST bit is exactly the next expected sequence number, reset the connection. C) If the RST bit is set and the sequence number does not exactly match the next expected sequence value, yet is within the acceptable window (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) send an acknowledgment. This solution forms a challenge/response with any RST where the value does not exactly match the expected value and yet the RST is within the window. In cases of a legitimate reset without the exact sequence number, the consequences of this new challenge/response will be that the peer requires an extra round trip time before the connection can be reset. So, per item C, does the recipient of a RST with a sequence number that does not exactly match the next expected sequence value not reset the connection? It sends an ACK but keeps the connection open? The ACK will go to the correct TCP partner, not the attacker presumably. So then that partner resets. But where does this leave the other partner (the recipient of the RST)? Is the assumption that this side may continue sending, which would cause the other side to RST (since it closed the session) and this RST would have the correct sequence number so the connection would get reset from both partners' points of view? Regardless of hackers, we're trying to figure out how to legitimately RST despite possibly not having the exact right sequence value. Thanks, Priscilla Oppenheimer At 09:48 PM 4/23/04, Todd Vierling wrote:
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>
_______________________________ Priscilla Oppenheimer www.priscilla.com When your Daemon is in charge, do not try to think consciously. Drift, wait, and obey. -- Kipling.