Re: TWC (AS11351) blocking all NTP?

[Michael DeMan <nanog () deman com>]

On Feb 2, 2014, at 10:02 PM, Dobbins, Roland <rdobbins () arbor net> wrote:

> On Feb 3, 2014, at 12:45 PM, Michael DeMan <nanog () deman com> wrote:
>
> > From a provider point of view, given the choices between contacting the end-users vs. mitigating the problem, if I 
> > were in TW position if I was unable to immediately contact the numerous downstream customers that were affected by 
> > this, I would take the option to block NTP on a case-by-case basis (perhaps even taking a broad brush) rather than 
> > allow it to continue and cause disruptions elsewhere.
>
> Per my previous post in this thread, there are ways to do this without blocking client access to ntp servers; in 
> point of fact, unless the ISP in question isn't performing antispoofing at their customer aggregation edge, blocking 
> client access to ntp servers does nothing to address (pardon the pun) the issue of ntp reflection/amplification DDoS 
> attacks.
Agreed, and I was not trying to get into arguments about saying whether 'blocking' is appropriate or not.  I was simply 
suggesting that a provider, if they found themselves in a position where this was causing lots of troubles and 
impacting things in a large, might have had taken a 'broad brush' approach to stabilize things while they work on a 
more proper solution.

> All that broadband access operators need to do is to a) enforce antispoofing as close to their customers as possible, 
> and b) enforce their AUPs (most broadband operators prohibit operating servers) by blocking *inbound* UDP/123 traffic 
> towards their customers at the customer aggregation edge (same for DNS, chargen, and SNMP).
I certainly would not want to provide as part the AUP (as seller or buyer), a policy that fundamentals like NTP are 
'blocked' to customers.  Seems like too much of a slippery slope for my taste.

In regards to anti-spoofing measures - I think there a couple of vectors about the latest NTP attack where more 
rigorous client-side anti-spoofing could help but will not solve it overall.  Trying to be fair and practical (from my 
perspective) - it is a lot easier and quicker to patch/workaround IPv4 problems and address proper solutions via IPv6 
and associated RFCs?

- Michael DeMan



> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins () arbor net> // <http://www.arbornetworks.com>
>
>         Luck is the residue of opportunity and design.
>
>                      -- John Milton