Re: TWC (AS11351) blocking all NTP?

[Christopher Morrow <morrowc.lists () gmail com>]

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)

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