For the life of me, I can't figure out why SYN packets (other than delayed retransmissions of the original SYN) would ever show up once a connection is in the ESTABLISHED state. So, I'm proposing the attached patch, which simply ignores any packet with the SYN flag on it while a connection is in the ESTABLISHED state.
Are you relying on the IPID or the connection tuple of srcIP+srcPort+destIP+destPort to identify the SYN packet as being associated with an already established connection?
I suppose that if the sending TCP stack has poor IPID sequence generation, maybe it could be reusing IPIDs and thus breaking the uniqueness assumption.
This means that SYN packets left of the window will no longer receive an ACK, and SYN packets in the window will no longer reset the connection. In all states other than ESTABLISHED, SYN packets are handled as they were before, in case there's some edge case where that could happen.
This seems to be a reasonable improvement: the stack shouldn't be ACK'ing data outside of a valid connection window to begin with.
What are people's thoughts on this? I'm especially interested how stateful firewalls like IPF or PF would handle such a situation. How do they respond to unexpected SYN packets?
Generally, each bare SYN packet is treated as a seperate new connection request, and they expect the destination TCP stack to handle any duplicate SYNs resulting from duplicated packets.
-- -Chuck
_______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
