Date: Sat, 27 Oct 2007 03:56:29 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Matus Harvan <mharvan@inf.ethz.ch> Cc: freebsd-net@freebsd.org, Brooks Davis <brooks@freebsd.org>, Max Laier <max@love2party.net> Subject: Re: icmp echo_user Message-ID: <4722A8DD.6060601@FreeBSD.org> In-Reply-To: <20071026153128.GF1049@styx.ethz.ch> References: <20070909201152.GA18039@inf.ethz.ch> <20071026153128.GF1049@styx.ethz.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
Matus Harvan wrote: > Hi, > > I was wondering if I could get some feedback about the patch and > whether others think it could be committed. > Thanks for your hard work on mtund. I'm not keen on this patch going into a mainline kernel, though. It stomps on bandwidth limitation if that's in effect -- which is a possible DoS vector -- and also stops updating icmp protocol counters. I believe we should track echo requests in netstat -p regardless of whether the kernel calls icmp_reflect() or not, as it can readily be inferred if a) your diversion to SOCK_RAW is in effect or b) the kernel processed the echo request. I also believe that a user who installs and configures the tunneling daemon is in a position to know that the ICMP thresholds need to be changed. Assuming the tunneling daemon doesn't process echoes unrelated to its tunneling (I haven't read the code), then the fact that rip_input() may exhaust its socket input buffer will provide a basic form of hysteresis, however I would suggest that if you intend to deploy this on the open Internet that the daemon either a) provides its own hysteresis too, b) tunes itself around the bandwidth limit in effect or c) tunes the bandwidth limit itself. A better approach would be to conditionalise the 'goto raw' next to the 'goto reflect'. regards, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4722A8DD.6060601>