Arbor Networks reported that there DDoS attacks in 2014 has 8 times compared to 2012
It has been reported that 71% of the data centers have had a DDoS attack
In 2013, BGP prefix hijacking affected 1,500 prefixes, in 150 cities
Some cases involved Live interception attacks for more than 60 days
In this time period,Traffic from major companies, government, ISPs were diverted
The best locations for diagnosis and mitigation are often far from the victim . But the problem is that the victim cannot observe nor control traffic and routes at these locations .
For example, in Reflector Attack, public servers see spoofed requests but do not know/care that they are spoofed and the victim has a challenge to separate legitimate from attack traffic.
SENSS - software-defined security service is a framework that enables a victim network to request services from remote ISPs for traffic that carries source IPs or destination IPs from this net work's address space. These services range from statistics gathering, to filtering or quality of service guarantees, to route reports or modifications. The SENSS service has very simple, yet powerful, interfaces. This enables it to handle a variety of data plane and control plane attacks, while being easily implementable in today's ISP. Through extensive evaluations on realistic traffic traces and Internet topology, we show how SENSS can be used to quickly, safely and effectively mitigate a variety of large-scale attacks that are largely unhandled today.
What does SENSS offer to the Victim?
SENSS enables the victim to observe and control traffic. The victim for example , can request the SENSS server about flows which carry either the source or the destination IPs from the Victim's prefix. The SENSS server will reply to the victim about the flow volume which is generated , recieved or sent for that particular requested flow. Similarly the victim can request the SENSS server to filter or allow a particular flow for a certain amount of time.
SENSS enables the victim to observe and control routes. The victim can request the SENSS server about its AS path to the victim's prefix. The victim can also request the SENSS server to demote a particular path if the path contains a specific AS segment, or to modify a path from one segement to the other.
The victim can use the responses from traffic and route observation to detect an attack. After detection, the attack can be mitigated using the traffic and route control.
How does SENSS work?
Victims will identify the ISP's which run the SENSS server by using the public SENSS directory.
Victim's interact with the SENSS server in the form of queries. In order for the SENSS server to verify the ownership of prefixes , the victim is required to attach its ROA certificate. After authenticating the victim, the SENSS server process's the request , charges the victim and returns the replies.
Victim processes the replies from the server and decides on the control actions which needs to applied. The victim sends request to the chosen ISP where the control messages have to be executed. The ISP authenticates the victim , charges the victim and implements the requested action.
We demonstrate the SENSS to detect a direct flood with signature attacks under two scenarios.
This demo consists of a 120 node AS level topology emulated on Deterlab. SENSS client at LBMC contantly fingerprints its traffic by using traffic_query commands. In this demo we use 880 attack and 240 legitimate traffic sources. There are two rounds of attack -- during the first, SENSS CLIENT at LBMC is able to send out add_filter message to the SENSS server at ARNEP and during the second round of larger attacks, SENSS client delegates its control over to the SENSS proxy at ICN, as its not able to communicate with any of the SENSS servers. The proxy at ICN then sends add_filter messages to SENSS servers at ARPNET and EQUINIX.
0.8 Tbps attack
This demo consists of 13 servers with Netronome Agilio NICs which generates 40Gbps--80Gbps of attack traffic (a cumulative attack of 0.8Tbps) towards the SENSS client. Four of these servers send a mix of both legitimate and attack traffic. SENSS client constantly fingerprints its traffic by issuing the traffic_query request to all 13 SENSS servers. Using the derived traffic fingerprint of its own legitimate traffic, the SENSS client can recognise when its under a large attack and issue a add_filter messages to the SENSS servers.
We evaluated the performance of SENSS using realistic legitimate attack traffic mined from a month's worth data of RouteViews.From this we concluded that.
Adopters have higher benefits. Early adopters can mitigate 100% of the DDoS with signature and reflector attacks
As the adoption grows the protection grows for everyone in terms of effectiveness and the range of attacks which are mitigated
Deployement at any tier helps
Most of the attacks can be mitigated with deployement at just 1-2% of all the ASes with under ten second delay