From owner-freebsd-net@FreeBSD.ORG Sat Oct 27 02:56:32 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A42016A418 for ; Sat, 27 Oct 2007 02:56:32 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4F61C13C4A6 for ; Sat, 27 Oct 2007 02:56:32 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 93F143EB80; Fri, 26 Oct 2007 22:56:31 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 26 Oct 2007 22:56:31 -0400 X-Sasl-enc: XnrDTQIiarqZgl+I/Xycmba+0epaRDDfeA6mgRoHpFkp 1193453791 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id D78631092B; Fri, 26 Oct 2007 22:56:30 -0400 (EDT) Message-ID: <4722A8DD.6060601@FreeBSD.org> Date: Sat, 27 Oct 2007 03:56:29 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Matus Harvan References: <20070909201152.GA18039@inf.ethz.ch> <20071026153128.GF1049@styx.ethz.ch> In-Reply-To: <20071026153128.GF1049@styx.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Brooks Davis , Max Laier Subject: Re: icmp echo_user X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2007 02:56:32 -0000 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