netdev - recursive static routes

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-next>] [day] [month] [year] [list]

Message-ID: <CAAeewD_-s32D9GJEyV_06LPmkXLk1s9stspiY0Xrrn81PyhGgg@mail.gmail.com>
Date:   Mon, 19 Mar 2018 09:42:29 +0200
From:   Saku Ytti <saku@...i.fi>
To:     netdev@...r.kernel.org
Subject: recursive static routes

I believe Linux does not support recursive static routes, is this correct?

If so, do we not see the use-case or is it just lacking quality
implementation which would be accepted if such is presented?

Just to elaborate on one use case. Consider your Linux host has two
BGP upstreams, you advertise your loopback/32 prefix and you receive
something. Let's say you at least receive 192.0.2.0/24 from both BGP
sessions.
Now you probably would like to do something like

'ip route add 0.0.0.0/0 via 192.0.2.0 src lo'

But this won't work, as we do not recurse 192.0.2.0 to where ever it
may point at any given time.

Why would you do this, instead of receive 0.0.0.0/0 from upstream? For
one, you can set the 'src' parameter. And another, typical upstream
generates 0.0.0.0/0 locally, so even if upstream device is isolated
from network, it will continue to advertise 0.0.0.0/0 and blackhole
your traffic. If you choose your prefix towards which you
default-route, you can choose something which is more representative
of functioning Internet from your POV.

This is typical feature supported by IOS, IOS-XE, IOS-XR, JunOS, SROS,
VRP and so forth. Some of them support it by standard without any
additional toggle, another, like JunOS requires that you define
specifically which static routes are recursed, in JunOS the keyword
used is 'resolve'. But commonly the functionality is known as
'recurse', so if iproute2 were to need verb for this, 'recurse' would
be preferred over 'resolve'.

-- 
  ++ytti