All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Cc: Eyal Birger <eyal.birger@gmail.com>,
	Steffen Klassert <steffen.klassert@secunet.com>,
	linux-crypto@vger.kernel.org, netfilter-devel@vger.kernel.org,
	Linux Kernel Network Developers <netdev@vger.kernel.org>
Subject: Re: [PATCH v2] xfrm: interface: Don't hide plain packets from netfilter
Date: Thu, 10 Dec 2020 18:57:40 +0100	[thread overview]
Message-ID: <20201210175740.GI4647@orbyte.nwl.cc> (raw)
In-Reply-To: <b5c1259b-71e8-57d2-85f2-d5971f33e977@6wind.com>

Hi Nicolas,

On Thu, Dec 10, 2020 at 02:18:45PM +0100, Nicolas Dichtel wrote:
> Le 10/12/2020 à 12:48, Eyal Birger a écrit :
> > On Thu, Dec 10, 2020 at 1:10 PM Nicolas Dichtel
> > <nicolas.dichtel@6wind.com> wrote:
> [snip]
> > I also think they should be consistent. But it'd still be confusing to me
> > to get an OUTPUT hook on the inner packet in the forwarding case.
> I re-read the whole thread and I agree with you. There is no reason to pass the
> inner packet through the OUTPUT hook (my comment about the consistency with ip
> tunnels is still valid ;-)).
> Sorry for the confusion.
> 
> Phil, with nftables, you can match the 'kind' of the interface, that should be
> enough to match packets, isn't it?

Yes, sure. Also, the inner packet passes POSTROUTING hook with ipsec
context present, it's just not visible in OUTPUT. Of course the broader
question is what do people use ipsec context matches for. If it's really
just to ensure traffic is encrypted, xfrm_interface alone is sufficient.

Originally this was reported as "ipsec match stops working if
xfrm_interface is used" and I suspected it's a bug in the driver.
Knowing the behaviour is expected (and at least consistent with vti),
the case is closed from my side. :)

Thanks, Phil

      reply	other threads:[~2020-12-10 17:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-07 13:43 [PATCH v2] xfrm: interface: Don't hide plain packets from netfilter Phil Sutter
2020-12-08  9:02 ` Nicolas Dichtel
2020-12-08 14:00   ` Phil Sutter
2020-12-08 14:45     ` Nicolas Dichtel
2020-12-08 14:47 ` Eyal Birger
2020-12-08 18:51   ` Phil Sutter
2020-12-09 14:40     ` Eyal Birger
2020-12-10 11:10       ` Nicolas Dichtel
2020-12-10 11:48         ` Eyal Birger
2020-12-10 13:18           ` Nicolas Dichtel
2020-12-10 17:57             ` Phil Sutter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201210175740.GI4647@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=eyal.birger@gmail.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.com \
    --cc=steffen.klassert@secunet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.