packets with syn/fin vs pf_norm.c

[Garrett Wollman]

<<On Wed, 6 Jul 2005 00:28:45 +1000 (Australia/ACT), Darren Reed <avalon at caligula.anu.edu.au> said:

> No, you're wrong on this.

> Packets for TCP with SYN + FIN set are valid under T/TCP.

Packets for TCP with SYN + FIN set are valid under TCP, period.  See
RFC 793 page 66, where it describes the processing of segments with
the SYN bit set:

	The connection state should be changed to SYN-RECEIVED.  Note
	that any other incoming control or data (combined with SYN)
	will be processed in the SYN-RECEIVED state, but processing of
	SYN and ACK should not be repeated.

Later, on page 75, the spec discusses the handling of FIN bits:

    eighth, check the FIN bit,

     Do not process the FIN if the state is CLOSED, LISTEN or SYN-SENT
     since the SEG.SEQ cannot be validated; drop the segment and
     return.

[We are in SYN-RECEIVED at this point so this graf does not apply.]

      If the FIN bit is set, signal the user "connection closing" and
      return any pending RECEIVEs with same message, advance RCV.NXT
      over the FIN, and send an acknowledgment for the FIN.  Note that
      FIN implies PUSH for any segment text not yet delivered to the
      user.

	SYN-RECEIVED STATE
	ESTABLISHED STATE

	  Enter the CLOSE-WAIT state.

See also section 3.4 on page 30.

The only thing that RFC 1644 adds to this is the ability to
short-circuit the three-way handshake by means of persistent sequence
numbers.  In short, SYN+FIN segments are legitimate *whether or not*
one is using T/TCP (and one should not be at this point in time, as
the T/TCP protocol is known to be flawed).

Note that the specification does not require a receiver-TCP to buffer
data (including the FIN bit) received on SYN, and FreeBSD in the
current implementation does not do so unless RFC 1644 is in use.  What
PF is doing is not obviously wrong, since it is what FreeBSD's TCP
would normally do anyway.

-GAWollman