- Original Message -
From: Glen Turner g...@gdt.id.au
On 4 Feb 2014, at 9:28 am, Christopher Morrow
morrowc.li...@gmail.com wrote:
wait, so the whole of the thread is about stopping participants in
the attack, and you're suggesting that removing/changing end-system
On 02/03/2014 05:10 PM, Majdi S. Abbas wrote:
NTP works best with a diverse set of peers. You know, outside
your little bubble, or walled garden, or whatever people in this thread
appear to be trying to build. I'm not sure what to call it, but it's
definitely not the Internet.
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
While I do not profess to know the cause of your particular NTP sync
problem, this *might* be due to knee-jerk reactions to the NTP
reflection/amplification DDoS attacks that have been quite an
annoyance and operational issue lately. suspect that
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.
-- Jonathan Towne
On Sat, Feb 01, 2014 at 11:03:19PM -0500, Jonathan Towne scribbled:
# This evening all of my servers lost NTP sync, stating that our
In article 20140202163313.gf24...@hijacked.us you write:
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.
I'm a Time-Warner cable customer in the Syracuse region, and both of
the NTP servers on my home LAN
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
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
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
Petachmpet...@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
On 2/2/2014 9: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
On Feb 2, 2014 7:41 PM, Larry Sheldon larryshel...@cox.net wrote:
On 2/2/2014 9: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
On 3/02/14 4:45 pm, Cb B cb.li...@gmail.com wrote:
On Feb 2, 2014 7:41 PM, Larry Sheldon larryshel...@cox.net wrote:
On 2/2/2014 9: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
On Feb 3, 2014, at 10:49 AM, Geraint Jones gera...@koding.com wrote:
We block all outbound UDP for our ~200,000 Users for this very reason
Actually, you could've (and should've) been far more selective in what you
filtered via ACLs, IMHO.
What about your users who play online games like BF4?
On Feb 3, 2014, at 10:58 AM, Dobbins, Roland rdobb...@arbor.net wrote:
I'm a big believer in using ACLs to intelligently preclude
reflection/amplification abuse, but wholesale filtering of all UDP takes
matters too far, IMHO.
I also think that restricting your users by default to your own
The recently publicized mechanism to leverage NTP servers for amplified DoS
attacks is seriously effective.
I had a friend who had a local ISP affected by this Thursday and also another
case where just two asterisk servers saturated a 100mbps link to the point of
unusability.
Once more - this
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
On Feb 3, 2014, at 1:02 PM, Dobbins, Roland rdobb...@arbor.net wrote:
b) enforce their AUPs (most broadband operators prohibit operating servers)
by blocking *inbound* UDP/123 traffic towards their customers at the customer
aggregation edge
Actually, this can cause problems for ntpds
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
On Feb 3, 2014, at 1:54 PM, Michael DeMan na...@deman.com wrote:
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.
The idea is to block traffic
This evening all of my servers lost NTP sync, stating that our on-site NTP
servers hadn't synced in too long.
Reference time noted by the local NTP servers:
Fri, Jan 31 2014 19:11:29.725
Apparently since then, NTP has been unable to traverse the circuit. Our
other provider is shuffling NTP
101 - 120 of 120 matches
Mail list logo
