Blackholing Service

Blackholing service is a protection mechanism against Denial Of Service attacks increasingly seen on the Internet today.

This feature is available only for Route Servers peers. However, all members can design and configure their own mechanisms on their bilateral peering relations.

We make use of RFC 7999 community 65535:666 at our service implementation. Any of our servers will skip prefix validation and will automatically rewrite the BGP NH Attribute pointing to one of the blackholing machines existent on both LANs:

LX-LAN1: 193.136.250.66 | 2001:7F8:A:1::666
LX-LAN2: 193.136.251.60 | 2001:7F8:A:2::1060

As a service demonstration, we’re designing a situation where peer A detects an abnormal amount of traffic aimed at one of its machines.

Automatically or with any kind of manual setup, peer A can force a new BGP update to announce a more specific route (even /32) marked with the aforementioned BH community.

The new prefix will then by analysed by our RSs. The community will signal the servers to skip prefix length validation while rewriting the NEXT-HOP attribute for a well-know machine. Besides keeping this community, our servers will also add the well-known “no-export” standard community as a best practice rule.

Without any other community control, all other ASNs will receive the new BGP route and will adjust their forwarding tables according to their routing policies.

If the prefix is accepted, all traffic will be directed at our machine and we will ensure to drop it on our infrastructure before reaching PEER-A network.

All the other export control mechanisms using communities can be applied for the original purposes. This way a peer can block DoS attacks at an ASN level and still keep legitimate traffic flowing.

For all this to work, all members should have a BGP configuration to detect blackholing community from RSs sessions and to accept network shorter than /24 or /64.