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:   Thu, 26 Nov 2020 10:40:21 +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: <20201126094021.GK8805@gauss3.secunet.de>
References: <20201125112342.GA11766@orbyte.nwl.cc>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20201125112342.GA11766@orbyte.nwl.cc>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

Hi Phil,

On Wed, Nov 25, 2020 at 12:23:42PM +0100, Phil Sutter wrote:
> Hi Steffen,
> 
> I am working on a ticket complaining about netfilter policy match
> missing packets in OUTPUT chain if XFRM interface is being used.
> 
> I don't fully overlook the relevant code path, but it seems like
> skb_dest(skb)->xfrm is not yet assigned when the skb is routed towards
> XFRM interface and already cleared again (by xfrm_output_one?) before it
> makes its way towards the real output interface. NF_INET_POST_ROUTING
> hook works though.
> 
> 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.

Does netfilter match against skb_dst(skb)->xfrm? What is the exact case
that does not work?