On Mon, Feb 3, 2014 at 10:16 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Feb 3, 2014 at 12:42 PM, Peter Phaal <peter.phaal@gmail.com> wrote:
Why burn the village when only one house is the problem? I thought there might be some interest in hearing about work being done to use SDN to automatically configure filtering in existing switches and routers to mitigate flood attacks.
that's great... who's got sdn capable gear in deployments today? with code and OSS stuff to deal with random SDN pokery? and who has spare tcam/etc to deal with said pokery of 'block the attack-du-jour' ?
There's certainly the case that you could drop acls/something on equipment to selectively block the traffic that matters... I suspect in some cases the choice was: "50% of the edge box customers on this location are a problem, block it across the board here instead of X00 times" (see concern about tcam/etc problems)
I agree that managing limited TCAM space is critical to the scaleability of any mitigation solution. However, tying up TCAM space on every edge device with filters to prevent each new threat is likely to be less scaleable than a measurement driven control that only takes a TCAM slot on a device when an active attack is detected transiting that device.
Real-time analytics based on measurements from switches/routers (sFlow/PSAMP/IPFIX) can identify large UDP flows and integrated hybrid OpenFlow, I2RS, REST, NETCONF APIs, etc. can be used to program the switches/routers to selectively filter traffic based on UDP port and IP source / destination. By deploying a DDoS mitigation SDN application, providers can use their existing infrastructure to protect their own and their customers networks from flood attacks, and generate additional revenue by delivering flood protection as a value added service.
yup, that sounds wonderous... and I'm sure that in the future utopian world (like 7-10 years from now, based on age-out of gear and OSS IT change requirements) we'll see more of this. I don't think you'll see much (in terms of edge ports on the network today) of this happening 'right now' though.
The current 10G upgrade cycle provides an opportunity to deploy equipment that is SDN capable. The functionality required for this use case is supported by current generation merchant silicon and is widely available right now in inexpensive switches.
Specifically looking at sFlow, large flood attacks can be detected within a second. The following article describes a simple example using integrated hybrid OpenFlow in a 10/40G ToR switch:
hopefully there's some clamp on how much change per device/port you plan too? :) I'd hate to see the RP/RE/etc get so busy programming tcam that bgp/isis/ospf/etc flaps :(
With integrated hybrid OpenFlow, there is very little activity on the OpenFlow control plane. The normal BGP, ECMP, LAG, etc. control planes handles forwarding of packets. OpenFlow is only used to selectively override specific FIB entries. I2RS provides a similar capability to selectively override RIB entries and implement controls. However, I don't know if any vendors are shipping I2RS capable routers today. Typical networks probably only see a few DDoS attacks an hour at the most, so pushing a few rules an hour to mitigate them should have little impact on the switch control plane. A good working definition of a large flow is 10% of a link's bandwidth. If you only trigger actions for large flows then in the worst case you would only require 10 rules per port to change how these flows are treated.
http://blog.sflow.com/2014/01/physical-switch-hybrid-openflow-example.html
The example can be modified to target NTP mon_getlist requests and responses using the following sFlow-RT flow definition:
{'ipdestination,udpsourceport',value:'ntppvtbytes',filter:'ntppvtreq=20,42'}
or to target DNS ANY requests:
{keys:'ipdestination,udpsourceport',value:'frames',filter:'dnsqr=true&dnsqtype=255'}
this also assume almost 1:1 sampling... which might not be feasible either...otherwise you'll be seeing fairly lossy results, right?
Actually, to detect large flows (defined as 10% of link bandwidth) within a second, you would only require the following sampling rates: 1G link, sampling rate = 1-in-1,000 (large flow >= 100M bit/s) 10G link, sampling rate = 1-in-10,000 (large flow >= 1G bit/s) 40G link, sampling rate = 1-in-40,000 (large flow >= 4G bit/s 100G link, sampling rate = 1-in-100,000 (large flow >= 10G bit/s) These sampling rates are realistically achievable in production networks (enabling monitoring on all ports) and would allow you to detect the specific IP destination and UDP source port associated with a flood attack, and the switches in the attack path, within a second.
The OpenFlow block control can be modified to selectively filter UDP traffic based on the identified UDP source port and destination IP address.
hopefully your OSS and netflow/sflow collection isn't also being used for traffic engineering/capacity planning purposes? else... you might get odd results from that infrastructure with such changes to the sflow/netflow sender platform.
This use case might be more problematic for NetFlow since obtaining the measurements may affect the router configuration (flow cache definitions) and other applications that depend on them (like capacity planning). In the case of sFlow monitoring, the flow cache is built externally and you can feed the sFlow to multiple independent analysis tools without risk of interference. http://blog.sflow.com/2013/05/software-defined-analytics.html