Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Jan 2000 23:38:35 -0800
From:      Don Lewis <Don.Lewis@tsc.tdk.com>
To:        Richard Steenbergen <ras@above.net>, Alfred Perlstein <bright@wintelcom.net>
Cc:        freebsd-security@FreeBSD.ORG
Subject:   Re: stream.c
Message-ID:  <200001240738.XAA21595@salsa.gv.tsc.tdk.com>
In-Reply-To: <20000123112220.E18349@above.net>
References:  <20000123102829.C18349@above.net> <20000123083234.N26520@fw.wintelcom.net> <20000123112220.E18349@above.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 23, 11:22am, Richard Steenbergen wrote:
} Subject: Re: stream.c
} On Sun, Jan 23, 2000 at 08:32:34AM -0800, Alfred Perlstein wrote:
} > * Richard Steenbergen <ras@above.net> [000123 07:53] wrote:
} > > 
} > > The correct "sorta-fix" is to rate limit the number of dropwithreset's per
} > > second, else kick them down to straight drop. I believe this has been done
} > > effectively in http://www.freebsd.org/~alfred/tcp_fix.diff (though I
} > > question what its aimed to be accomplished with that checksum work :P).
} > 
} > The idea is to reduce the amount of time spent doing checksums on invalid
} > packets, why checksum if the destination port isn't open or no such
} > connection is open?
} > 
} > Unfortunatly even after moving the checksum quite far into tcp_input's
} > path it still seems pretty easy to eat all CPU on a box, in fact I
} > didn't notice any improvement at all.

If the checksum was the problem, then an attacker could DoS the machine
by creating a connection and sending duplicate packets.  This could
be trivially be done by repeatedly sending the same SYN+data.  You have
to do the checksum before fitting the segment into the input stream.

} > Maybe i'm missing something, those interested can have a try at:
} > http://www.freebsd.org/~alfred/tcp_fix_untested.diff
} > 
} > maybe someone can tell me what i'm screwing up.
} 
} The checksums are a pretty small amount of the CPU time burned. The RST
} generation is by far the worst, the PCB hash lookups are 2nd after that.

Any idea why RST generation is so bad?

} And really you shouldn't be doing any work at all if the checksum is
} invalid. :P


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001240738.XAA21595>