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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20190525070924.GA1184@debian10.local>
Date:   Sat, 25 May 2019 08:09:24 +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 Fri, May 24, 2019 at 02:19:45PM -0600, David Ahern wrote:
> I think this codifies the use case:
>   ip li add vrf-a up type vrf table 1
>   ip route add vrf vrf-a unreachable default
>   ip li add vrf-b up type vrf table 2
>   ip route add vrf vrf-b unreachable default
>   ip ru add pref 32765 from all lookup local
>   ip ru del pref 0
> 
>   ip netns add foo
>   ip li add veth1 type veth peer name veth11 netns foo
>   ip addr add dev veth1 10.1.1.1/24
>   ip li set veth1 vrf vrf-b up
>   ip -netns foo li set veth11 up
>   ip -netns foo addr add dev veth11 10.1.1.11/24
>   ip -netns foo ro add 10.1.2.0/24 via 10.1.1.1
> 
>   ip netns add bar
>   ip li add veth2 type veth peer name veth12 netns bar
>   ip li set veth2 vrf vrf-a up
>   ip addr add dev veth2 10.1.2.1/24
>   ip -netns bar li set veth12 up
>   ip -netns bar addr add dev veth12 10.1.2.12/24

Although I'm not using namespaces:
   ip link add vrfA type vrf table 256
   ip link set dev vrfA up
   ip route add table 256 unreachable default metric 4278198272
   ip link set dev ens4 master vrfA
   ip address add 10.10.2.9/24 dev ens4
   ip link set dev ens4 up

   ip link add vrfB type vrf table 257
   ip link set dev vrfB up
   ip route add table 257 unreachable default metric 4278198272
   ip link set dev ens5 master vrfB
   ip address add 10.10.3.9/24 dev ens5
   ip link set dev ens5 up

> 
> If you do route leaking this way:
>   ip ro add vrf vrf-b 10.1.2.0/24 dev veth2
>   ip ro add vrf vrf-a 10.1.1.0/24 dev veth1
> 
> yes, you hit problems trying to connect to a local address.
> 
> If you do route leaking this way:
>   ip ro add vrf vrf-b 10.1.2.0/24 dev vrf-a
>   ip ro add vrf vrf-a 10.1.1.0/24 dev vrf-b
> 
> you do not.
> 

That was my initial thought, although it needs a 2nd lookup.
The problem I hit though was I couldn't figure out how to make it work
when leaking from global into a VRF. I couldn't see how to indicate
a lookup in the global table.  Is there a way to do this?
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

It seemed if something new was needed, leaking the locals was neater approach?

Thanks.