TWC (AS11351) blocking all NTP?

Mon Feb 3 18:16:41 UTC 2014

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)

> 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 <LarrySheldon at cox.net> wrote:
>> On 2/2/2014 9:17 PM, ryangard at 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)
>>
>