Date: Tue, 5 Jul 2005 16:35:29 -0400 From: Garrett Wollman <wollman@csail.mit.edu> To: Darren Reed <avalon@caligula.anu.edu.au> Cc: freebsd-security@freebsd.org Subject: Re: packets with syn/fin vs pf_norm.c Message-ID: <17098.61201.244682.110397@khavrinen.csail.mit.edu> In-Reply-To: <200507051428.j65ESjJu001522@caligula.anu.edu.au> References: <17096.38921.588487.576918@khavrinen.csail.mit.edu> <200507051428.j65ESjJu001522@caligula.anu.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 6 Jul 2005 00:28:45 +1000 (Australia/ACT), Darren Reed <avalon@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17098.61201.244682.110397>