From owner-freebsd-net@FreeBSD.ORG Thu May 29 12:45:30 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 136E37F8 for ; Thu, 29 May 2014 12:45:30 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D810125DB for ; Thu, 29 May 2014 12:45:29 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id ld10so312787pab.20 for ; Thu, 29 May 2014 05:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=ZbG43PLuPiP7LxXZQHp2MuHp4d2iAvXKNaK5QAyhoco=; b=R5JCcq3hbwoTXfQ4TRqCYULGCCJ87Vr8Tvcq4NnZ5vA5mmev4Bj1W6JTcA1tWOgn26 fKvX4AefLkLdWUYh+h3NBUFHqSmHbnG50q8DaWy8q+89nGbTK884Ur+StaOhfDkkqszU Us2gwXo8FG+lTU3/wSWDdJMudgcSem3SVWenrg8AeGbssnRyIM49phWIW9pkgKfDFM1+ hEepxO2OyDhXJEjFe8ZrOvArYCBSwmwGZdUuK/GKRmIeyf36WveZzLoEecJGq2baY4WX r9aMXltWWMFZDChVgPNSGdGNgsF/nNJo4n7e6IlDan8+4vDdM3CLfmkXtbX5Htc3ngK5 QRpg== X-Received: by 10.66.164.5 with SMTP id ym5mr8728920pab.50.1401367529524; Thu, 29 May 2014 05:45:29 -0700 (PDT) Received: from billwin7 (amx-tls2.starhub.net.sg. [203.116.164.12]) by mx.google.com with ESMTPSA id qw8sm1140806pbb.27.2014.05.29.05.45.27 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 May 2014 05:45:28 -0700 (PDT) From: "bycn82" To: "'Luigi Rizzo'" References: In-Reply-To: Subject: RE: propose a new generic purpose rule option for ipfw Date: Thu, 29 May 2014 20:45:26 +0800 Message-ID: <001b01cf7b3b$dfd1cfb0$9f756f10$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGHvkjU79R1H+5sSqlQcstB+XJ0CwD6Vot3m98ZEXA= Content-Language: en-us Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: 'FreeBSD Net' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:45:30 -0000 =20 Sure your generic binary match could be a welcome addition to ipfw. But its usefulness is extremely limited in practice, as it only lets you match stuff in fixed position of a packet, and it is not even good to do other relatively simple things such as skip options and the like. =20 Sure. When the user need to fulfill a feature and there is a rule option = for it. Then in this scenario . the user should definitely use the = option. Except the user this testing this feature. =20 If you have spare time you might try how hard would it be to hook the in-kernel bpf to ipfw. That would be a superset of what you propose, and avoids duplication of effort and features. =20 By the way, what is in-kernel bpf. I ve read your dummynet already, = still have some place not clear. =20 This said, even bpf is not a generic firewall mechanism. =20 Much of the power of a firewall comes from the availability of high level functions and data structures and metadata access functions to reduce the complexity and improve the quality of matches. Many of the ipfw options are just for that: address and port bitmaps, tables, reverse path lookup, metadata lookups and so on. =20 Sure, that is the reason why developers are providing more and more rule = options. But the my question is do we have enough options to match all = the fixed position values? =20 cheers luigi =20