Re: nft: ah expression doesn't work for IPv6

[Pablo Neira Ayuso <pablo@netfilter.org>]

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.