BGP remote-triggered blackhole (RTBH) filter for Juniper

Question

I'm trying to find the most elegant way to implement a RTBH filter for routes received from a customer.

The filter should:

1. Only accept the customers own prefixes from a prefix-list
2. Only accept /32 prefixes
3. Only prefixes with the blackhole community
4. Set the next-hop to the RTBH next-hop (192.0.2.1)

To begin I looked at the "Configuring Match Conditions in Routing Policy Terms" document from Juniper.

First I thought about combining a prefix-list-filter to only match routes from the customers prefix-list and a route-filter to limit the accepted prefixes to /32, like so:

from {
    as-path customer;
    community blackhole;
    prefix-list-filter customer-prefixes orlonger;
    route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}

But then I stumbled about this information in the document:

If you configure a policy that includes some combination of route filters, prefix lists, and source address filters, they are evaluated according to a logical OR operation or a longest-route match lookup.

As I understand this (and I find it a bit unclear), if I use prefix-list-filter, route-filter and/or source-address-filter in the same term it would be evaluated with a longest-match OR between all of them, which makes this approach unusable.

What I came up with is this the following filter. The hostroutes-only term diverts all prefixes shorter than /32 to the next policy. After that the prefixes term matches if the /32 is in the range of the customer, matches his as-path and has the blackhole community set:

term hostroutes-only {
    from {
        route-filter 0.0.0.0/0 prefix-length-range /0-/31;
    }
    then next policy;
}
term prefixes {
    from {
        as-path customer;
        community blackhole;
        prefix-list-filter customer-prefixes orlonger;
    }
    then {
        next-hop 192.0.2.1;
        accept;
    }
}

So, is this the most elegant way to handle this? Any other solutions?

Answer 1

There is no reason to limit customer to blackhole only /32, allow them to blackhole anything from them.

Something like this:

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            prefix-list-filter AS42 orlonger;
        }
        then {
            community add NO-EXPORT;
            next-hop 192.0.2.1;
            accept;
        }
    }
    term advertise {
        from {
            prefix-list AS42;
        }
        then {
            community add ADVERTISE;
            next-hop peer-address;
            accept;
        }
    }
    term reject {
        then reject;
    }
}

Remember to set 'accept-remote-nexthop' under BGP settings, so that the next-hop can be changed to something else than link address.

I also strongly support that providers start to support different blackhole communities than just 'full blackhole'. Especially if you operate in more than one country usually attack is from transit and often customer actually mostly wants to access domestic peerings, so it's useful to implement several levels of blackhhole:

1. Full
2. Outside local country (local IXP, whole own AS + customers seen)
3. Outside local area (if applicable, like for me it could be 'Nordics')
4. Include/Exclude specific peering router in blackhole

I'm happy to give example how to implement something like this with JNPR DCU/SCU, provided your peering routers are JNPR, but it's possible with just communities, just bit more awkward.

---

If you absolutely want to limit your customer's options you can add this:

policy-statement /32 {
    term /32 {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /32-/32;
        }
        then accept;
    }
    term reject {
        then reject;
    }
}

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            policy /32;
            prefix-list-filter AS42 orlonger;
        }
..
}

This way it should be logical AND. But I really don't see the value in creating complexity to reduce expressiveness of configuration.

Answer 2

It's been a while, but here is a point to consider related to the accept-remote-nexthop.

Assuming that there is an import policy on the customer peer changing the next-hop, the accept-remote-nexthop will permit prefixes with any next hop, making this to be "open" for certain types of attacks.

Not sure about a workaround. Maybe adding another statement under the policy to accept only the actual customer next-hop is the way to go then. The other thing is that it seems that the accept-remote-nexthop is not possible with eBGP multi-hop.