Date: Mon, 3 Jan 2005 13:02:26 -0500 From: Charles Swiger <cswiger@mac.com> To: Mike Silbersack <silby@silby.com> Cc: net@freebsd.org Subject: Re: Fixing "Slipping in the window" before 4.11-release Message-ID: <A04C4750-5DB1-11D9-95E0-003065ABFD92@mac.com> In-Reply-To: <20050103012325.A62262@odysseus.silby.com> References: <20050103012325.A62262@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A04C4750-5DB1-11D9-95E0-003065ABFD92>