All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eyal Birger <eyal.birger@gmail.com>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: herbert@gondor.apana.org.au, David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>
Subject: Re: [PATCH ipsec-next] xfrm: interface: support collect metadata mode
Date: Fri, 27 Nov 2020 14:32:44 +0200	[thread overview]
Message-ID: <CAHsH6Gtgui7fbv1sPYUoOj_dZR5yajEd7+tLKwsv5FvQZCFOow@mail.gmail.com> (raw)
In-Reply-To: <20201127094414.GC9390@gauss3.secunet.de>

Hi Steffen,

On Fri, Nov 27, 2020 at 11:44 AM Steffen Klassert
<steffen.klassert@secunet.com> wrote:
>
> On Sat, Nov 21, 2020 at 04:28:23PM +0200, Eyal Birger wrote:
> > This commit adds support for 'collect_md' mode on xfrm interfaces.
> >
> > Each net can have one collect_md device, created by providing the
> > IFLA_XFRM_COLLECT_METADATA flag at creation. This device cannot be
> > altered and has no if_id or link device attributes.
> >
> > On transmit to this device, the if_id is fetched from the attached dst
> > metadata on the skb. The dst metadata type used is METADATA_IP_TUNNEL
> > since the only needed property is the if_id stored in the tun_id member
> > of the ip_tunnel_info->key.
>
> Can we please have a separate metadata type for xfrm interfaces?
>
> Sharing such structures turned already out to be a bad idea
> on vti interfaces, let's try to avoid that misstake with
> xfrm interfaces.

My initial thought was to do that, but it looks like most of the constructs
surrounding this facility - tc, nft, ovs, ebpf, ip routing - are built around
struct ip_tunnel_info and don't regard other possible metadata types.

For xfrm interfaces, the only metadata used is the if_id, which is stored
in the metadata tun_id, so I think other than naming consideration, the use
of struct ip_tunnel_info does not imply tunneling and does not limit the
use of xfrmi to a specific mode of operation.

On the other hand, adding a new metadata type would require changing all
other places to regard the new metadata type, with a large number of
userspace visible changes.

>
> > On the receive side, xfrmi_rcv_cb() populates a dst metadata for each
> > packet received and attaches it to the skb. The if_id used in this case is
> > fetched from the xfrm state. This can later be used by upper layers such
> > as tc, ebpf, and ip rules.
> >
> > Because the skb is scrubed in xfrmi_rcv_cb(), the attachment of the dst
> > metadata is postponed until after scrubing. Similarly, xfrm_input() is
> > adapted to avoid dropping metadata dsts by only dropping 'valid'
> > (skb_valid_dst(skb) == true) dsts.
> >
> > Policy matching on packets arriving from collect_md xfrmi devices is
> > done by using the xfrm state existing in the skb's sec_path.
> > The xfrm_if_cb.decode_cb() interface implemented by xfrmi_decode_session()
> > is changed to keep the details of the if_id extraction tucked away
> > in xfrm_interface.c.
> >
> > Signed-off-by: Eyal Birger <eyal.birger@gmail.com>
>
> The rest of the patch looks good.

Thanks for the review!
Eyal.

  reply	other threads:[~2020-11-27 12:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-21 14:28 [PATCH ipsec-next] xfrm: interface: support collect metadata mode Eyal Birger
2020-11-27  9:44 ` Steffen Klassert
2020-11-27 12:32   ` Eyal Birger [this message]
2020-12-02  9:37     ` Steffen Klassert
2020-12-28  7:03       ` Eyal Birger
2021-01-05  8:13         ` Steffen Klassert

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=CAHsH6Gtgui7fbv1sPYUoOj_dZR5yajEd7+tLKwsv5FvQZCFOow@mail.gmail.com \
    --to=eyal.birger@gmail.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --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.