It is well understood that today’s business critical applications rely heavily on highly functional and available network services.

So how do you observe the health of your network services while under a significant DDoS attack, let alone mitigate such an attack?

It should all start with having a reliable method of observing the state of your network at any given time. Here I will make a case for using a well-known industry standard for traffic monitoring, namely sFlow. sFlow is short for ‘sampled flow’ and has been around for a couple of decades. You can find more details here: http://www.sflow.org.

Once the ability to observe the nature and amount of traffic traversing the network resources has been established, it becomes critical to continuously ensure this ability is maintained through the torrents of DDoS attack type traffic from the ever present hordes of Internet bots.

This accessibility requirement may have seemed more trivial in the days of ASIC based switching and routing hardware devices. Back then routers were hardware and software inseparable monolithic devices, provided exclusively by companies like Cisco, Juniper et al.

With today’s wider adoption of Virtual Network Functions (VNFs) and the need for deployment flexibility and OPEX savings, care should be taken so that any virtualized router (vRouter) has the proper control and data plane architecture.

A good vRouter implementation has a separate control plane with some guaranteed core cycles and NIC bandwidth, ensuring operational control for route diversions and the like all while the data-path pipe is fully saturated by, for instance, millions of small malicious UDP packets.

Once you have gathered a picture of the amount and nature of the traffic, the next step should be to mitigate the attack by re-directing traffic to a ‘black-hole’, i.e. the traffic is silently dropped or alternatively re-directed to a dedicated system for further analysis and mitigation.

Several companies provide excellent traffic analysis and mitigation devices for analyzing and cleaning network traffic. An example is Arbor Networks’ TMS and APS devices. You can read more here: https://www.arbornetworks.com.

Summarizing the above:

• Select a traffic monitoring capability that provides insight into your network. A good example is to configure sFlow on your routers.
• Ensure that these routers have the capability to provide traffic monitoring continuously even under heavy load. This is in particular crucial when running in a virtualized environment using vRouters.
• Determine a mitigation strategy. Black-hole the offending traffic or re-direct it to a dedicated device that can further analyze and mitigate any attack (route-redistribution, traffic-filtering, etc.).

Let’s explore further.

1.) Traffic monitoring

6WIND’s vRouter implements sFlow v5, which for instance supports BGP communities.

The sFlow standard provides a network-wide view of active routes and network interface usage. It enables many interfaces to be monitored from a single location.

This single location operates as an sFlow collector, fed with UDP Datagrams from sFlow agents.

The sFlow agents should generally be critical network devices such as routers and switches.

Each agent must be configured with an IP address and UDP port of the collector (multiple collectors can be specified).

Polling and sampling rates can be specified uniquely for each agent. It is often bandwidth dependent with bandwidths varying from 1Gb up to 100Gb per port.

Finally, specify what interfaces should be monitored; it is often desirable to omit any management interfaces.

A configuration example (can use the 6WIND CLI or Linux):

sflow {

polling = 5  # sec

sampling = 16  # power 2 for performance reasons

collector { ip=10.1.0.1 udpport=6343 } // sflow datagram destination

collector { ip=192.168.0.7 udpport=6343 } // Another destination

pcap { dev = eth1 } // Collect information from these NIC ports …

pcap { dev = eth2 }

pcap { dev = eth3 }

}

2.) Reachability

Having selected the 6WIND vRouter, there is a guarantee that the control path, i.e. the ability to make SNMP inquiries, inject re-direct routes, obtain sFlow datagrams and such is responsive while the data path is processing data at bandwidth.

The 6WIND control path has a dedicated CPU core that is independent of servicing network traffic directly from the NIC ports. This ensures a high degree of operability and reachability under DDoS attacks. This architecture is based on open source DPDK (Data Plane Development Kit) which 6WIND has contributed greatly to over the years.

Additionally, the 6WIND routers are user configurable with the ability to fine-tune control path protection to avoid control packet loss. This is quite important when the data-path is capable of processing up towards 12Mpps per core!

3.) Mitigation

Once a DDoS attack has started the combination of sFlow and SNMP packets flowing to the monitoring station, this should indicate that an attack is underway and counter measures can be taken. Simple black-holing of the victims’ IP addresses is a simple way of at least protecting the victim from further attacks. The downside is obviously that the DDoS attack has succeeded in bringing down the victim.

A better approach is to re-inject routes to a Threat Management System for analysis and filtering of the packets. This should result in the victim still receiving valid traffic while avoiding the malicious packets.

So putting it all together, let me finish with an interesting real-world deployment of a network that emulates a DDoS attack including attackers, victims, core routers and traffic mitigation systems.

An example: Security Test Network

As one of the leading DDoS Detection and Mitigation companies, Arbor Networks has for years run a Security Training Network. As DDoS attacks increase in frequency and intensity it has been vital for their training networks to keep up with these ever increasing attack volumes.

To emulate DDoS attacks with many attackers, victims, routers and threat mitigation systems, it becomes fairly cost prohibitive to deploy such a scenario with bare-metal equipment. As such Arbor chose to implement a virtualized solution.

In the example below, there are around 100 vRouters acting as attackers and victims, and core routers can be deployed along with their mitigation devices.

The “attacking” vRouters in the top of the diagram route the incoming malicious traffic towards core router 1. The core vRouter sends the traffic to the “victim” vRouters.

Once the sFlow datagrams sent to the collector indicate overwhelming traffic, often small 64 byte UDP packets, the mitigation system injects BGP routes to the core vRouters to re-divert traffic to Arbor’s TMS devices.

Other routes are re-injected via GRE tunnels to Arbor’s APS devices in order to make the victim systems available again.

Operational control and visibility into the network is maintained throughout the attack.

This was just one example of how using 6WIND’s sFlow functionality can provide insight into and provide better uptime for your network.

Stay tuned for a future blog about our upcoming flowSpec implementation.

Jes Nielsen is a Solution Engineer for 6WIND.