From owner-freebsd-net@FreeBSD.ORG Thu May 29 13:44:48 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 E8195D5C for ; Thu, 29 May 2014 13:44:47 +0000 (UTC) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (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 AB9BF2B3E for ; Thu, 29 May 2014 13:44:47 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id wm4so325787obc.40 for ; Thu, 29 May 2014 06:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jT4SpgtE+BCURAYka4tJ9pbCaLdAR+fnPD1t9mNQSoM=; b=kY1XwsbeyLsR3WRv6pVuk5fpHzDA2rrmSZGoyyaU0EpDo9C6jDNr8zIWMqMCZF7M35 Aj4lrFnnyJwMYaSvfSDW28/BweaDUC5kRnAN3zXop9bfrOlhoDmY9uRxlIGX6dj+Pnqk N0C5ByzskrH1kCRU+WbC9s8hjk5DzPWiFOKOzDVsT14F8CdmjH5NL8Si+Bg2AeQSnWfj aCyrwVc6TdSSnX4Zz/QCFrl9e1N+NVcZD6o0mwExekYHC28xekv5P+YqMIv3WnnzjAR2 px4D2prDTqfIo9WWyRJmV1pqhHyS6kT2sX1yBvMKRnL5FVmpxgWJtYh7ywptufbWE0/M 4Dog== MIME-Version: 1.0 X-Received: by 10.60.74.163 with SMTP id u3mr8867695oev.2.1401371086910; Thu, 29 May 2014 06:44:46 -0700 (PDT) Received: by 10.76.170.39 with HTTP; Thu, 29 May 2014 06:44:46 -0700 (PDT) In-Reply-To: References: <001b01cf7b3b$dfd1cfb0$9f756f10$@gmail.com> <20140529131015.GA72798@onelab2.iet.unipi.it> Date: Thu, 29 May 2014 15:44:46 +0200 Message-ID: Subject: Re: propose a new generic purpose rule option for ipfw From: Andreas Nilsson To: Luigi Rizzo 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:44:48 -0000 On Thu, May 29, 2014 at 3:39 PM, Luigi Rizzo wrote: > > > > On Thu, May 29, 2014 at 3:32 PM, Andreas Nilsson wrot= e: > >> 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? >> > > Good enough for me. I might be able to get some time on a xena 10g device to check some numbers if there is any interest for coming changesets. Best regards Andreas > =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 >> > > > > -- > -----------------------------------------+------------------------------- > 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) > -----------------------------------------+------------------------------- >