From owner-freebsd-net@FreeBSD.ORG Thu May 29 07:25:22 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 B31CF6B7 for ; Thu, 29 May 2014 07:25:22 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 8D8602702 for ; Thu, 29 May 2014 07:25:22 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id kq14so12435607pab.38 for ; Thu, 29 May 2014 00:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BuujjfCPtSdNEQRM9/qw4tzDXlAve6/UAPB+thB9qMU=; b=zCwNsMyX5/JLEmwec2sByUXjHcUW1EM2ShWQLYhL/7yQuN/HKCef8d1TtUYb4nWmjt fXsy5MQ4wv5EHKecohe0Rk8nX8NeWzoTDcCFvw1Svnsp5ojKfCp1UpUix5T+ZVJkHGGR CYthkKytMFqqs9RuhdJhEVEpnbKh8jxla1pwCk3xg9/gSIQSl4hUoYvmXK3cZnArdykI xtJZlf8MDlB416eJCusvSO1PZ0NMKnSPhjMB5Kz3wKMaP+u4UreEVpbFMg8RquKfiO3y VfCFyqtnLsrdWDHiEGOW0sB7nOPTuFbiH6zttgn8HHNHtU8iGjxfAk0lf8CKBaTtqN2r GNMQ== MIME-Version: 1.0 X-Received: by 10.66.192.104 with SMTP id hf8mr6367673pac.13.1401348322180; Thu, 29 May 2014 00:25:22 -0700 (PDT) Received: by 10.70.126.138 with HTTP; Thu, 29 May 2014 00:25:22 -0700 (PDT) Date: Thu, 29 May 2014 15:25:22 +0800 Message-ID: Subject: propose a new generic purpose rule option for ipfw From: Bill Yuan To: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 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 07:25:22 -0000 hi the rule of ipfw is kind of semantic, and it is powerful. so it means good for normal users. but not for developers of it, because simplicity actually is hidden complexity.that is the reason developers fulfilled so many rule options to match the traffic. and the man page of ipfw becomes long long. (maybe the manpage for ipfw should be spitted into multiple pages) Yesterday I was thinking, "a firewall is ... when the traffic comes, it will be filtered based on the rule, and the action will be executed when the rule matched". so actually the job is quite simple. So I was thinking whether there is a generic method to handle the filtering? And the "U32" module of iptables came into my mind immediately.I think the feature is cool. and I am going to introduce this feature into ipfw, if have people like this feature, since i am free recently :). So i am proposing a new rule option `u32` and the usage will be "u32 " e.g. >ipfw add 1 allow all from any to any u32 0 0x112233445566 layer2 It means if part of the traffic(start from position 0) is equal to the 0x112233445566, then it means matched. Or maybe the usage will be more complex that the above. maybe "u32 " e.g >ipfw add 1 allow all from any to any u32 0 0xFFFFFF000000FFFFFF000000 0x111111000000222222000000 layer2 the traffic will be AND the before comparing the . It sounds like "nothing impossible" with this feature!. It is a really powerful thing in my opinion. but it has requirement, to master it requires the knowledge of the structure of the packet/frame/whatever. Anyone like this feature? Like it ? please voice out. Best Regards, bycn82