"gw" attribute assignment in filter invalidates routes learned via BGP, static, and possibly others?

[Ondrej Zajicek]

On Tue, Aug 13, 2013 at 01:57:48PM +0300, Sergey Popovich wrote:
> Hello!
> 
> Another issue I spot last time:
>   assigning value in protocol export filter
>   invalidates route and prevents its from being
>   installed in KRT.

Yes, this is a known issue. Works just for setting gw on the same iface.

> ---------------------------------------------------------------------------------------
> This is probably due to not updating iface, nexthops (multihop config) and
> other fields of "rta" struct.
> 
> Provided patch in attachment tries to address this issue by calling 
> rta_set_recursive_next_hop() in filter/filter.c to properly assign to "gw"
> attribute. Special cases for bgp and static protocols was taken to use
> "igp table" configuration parameter if present (tested, and found working
> with static protocol, probably some with bgp).

The patch does not make sense to me - if user sets 'gw' attribute, BIRD
should set immediate nexthop of the route, not setup a route with a
recursive nexthop - that would be inconsistent, because reading of 'gw'
attribute returns the immediate nexhop and not the recursive nexthop of
a route.

The attached patch should do that (essentially just lookup iface,
fix it and force the route to RTD_ROUTER in case of setting 'gw').
Is this OK for you?

> ---------------------------------------------------------------------------------------
> Brief explanation why "gw" attribute might be wery important (at least
> in my case).
> 
> There is common technique to stop DDoS in large ISP network:
>   blackholing.
> 
> However implementations of this might wary from vendor to vendor.
> In BIRD simplest way to implement this is to set "dest" attribute to something
> like RTD_BLACKHOLE, and all other route attributes gets deleted (gw, iface, 
> ...). Route installed in KRT as blackhole.

...

> 
> In this case we setup some system looped back interface (in Linux this is
> dummy interface type), configure some network on it (say something 
> 192.0.2.0/24), And instead of setting blackholed route type to RTD_BLACKHOLE
> we change its "gw" to any address within subnet assigned on looped back
> interface.
> 
> Thats servers same as route with blackhole type, but behaves differently on 
> trace paths: router sends ICMP Time To Live Exceeded messages from its
> incoming interface address indicating last hop before dropping blackholed 
> traffic. This has no impact on DDoS traffic, except it transmitted to
> looped back interface instead of being dropped immediately after matching 
> route and wasting few CPU cycles.

Thanks for the thorough explanation. I am surprised that route to a Linux
dummy interface works like that, i always thought that dummy interface
would behave more like an ethernet with nothing connected on it than
like a loopback (therefore you would get ICMP Destination unreachable
instead of TTL exceeded), but i didn't tested that.

And why not just use RTD_UNREACHABLE or RTD_PROHIBIT? Both would return
some ICMP message.


-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: set_gw.patch
Type: text/x-diff
Size: 821 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20130813/8804adc4/attachment-0001.patch>