From owner-freebsd-ipfw@FreeBSD.ORG Thu Jul 26 05:54:59 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66805106566C; Thu, 26 Jul 2012 05:54:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 21F2F8FC08; Thu, 26 Jul 2012 05:54:59 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 8F1D47300A; Thu, 26 Jul 2012 08:14:56 +0200 (CEST) Date: Thu, 26 Jul 2012 08:14:56 +0200 From: Luigi Rizzo To: Julian Elischer Message-ID: <20120726061456.GB42206@onelab2.iet.unipi.it> References: <20120725184104.GA35621@onelab2.iet.unipi.it> <5010D6EF.9040805@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5010D6EF.9040805@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: ipfw@freebsd.org, net@freebsd.org Subject: Re: PREVIEW - netmap-enabled ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 05:54:59 -0000 On Wed, Jul 25, 2012 at 10:34:39PM -0700, Julian Elischer wrote: > On 7/25/12 11:41 AM, Luigi Rizzo wrote: > >First and foremost: this is just a preview, only usable for testing now, > >but very very close to working. > > > > http://info.iet.unipi.it/~luigi/netmap/20120725-ipfw-user.tgz > > > >[...] > > > connected to 127.0.0.1:5555 > > 00100 30628621 1408916566 count ip from any to any dst-ip 10.1.0.1 > > 00100 0 0 count ip from any to any dst-ip 10.1.0.2 > > 00100 0 0 count ip from any to any dst-ip 10.1.0.3 > > 65535 30628621 1408916566 allow ip from any to any > > > how do you handle rules that require to be able to see routes and > socket owners? I don't, at least not at this level. Let me elaborate. This project is meant to be used at very high packet rates, and in a router/switch environment. Think of it as a first-level defense against attacks, or a fast NAT device, wich deals with the bulk of the traffic and forwards the rest to the output interface or to the host stack. At the next hop (e.g. in the host stack), you can still have another firewall instance that does the more complex lookups such as socket owners, routes and whatnot. The next step would be to export forwarding information to userspace so you can lookup routes from there too. In principle it should not be that hard to listen for updates on the routing socket and rebuild a forwarding table to be looked up. One could devise a similar strategy for sockets, providing an interface for applications to query existing sockets (we have a sysctl now, i believe) and be notified of creations/destructions of sockets (similar to routing updates; i don't know if this is supported, though) and this will make socket info available to userspace too. cheers luigi