From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pablo Neira Ayuso Subject: Re: nft: ah expression doesn't work for IPv6 Date: Thu, 2 Mar 2017 22:25:22 +0100 Message-ID: <20170302212522.GA8035@salvia> References: <20170302195651.GX6099@orbyte.nwl.cc> <20170302210129.GA19330@salvia> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Phil Sutter , netfilter-devel@vger.kernel.org, Florian Westphal Return-path: Received: from mail.us.es ([193.147.175.20]:35420 "EHLO mail.us.es" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750941AbdCBVfW (ORCPT ); Thu, 2 Mar 2017 16:35:22 -0500 Received: from antivirus1-rhel7.int (unknown [192.168.2.11]) by mail.us.es (Postfix) with ESMTP id 3A240170DCD for ; Thu, 2 Mar 2017 22:25:30 +0100 (CET) Received: from antivirus1-rhel7.int (localhost [127.0.0.1]) by antivirus1-rhel7.int (Postfix) with ESMTP id 2AF0EDA801 for ; Thu, 2 Mar 2017 22:25:30 +0100 (CET) Received: from antivirus1-rhel7.int (localhost [127.0.0.1]) by antivirus1-rhel7.int (Postfix) with ESMTP id 94F95DA795 for ; Thu, 2 Mar 2017 22:25:27 +0100 (CET) Content-Disposition: inline In-Reply-To: <20170302210129.GA19330@salvia> Sender: netfilter-devel-owner@vger.kernel.org List-ID: On Thu, Mar 02, 2017 at 10:01:29PM +0100, Pablo Neira Ayuso wrote: > On Thu, Mar 02, 2017 at 08:56:52PM +0100, Phil Sutter wrote: > > Hi, > > > > There is currently an open issue with nft in that ah expression doesn't > > work for IPv6 since it creates a payload expression which doesn't find > > the AH IPv6 extension header. > > > > There has been a discussion about this problem off-list in which two > > alternative "solutions" were named, both involve checking the context > > to find out whether one is trying to match an IPv4 or IPv6 packet and > > then create either payload or exthdr expression. Though this solution is > > not optimal, as in (at least) inet table the address family is not given > > per se. > > > > I had the idea of creating a "real" solution to the problem which > > consists of a payload/exthdr hybrid in kernel space searching for the > > given header in different locations depending on the family of the > > actual package being handled. Ideally this should reuse as much code as > > possible, so maybe "just" create both expressions in user space and in > > kernel space only branch between the two. > > If the problem is the inet chain, I would prefer we request explicit > dependencies for ah so we generate the right bytecode depending on the > family. Yes, I mean we would need two different rules for each case by > now. > > On top of that, do you have a real usecase having both AH traffic for > IPv4 and IPv6 traffic? If you don't I would prefer you just fix what > we have and focus on a different task, we have plenty of work to do > ahead. We can hand over you more useful tasks. Sorry, I didn't mean to sound rude. But I would like to see more usecases that would fit into such hybrid. I think we need more usecases (not only AH) to justify this extra complexity that this hybrid (or probably something else we can come up with) requires.