Re: packets with syn/fin vs pf_norm.c
From: Garrett Wollman (wollman_at_csail.mit.edu)
Date: 07/05/05
- Previous message: fooler: "Re: packets with syn/fin vs pf_norm.c"
- In reply to: Darren Reed: "Re: packets with syn/fin vs pf_norm.c"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 5 Jul 2005 16:35:29 -0400 To: Darren Reed <avalon@caligula.anu.edu.au>
<<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
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
- Previous message: fooler: "Re: packets with syn/fin vs pf_norm.c"
- In reply to: Darren Reed: "Re: packets with syn/fin vs pf_norm.c"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
