Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 27 Nov 2020 10:55:11 +0100
From:   Steffen Klassert <steffen.klassert@secunet.com>
To:     Phil Sutter <phil@nwl.cc>, <linux-crypto@vger.kernel.org>,
        <netfilter-devel@vger.kernel.org>
Subject: Re: XFRM interface and NF_INET_LOCAL_OUT hook
Message-ID: <20201127095511.GD9390@gauss3.secunet.de>
References: <20201125112342.GA11766@orbyte.nwl.cc>
 <20201126094021.GK8805@gauss3.secunet.de>
 <20201126131200.GH4647@orbyte.nwl.cc>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20201126131200.GH4647@orbyte.nwl.cc>
Precedence: bulk

On Thu, Nov 26, 2020 at 02:12:00PM +0100, Phil Sutter wrote:
> > > 
> > > Is this a bug or an expected quirk when using XFRM interface?
> > 
> > This is expected behaviour. The xfrm interfaces are plaintext devices,
> > the plaintext packets are routed to the xfrm interface which guarantees
> > transformation. So the lookup that assigns skb_dst(skb)->xfrm
> > happens 'behind' the interface. After transformation,
> > skb_dst(skb)->xfrm will be cleared. So this assignment exists just
> > inside xfrm in that case.
> 
> OK, thanks for the clarification.
> 
> > Does netfilter match against skb_dst(skb)->xfrm? What is the exact case
> > that does not work?
> 
> The reported use-case is a match against tunnel data in output hook:
> 
> | table t {
> |     chain c {
> |         type filter hook output priority filter
> |         oifname eth0 ipsec out ip daddr 192.168.1.2
> |     }
> | }
> 
> The ipsec expression tries to extract that data from skb_dst(skb)->xfrm
> if present. In xt_policy (for iptables), code is equivalent. The above
> works when not using xfrm_interface. Initially I assumed one just needs
> to adjust the oifname match, but even dropping it doesn't help.

Yes, this does not work with xfrm interfaces. As said, they are plaintext
devices that guarantee transformation.

Maybe you can try to match after transformation by using the secpath,
but not sure if that is what you need.