Fixing "Slipping in the window" before 4.11-release

[Charles Swiger]

On Jan 3, 2005, at 2:31 AM, Mike Silbersack wrote:
> 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