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

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

On Fri, Mar 03, 2017 at 03:01:57PM +0100, Phil Sutter wrote:
> On Thu, Mar 02, 2017 at 10:25:22PM +0100, Pablo Neira Ayuso wrote:
> > 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:
[...]
> > > 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.
> 
> Well, in bison there would have to be a common entrance point, which
> checks the scope and then generates either payload expr, exthdr expr or
> an error depending on what it is. Correct?

That's right.

> > > 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.
> 
> Not sure if I understand you correctly, but the use-case is matching on
> some AH header field in IPv6 traffic? But sure, if you think that's too
> exotic I could maybe just add some check somewhere which causes an error
> if the family is not specified or not IPv4 and ah expression is being
> used.

As you indicate the AH handling in nft is inconsistent, just like it
happens in iptables and ip6tables, look:

1) in iptables we can do -p ah, then use an extension to match AH
   header from transport.
2) in ip6tables we cannot do -p ah. We use a specific ah extension for
   IPv6 that uses ipv6_find_hdr().

This is a mess.

Please, develop your hybrid idea.