How about this - I have proposed to NIST we start filtering - realize
that the NIST ITS program itself was setup to run NTP in an open access
mode - we host a dozen or so of those systems and so we get hit all the
time.
The solution is actually not running timing services across UDP because
of the hand shaking over the open Internet - and that obviously isnt
going to happen.
My suggestion is that for those that need access we set up VLAN trunked
private networking models to your ISP MPOE as it were in a digital context.
If this interests you contact me off list.
Todd Glassey - USTiming.ORG
On 2/2/2014 7: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.
Sent on the TELUS Mobility network with BlackBerry
-----Original Message-----
From: Cb B <cb.li...@gmail.com>
Date: Sun, 2 Feb 2014 15:09:55
To: Matthew Petach<mpet...@netflight.com>
Cc: <nanog@nanog.org>
Subject: Re: TWC (AS11351) blocking all NTP?
On Feb 2, 2014 2:54 PM, "Matthew Petach" <mpet...@netflight.com> wrote:
On Sun, Feb 2, 2014 at 2:17 PM, Cb B <cb.li...@gmail.com> wrote:
On Feb 2, 2014 8:35 AM, "Jonathan Towne" <jto...@slic.com> wrote:
The provider has kindly acknowledged that there is an issue, and are
working on a resolution. Heads up, it may be more than just my
region.
And not just your provider, everyone is dealing with UDP amp attacks.
These UDP based amp attacks are off the charts. Wholesale blocking of
traffic at the protocol level to mitigate 10s to 100s of gigs of ddos
traffic is not "knee jerk", it is the right thing to do in a world where
bcp 38 is far from universal and open dns servers, ntp, chargen, and
whatever udp 172 is run wild.
People who run networks know what it takes to restore service. And
increasingly, that will be clamping ipv4 UDP in the plumbing, both
reactively and proactively.
Please note that it's not that UDP is at fault here; it's
applications that are structured to respond to small
input packets with large responses.
I dont want to go into fault, there is plenty of that to go around.
If NTP responded to a single query with a single
equivalently sized response, its effectiveness as
a DDoS attack would be zero; with zero amplification,
the volume of attack traffic would be exactly equivalent
to the volume of spoofed traffic the originator could
send out in the first place.
I agree the source obfuscation aspect of UDP can be
annoying, from the spoofing perspective, but that
really needs to be recognized to be separate from
the volume amplification aspect, which is an application
level issue, not a protocol level issue.
Source obfuscation is not annoying. Combined with amplification, it is the
perfect storm for shutting down networks... whereby the only solution is to
shutdown ipv4 udp. Or wave the magic wand that makes bcp38 universal,
patches boxes, and so on.
My point is: dont expect these abbused services on UDP to last. We have
experience in access networks on how to deal with abused protocols. Here is
one reference
http://customer.comcast.com/help-and-support/internet/list-of-blocked-ports/
My crystal ball says all of UDP will show up soon.
CB
Thanks!
Matt
PS--yes, I know it would completely change the
dynamics of the internet as we know it today to
shift to a 1:1 correspondence between input
requests and output replies...but it *would*
have a nice side effect of balancing out traffic
ratios in many places, altering the settlement
landscape in the process. ;)
--
-------------
Personal Email - Disclaimers Apply
