On Mon, Feb 3, 2014 at 12:42 PM, Peter Phaal <peter.ph...@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) > 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. > https://datatracker.ietf.org/doc/draft-krishnan-i2rs-large-flow-use-case/ > http://events.linuxfoundation.org/sites/events/files/slides/flow-aware-real-time-sdn-analytics-odl-summit-v2.pdf > > 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 :( > > 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? > 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. > Vendors are adding new SDN capabilities to their platforms (often as > software upgraded), so it's worth taking a look and seeing what is > possible. the device side is PROBABLY the simple side of the equation for most people... > > On Sun, Feb 2, 2014 at 7:38 PM, Larry Sheldon <larryshel...@cox.net> wrote: >> On 2/2/2014 9:17 PM, ryang...@gmail.com wrote: >>> >>> I'd hate to think that NetOps would be so heavy handed in blocking >>> all of UDP, as this would essentially halt quite a bit of audio/video >>> traffic. That being said, there's still quite the need for protocol >>> improvement when making use of UDP, but blocking UDP as a whole is >>> definitely not a resolution, and simply creating a wall that not only >>> keeps the abusive traffic out, but keeps legitimate traffic from >>> flowing freely as it should. >> >> >> "We had to burn down the village to save it." >> >> >> -- >> Requiescas in pace o email Two identifying characteristics >> of System Administrators: >> Ex turpi causa non oritur actio Infallibility, and the ability to >> learn from their mistakes. >> (Adapted from Stephen Pinker) >> >