Date: Wed, 21 Apr 2004 04:29:17 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: silby@silby.com Cc: avalon@caligula.anu.edu.au Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) Message-ID: <200404211129.i3LBTH7E046516@gw.catspoiler.org> In-Reply-To: <20040421014736.H1228@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Apr, Mike Silbersack wrote:
>
> On Tue, 20 Apr 2004, Don Lewis wrote:
>
>> I am concerned that step C will not solve the compatibility problem. The
>> FreeBSD host is sending a FIN to close an established connection, and
>> the peer host adding the window size advertised in the FIN packet to the
>> sequence number acknowledged in the FIN packet, and using the sum as the
>> sequence number for the RST packet, which puts the sequence number at
>> the end of the receive window.
>
> Would it be feasible for us to create a four to five element array to
> track "resettable" sequence numbers? This could hold the sequence numbers
> of the last few packets transmitted, and account for that edge case as
> well. I'm very uneasy with the IETF step C - sending more packets out
> into the network sounds like a new type of amplification attack.
I'd be concerned about the extra memory, especially in cases where we
want to support very large numbers of connections.
As far as amplification, step C has a gain of less than one, since
packets are only transmitted if the incoming packet hits the window, and
they will be the same or smaller in size than the incoming packets. I
don't know if it would be valid to rate limit them ...
If this is the only edge case that we have to worry about, we might be
able change the test to:
if (th->th_seq == tp->last_ack_sent ||
th->th_seq == tp->last_ack_sent + tp->rcv_wnd - 1) {
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404211129.i3LBTH7E046516>