[168668] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: TWC (AS11351) blocking all NTP?

daemon@ATHENA.MIT.EDU (Dobbins, Roland)
Mon Feb 3 01:02:54 2014

From: "Dobbins, Roland" <rdobbins@arbor.net>
To: "nanog@nanog.org list" <nanog@nanog.org>
Date: Mon, 3 Feb 2014 06:02:18 +0000
In-Reply-To: <D553A35E-AF58-47D9-9A5B-A225616A6041@deman.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


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 e=
nd-users vs. mitigating the problem, if I were in TW position if I was unab=
le to immediately contact the numerous downstream customers that were affec=
ted 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 cau=
se disruptions elsewhere.

Per my previous post in this thread, there are ways to do this without bloc=
king client access to ntp servers; in point of fact, unless the ISP in ques=
tion isn't performing antispoofing at their customer aggregation edge, bloc=
king client access to ntp servers does nothing to address (pardon the pun) =
the issue of ntp reflection/amplification DDoS attacks.

All that broadband access operators need to do is to a) enforce antispoofin=
g as close to their customers as possible, and b) enforce their AUPs (most =
broadband operators prohibit operating servers) by blocking *inbound* UDP/1=
23 traffic towards their customers at the customer aggregation edge (same f=
or DNS, chargen, and SNMP).

-----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



home help back first fref pref prev next nref lref last post