Traffic diversion with SDN – Part 3: The Brain

Until now, we have taken it for granted that the OpenFlow switches have preprogramed flows and that the routing daemon on the injector knows what to announce. We will now cover how this happened.

There are two input values we need. First, the IP under attack (red traffic) and second the temporary IP we want to use (blue traffic). The attacked IP will be provided by the DDoS Mitigation Analysis platform, the temporary IP can be freely chosen from available address in your network. It can be either a public IP address, private (RFC1918) address or even one from the Documentation Range (RFC 5737). It will only be used inside your network and not visible to the outside world.

Figure 5 shows what happens next. A small cli script takes the two IP address described above as input, creates a configuration file for the routing daemon and reloads the daemon. The other needed information (next-hops to use for red and blue traffic) are static and preconfigured in the script and the network already knows about those.

In addition to that a second set of actions is performed. The cli Script uses Rest API Calls to program Flows to the OpenFlow Switches. We are using the Opendaylight SDN Controller in this example to provide the translation between API Calls and OpenFlow commands. The needed information to program the flow is ony again static and preconfigured in the script (which ports to use, which MAC addresses to rewrite) or are provided by the scripts parameters (red and blue IP).

Screen-Shot-2016-01-13-at-14.39.46_550_

After running the script all device in the network know what they need to do and traffic will be OFF- and On-Ramped correctly.

Life of a Packet

Figure 6 gives an overview of the Packet Flow and the destination IP at each stage of the packets flow through the network. In this case, the temporary (blue) IP 10.10.10.10 has been chosen.

Real World Check

This solution is implemented and tested in Xantaros XT³Lab using open vSwitch on Virtual Machines acting as the OpenFlow Switch.

Unfortunately, not many vendors have implemented the needed OpenFlow Actions to rewrite the destination IP addresses of Packets yet so the choice of hardware is currently limited.

As the needed Port Count is quite low, we are currently investigating the performance of using standard x86 Hardware to perform the forwarding using open vSwitch. Frameworks like Intel DPDK have already proven that Off the Shelf x86 Hardware can be capable of forwarding multiple 10Gbit/s of traffic.

In addition to that, vendors have already begun to integrate OpenFlow Capabilities into their Core Routing Platforms and may be capable of providing the needed actions and features directly on that platform in the near future. This would lead to a possibility to collapse the OpenFlow Switches back into the existing network if is feasible.

Takeaways

What Xantaro did to provide this solution was taking existing building blocks from the open source community (Open Daylight SDN Controller, Bird Routing Daemon, Open vSwitch) as well as products from various vendors (OpenFlow capable switches, DDoS Mitigation appliances, existing Routers) and by applying some glue (scripting, using APIs) created a service to tackle a real world challenge.

Furthermore, while everybody is talking about how SDN and OpenFlow might change their network in the future Xantaro provided a solution where the existing network can coexist with SDN without the need to redo the complete network.