lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHsH6Gv0AaNamsumhdqVtuTCMkJCwcAam07kZZoQ0vbuZi7tHA@mail.gmail.com>
Date:   Wed, 24 Aug 2022 21:56:34 +0300
From:   Eyal Birger <eyal.birger@...il.com>
To:     nicolas.dichtel@...nd.com
Cc:     davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        pabeni@...hat.com, steffen.klassert@...unet.com,
        herbert@...dor.apana.org.au, pablo@...filter.org,
        contact@...elbtn.com, dsahern@...nel.org, netdev@...r.kernel.org,
        bpf@...r.kernel.org, devel@...ux-ipsec.org
Subject: Re: [PATCH ipsec-next 3/3] xfrm: lwtunnel: add lwtunnel support for
 xfrm interfaces in collect_md mode

Hi Nicolas,

On Wed, Aug 24, 2022 at 6:21 PM Nicolas Dichtel
<nicolas.dichtel@...nd.com> wrote:
>
>
> Le 23/08/2022 à 17:45, Eyal Birger a écrit :
> > Allow specifying the xfrm interface if_id as part of a route metadata
> > using the lwtunnel infrastructure.
> >
> > This allows for example using a single xfrm interface in collect_md
> > mode as the target of multiple routes each specifying a different if_id.
> >
> > With the appropriate changes to iproute2, considering an xfrm device
> > ipsec1 in collect_md mode one can for example add a route specifying
> > an if_id like so:
> >
> > ip route add <SUBNET> dev ipsec1 encap xfrm if_id 1
> It would be nice to be able to specify the link also. It may help to combine
> this with vrf. Something like
> ip route add <SUBNET> dev ipsec1 encap xfrm if_id 1 dev eth0

I think I understand how this would work on xmit - if you mean adding link
to the metadata and using it to set fl.flowi_oif in xfrmi_xmit() - in which
case the link would be used in the underlying lookup such that routes in
a vrf could specify a device which is part of the vrf for egress.

On RX we could assign the link in the metadata in xfrmi_rcv_cb() to the original
skb->dev. I suspect this would be aligned with the link device, but any input
you may have on this would be useful.

Eyal.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ