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.
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:
The principal advantages of this solution are:
The drawbacks are:
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:
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:
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):
|General Terms and Conditions
effective as of 01.09.2009, amended as of 01.12.2010, 01.05.2011 and 01.01.2019
|Service Level Agreement
effective as of 01.09.2009
|General Terms and Conditions Multicast Carrier
effective as of 01.04.2011, amended as of 01.01.2019
|Multicast Receiver Order Form
|Multicast Source Order Form
|General Terms and Conditions for providing Transparent Ethernet Interconnect
|Transparent Ethernet Interconnect Order Form
|Information Security Policy Declaration
|Certificate ISO/IEC 27001:2013