From owner-freebsd-net@FreeBSD.ORG Thu May 29 13:39:35 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 9A033B06 for ; Thu, 29 May 2014 13:39:35 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (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 25CF52AA2 for ; Thu, 29 May 2014 13:39:34 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id k14so403300wgh.31 for ; Thu, 29 May 2014 06:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=S1ckVrltOVQCqrrfBc9jk3AM26D14YAlzJqW1NH3lwA=; b=MmLKx96deSxeACji/GZdDi+95O1cXiTDskuALMzjmpkdt8nJmj7TWeYDQyvnk50hQZ VqA5Ryh3weQxPKHdZwnj7e7c8SPLDxX9ipbqAK8Z/O085TNUWrjmR1j1id+oc9u+El2w hCNK2SsFuZidEEp/wRHvEda+KQ5ByEX65M1x81dhbrNOjai7a4YUyT1hJ11TGXtc5QUX ChrnhyzE1FEZ+M3emv+0CTmFgcr0gY06hswfEgxwh/I7P/XVRWPRu/SSwRDSVAfuSvqX aIwTXmmmdKy7t+6b5B3ydyIAHNdQtJmpqBkIjaRBlRx3HvqM52W0NWpYOrws+IV1kU+K 2MsA== MIME-Version: 1.0 X-Received: by 10.180.183.131 with SMTP id em3mr59271054wic.56.1401370773039; Thu, 29 May 2014 06:39:33 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.194.246.130 with HTTP; Thu, 29 May 2014 06:39:32 -0700 (PDT) In-Reply-To: References: <001b01cf7b3b$dfd1cfb0$9f756f10$@gmail.com> <20140529131015.GA72798@onelab2.iet.unipi.it> Date: Thu, 29 May 2014 15:39:32 +0200 X-Google-Sender-Auth: _8lPprQ6CPgBw9hbSMYLuj4or3A Message-ID: Subject: Re: propose a new generic purpose rule option for ipfw From: Luigi Rizzo To: Andreas Nilsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Net , bycn82 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 13:39:35 -0000 On Thu, May 29, 2014 at 3:32 PM, Andreas Nilsson wrote= : > On Thu, May 29, 2014 at 3:10 PM, Luigi Rizzo wrote: > >> On Thu, May 29, 2014 at 08:45:26PM +0800, bycn82 wrote: >> ... >> > >> > 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? >> >> we do not have an option for fixed position matching. >> >> As i said, feel free to submit one and i will be happy to >> import it if the code is clean (btw i am still waiting >> for fixes to the other 'rate limiting' option you sent), >> but keep in mind that 'fixed position' is mostly useless. >> >> More useful options would be one where you express the position as >> >> '{MAC|VLAN|IP|UDP|TCP|...|PAYLOAD}+offset' >> >> so at least you can adapt to variant headers, or one where you can look >> for a pattern in the entire packet or in a portion of it. >> >> cheers >> luigi >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > Wouldn't PAYLOAD require possibly reassembly of a fragmented packet? > =E2=80=8Bwell, other firewalls do reassemble fragments, ipfw does not (actually there was some code floating around in the past that did implement a reassembly, not sure if it was committed). With this in mind, PAYLOAD would not be that different from TCP if you think that you can have a ton of IPV6 headers and extensions.=E2=80=8B So if/when we implement reassembly, that would be the default for any action that searches past the end of the first fragment. Except from fragmentation, all ipfw instructions already track the beginning of the relevant header for the info at hand (typically skipping ip options or ipv6 headers). It costs something, but not a fortune. cheers luigi > It certainly is a good feature, don't get me wrong. But what are the > performance hits? > > Best regards > Andreas > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+-------------------------------