netdev - Re: [PATCH net-next] vrf: local route leaking

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 27 May 2019 09:34:02 +0100
From:   George Wilkie <gwilkie@...tta.att-mail.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Shrijeet Mukherjee <shrijeet@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next] vrf: local route leaking

On Sat, May 25, 2019 at 09:13:13AM -0600, David Ahern wrote:
> > Using a loopback doesn't work, e.g. if 10.1.1.0/24 was on a global interface:
> >    ip ro add vrf vrf-a 10.1.1.0/24 dev lo
> 
> That works for MPLS when you exit the LSP and deliver locally, so it
> should work here as well. I'll take a look early next week.

OK, thanks.

> I would prefer to avoid it if possible. VRF route leaking for forwarding
> does not have the second lookup and that is the primary use case. VRL
> with local delivery is a 1-off use case and you could just easily argue
> that the connection should not rely on the leaked route. ie., the
> control plane is aware of both VRFs, and the userspace process could use
> the VRF-B path.
> 

Although it isn't always possible to change the userspace process -
may be running in a specific vrf by 'ip vrf exec'