packets with syn/fin vs pf_norm.c

[Jesper Wallin]

Darren Reed wrote:

>In some mail from Garrett Wollman, sie said:
>  
>
>><<On Mon, 04 Jul 2005 02:53:33 +0200, des at des.no (Dag-Erling Smørgrav) said:
>>
>>    
>>
>>>It is not invalid for a TCP segment to have both SYN and FIN set.  See
>>>for instance RFC 1644.
>>>      
>>>
>>RFC 793 is perhaps the better reference, followed by RFC 1025.
>>    
>>
>
>No, you're wrong on this.
>
>Packets for TCP with SYN + FIN set are valid under T/TCP.
>T/TCP is documented under RFC 1644.  To claim that these, earlier,
>documents render it ... "dead" is to argue that SACK and all other
>TCP enhancements since also fall into that bucket.
>
>Very few people use T/TCP, although I believe FreeBSD is the only
>one of the BSDs that has done anything serious with it.  pf is wrong
>to unconditionally clear the FIN flag.  So there are a number of
>options here:
>- fix pf to not remove the FIN flag in FreeBSD
>- don't use T/TCP
>- don't use scrub in pf
>- don't use pf
>
>I think this is a bug in the scrub implementation and should be
>fixed.
>
>Darren
>
Like mentioned in my first mail, I don't know anything about C programming,
but I just wanted to say that my patch seems to work and scrub will now 
drop
packets with both SYN/FIN bits set. Yet, I doubt it's far from optimized or
good to do it that way and I would love if someone could rewrite/look at it.

Also, I wonder why the TCP_DROP_SYNFIN option isn't checked in pf_norm.c?
Sure, it might be bad/good/whatever dropping packets with SYN/FIN, but 
if you
decide to do it and add the TCP_DROP_SYNFIN option, then it should drop them
even if you use pf, ipf or ipfw.. or is it just me having wrong 
expectations?


Best regards,
Jesper Wallin