[GTER] BlackHole no IX.BR

Rubens Kuhl rubensk at gmail.com
Tue Jan 7 14:00:22 -03 2020


Hi Job.

Comments inline.


On Tue, Jan 7, 2020 at 1:16 PM Job Snijders <job at ntt.net> wrote:

> Dear all,
>
> The idea to use a route server to distribute requests for blackholing is
> not new and has been tried in a few places (such as DE-CIX), but there
> are some obstacles in operating such a mechanism securely.
>
> A) How do you prevent people from requesting blackholes for IP space
> that is not theirs? We know that normal BGP filtering already is a
> challenge, so introducing a mechanism which can be easily abused is
> tricky.
>

The two simpler ways to do this is to require the BH to be either from the
Brazilian IP space of the member AS (which would cover cases for end-user
and content networks, just not transit networks) or to be RPKI-valid (which
would cover non-Brazilian networks and transit networks regardless of
origin).


> B) Another downside of the 'distribute blackholes via route server'
> model is that it requires *EVERY* participant to implement custom
> routing policy to honor the blackhole requests. I am not sure it is
> reasonable to expect hundreds of participants to update their router
> configurations for this purpose. And until everyone updated their
> configurations, the blackhole mechanism will be ineffective (yet still
> dangerous, see point A!).
>

This is a downside, but this has an upside too: this can be used to trickle
both down and up the BH, so it can be dropped closer to its entry point,
either an internal aggregator or a border router.


>
> So with the above in mind, I would like to suggest an alternative
> approach:
>
> ALTERNATIVE APPROACH: implement blackholing inside the IXP fabric
>

This doesn't have to be mutually exclusive with BH announcements. The IXP
can both blackhole inside the fabric traffic that ends up getting to it,
and pass on the announcements.
This allows each member to drop before sending to the fabric, which for
members that hire long-haul circuits to connect to the IX can make a whole
lot of difference.

Even the Layer 2 reseller ports (called CIX in IX.br) can do such filtering
and prevent using their transport networks. The BH announcements could have
a defined IP address in the IX subnet with a defined MAC address, allowing
anyone in the middle to know that this traffic is going to be dropped
anyways.


Rubens


More information about the gter mailing list