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: [email protected])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
diff --git a/filter/filter.c b/filter/filter.c
index d784c25..98bae33 100644
--- a/filter/filter.c
+++ b/filter/filter.c
@@ -853,10 +853,29 @@ interpret(struct f_inst *what)
f_rta_cow();
{
struct rta *rta = (*f_rte)->attrs;
+ ip_addr ip;
+
switch (what->aux) {
case T_IP:
- * (ip_addr *) ((char *) rta + what->a2.i) = v1.val.px.ip;
+ ip = v1.val.px.ip;
+
+ /* "gw" attribute? */
+ if (what->a2.i == OFFSETOF(struct rta, gw))
+ {
+ neighbor *n = neigh_find(rta->proto, &ip, 0);
+ if (!n || (n->scope == SCOPE_HOST))
+ runtime( "Invalid gw address" );
+
+ rta->dest = RTD_ROUTER;
+ rta->gw = ip;
+ rta->iface = n->iface;
+ rta->nexthops = NULL;
+ rta->hostentry = NULL;
+ }
+ else /* or "from" attribute? */
+ rta->from = ip;
+
break;
case T_ENUM_SCOPE:
