TWC (AS11351) blocking all NTP?

Mon Feb 3 19:42:17 UTC 2014

On Mon, Feb 3, 2014 at 10:16 AM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Mon, Feb 3, 2014 at 12:42 PM, Peter Phaal <peter.phaal at 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