DDoS Mitigation

We have developed a few solutions (In-line Classification & QoS, DDoS Packet Stamp и Blackholing) to support the Members of the Public peering in case of potential Volumetric DDoS attacks aimed at their networks.

1. In-line Classification & QoS

Our main goal is to reduce the possibility of losing useful traffic in case of a DDoS attack.

The technical implementation is as follows:
On Input: Classification
Each packet is analysed in real time according to a set of multiple complex rules. In case the packet resembles some of the known DDoS attacks, it moves into a special queue (DDoS Queue).

On Output: QoS
Several queues with different priorities are set up at the output of each port. The principle is as follows: Multicast traffic is served with highest priority, followed by useful peering traffic and finally - the DDoS queue. The result is that:

• in the absence of a DDoS attack (or in the presence of a small one), when the port capacity is large enough to carry all of the traffic, all queues are served and there is no loss of any packets;
• in the case of a large DDoS attack, when the traffic that tries to go through the port becomes larger than the capacity of the port itself (i.e. packet loss is inevitable), multicast traffic and useful peering are served without loss (because they have higher priority) and the DDoS queue serves only a fraction of the traffic (depending on how much free capacity remains in the port).

The principal advantages of this solution are:

• it is continuously active and will respond immediately in case of a DDoS attack i.e. no time is lost to identify the attack, reroute the traffic, etc.;
• it is the same for all Members of the Public peering no matter the speed at which they are connected.

The drawbacks are:

• it cannot guarantee with absolute certainty that all types of attacks will be recognised, especially when it comes to new attack types (Zero-day DDoS Attack);
• there is a minimal possibility that some useful traffic can be classified in the DDoS Queue but this is irrelevant when there is no attack towards the Member and it’s port has enough capacity to carry the traffic.

2. DDoS Packet Stamp

Our primary aim is to provide a convenient mechanism for Members to learn which part of the traffic has been classified as a potential DDoS attack and in case they decide so, to be able to easily apply additional restrictive rules on their networks to this traffic.

In this regard, all packages which have been classified as a DDoS attack are marked at the output towards the Members according to IEEE P802.1p with Priority Code Point (PCP) = 1.

We DO NOT recommend Members to drop/filter all of the marked traffic because it may also contain useful traffic classified as DDoS.

A reasonable approach, for example, could be:

• to collect statistical information for the maximum volume of the marked traffic in case of regular traffic (absence of a DDoS attacks) for a longer period of time;
• if possible, to set a rate limit on the marked traffic that is 10-fold greater (than the maximum volume on regular traffic on the first device on which the connection to BIX.BG is terminated);
• to observe permanently for packet drops (when the traffic is regular) and if needed to change the rate limit value.

3. Blackholing (BGP community 65535:666)

The possibility to block the traffic towards a specific prefix (IP address or network) by signaling with a BGP4 announcement through the already established sessions with the Route Servers (RS).
The functionality refers only to the traffic via VLAN for Public peering.
RS accept prefixes tagged with BLACKHOLE (BH) community 65535:666 with the following prefix length restrictions:

• IPv4: /25 and larger (up to /32);
• IPv6: /49 and larger (up to /128).

Route Servers do not re-distribute prefixes tagged with BH to the other Members. A BH announcement to any of the RS is sufficient.

Within 2 seconds of receiving a valid BH announcement BIX.BG blocks the entire traffic with a Destination IP address/es with the received BGP prefix at the output towards the Member (i.e. at the input from the Member’s point of view). In case the Member has more than one connection for Public peering, the blocking will be applied to all of its connections. 

We want to emphasize that traffic blocking takes place within the BIX.BG network at the output towards the Member’s network, which has the following major differences compared to the traditional implementation in most IXPs (block at the input via manipulation of the routing of the BH prefix):

• the Members who do not want to use the Blackholing feature don’t need to change anything in their setup;
• the Members who use Blackholing do not depend on the readiness of others to accept their BH announcements;
• there is no risk of blocking traffic as a result of a BH announcement received by another Member (in most implementations blocking is at the input and when two Members have the right to announce the same network there is a real risk; for instance, if one member announces /32 with BH, this can lead to a traffic block to this destination for all Members);
• Blackholing works in same way no matter whether the routing between Members is accomplished via Route Servers or a private BGP session.