On Feb 2, 2014, at 10:02 PM, Dobbins, Roland <rdobb...@arbor.net> wrote:
> > On Feb 3, 2014, at 12:45 PM, Michael DeMan <na...@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 <rdobb...@arbor.net> // <http://www.arbornetworks.com> > > Luck is the residue of opportunity and design. > > -- John Milton > >
