[816] in bugtraq
Re: the next generation of nuke.c
daemon@ATHENA.MIT.EDU (smb@research.att.com)
Fri Jan 27 14:06:51 1995
From: smb@research.att.com
To: dorian@oxygen.house.gov (Dorian Deane)
Cc: bugtraq@fc.net
Date: Fri, 27 Jan 95 11:14:04 EST
I'm sure I'm confused, but...
It seems logical that RST sequence numbers should be ignored. RSTs are
usually sent to abort a hosed connection, one in which it is likely the
sequence numbers are already out of whack.
No. Here's an excerpt from section 3.4 of RFC 793, the TCP spec:
Reset Processing
In all states except SYN-SENT, all reset (RST) segments are validated
by checking their SEQ-fields. A reset is valid if its sequence number
is in the window. In the SYN-SENT state (a RST received in response
to an initial SYN), the RST is acceptable if the ACK field
acknowledges the SYN.
The receiver of a RST first validates it, then changes state. If the
receiver was in the LISTEN state, it ignores it. If the receiver was
in SYN-RECEIVED state and had previously been in the LISTEN state,
then the receiver returns to the LISTEN state, otherwise the receiver
aborts the connection and goes to the CLOSED state. If the receiver
was in any other state, it aborts the connection and advises the user
and goes to the CLOSED state.
The preceeding paragraphs describe when to send an RST, and how to
create the sequence number for it. If you read them, you'll see that
most packets that can elicit an RST carry an SEQ field; it can be used
to generate the sequence number for the RST.
We're getting a bit far afield here, and I won't pursue the topic further
save to note that TCP's behavior is carefully crafted, and trying to
change one small piece of it can have unintended side-effects. For
example, I'm not at all convinced that it's safe -- from a non-security
perspective -- to use random initial sequence numbers. See section 3.3
of the RFC for the rationale for the current behavior.
