Re: the next generation of nuke.c

[smb () research att com (smb () research att com)]

         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.