TWC (AS11351) blocking all NTP?

Mon Feb 3 17:11:47 UTC 2014

Huh?  The issue with NTP relates to the monlist command (and a few 
others).  These are management queries, and are not critical to the 
operation of a NTP server.  You can disable these quite easily, and 
still run a NTP server that provides accurate time services.

On 2/3/2014 9:14 AM, TGLASSEY wrote:
> 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, 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.
>> Sent on the TELUS Mobility network with BlackBerry
>>
>> -----Original Message-----
>> From: Cb B <cb.list6 at gmail.com>
>> Date: Sun, 2 Feb 2014 15:09:55
>> To: Matthew Petach<mpetach at netflight.com>
>> Cc: <nanog at nanog.org>
>> Subject: Re: TWC (AS11351) blocking all NTP?
>>
>> On Feb 2, 2014 2:54 PM, "Matthew Petach" <mpetach at netflight.com> wrote:
>>> On Sun, Feb 2, 2014 at 2:17 PM, Cb B <cb.list6 at gmail.com> wrote:
>>>
>>>> On Feb 2, 2014 8:35 AM, "Jonathan Towne" <jtowne at 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.  ;)
>