Date: Fri, 23 Apr 2004 03:41:27 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: silby@silby.com Cc: jayanth@yahoo-inc.com Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) Message-ID: <200404231041.i3NAfR7E051507@gw.catspoiler.org> In-Reply-To: <20040423040235.R703@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 Apr, Mike Silbersack wrote: > > On Thu, 22 Apr 2004, jayanth wrote: > >> if i remember right this was done to handle the Alteons which >> generate a RST segment that would fall within the window size but not the >> next expected sequence no. >> So they would do something crazy like rcv_nxt + rcv_win as the sequence no, >> for the RST segment rather than rcv_nxt + 1. >> This was part of the RFC though. >> >> If it is a problem we can always revert it back. >> >> jayanth > > What type of packet was causing the Alteons to emit the RST? SYN, FIN, > normal data? > > Also, has Alteon fixed the problem or do their load balancers still > exhibit the behavior? The link I posted showed it was a FIN, and after the RST was sent (and ignored by the FreeBSD stack because of the strict sequence number check), the Alteon (or whatever it was) did not respond to the retransmissions of the FIN packet. Maybe we can get by with the strict check by default and add a sysctl to revert to the permissive check.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404231041.i3NAfR7E051507>