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] [day] [month] [year] [list]
Message-ID: <CAHsH6GviZudwDHwG-JDqGapzVP95spY1=J+5xM2GX_711L+DWA@mail.gmail.com>
Date:   Thu, 25 Aug 2022 16:03:05 +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

On Thu, Aug 25, 2022 at 1:07 PM Nicolas Dichtel
<nicolas.dichtel@...nd.com> wrote:
>
>
> Le 24/08/2022 à 20:56, Eyal Birger a écrit :
> > 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.
> Yes.
>
> >
> > 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.
> The link is not used in the rx path, only in the tx path to perform the route
> lookup in the right vrf. You can assign the input iface to the link device, but
> the if_id should be enough to identify the tunnel.

Thanks. I tested this in the context of VRF and it works well.

I'll include it in v2.

Eyal.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ