Don't fight it.
It's clear that implementation on a per-packet basis of RFC4824 (datagrams
over Semaphore Flag Signaling System) would have prevented this entire
situation.
Refer to sections 3.3 and 3.4.
-j
On Mon, Feb 3, 2014 at 12:23 PM, Paul Ferguson fergdawgs...@mykolab.com
wrote:
On
On Feb 4, 2014, at 8:52 AM, William Herrin b...@herrin.us wrote:
On Tue, Feb 4, 2014 at 11:23 AM, Jared Mauch ja...@puck.nether.net wrote:
On Feb 4, 2014, at 11:04 AM, William Herrin b...@herrin.us wrote:
If just three of the transit-free networks rewrote their peering
contracts such that
On (2014-02-05 00:29 -), John Levine wrote:
Why does it have to be hard? Restricting the filter to addresses which
(A) the customer asserts are theirs
How does the customer do that in a way that scales?
I don't think any of this is rocket science, but it apparently is a
real block to
On Feb 5, 2014, at 3:35 AM, Saku Ytti s...@ytti.fi wrote:
If what you say was actual reason, it could be solved by logging ACL.
We the community, could produce tooling to automate this in few popular
platforms. Automatically builds the ACL, web interface for humans to classify
the
On (2014-02-05 11:15 -0500), Jared Mauch wrote:
The problem is many of these can compile to larger than the physical amount
of space in the router/LC have to handle it. I’ve done presentations to
vendors about what percentage (in bytes and per-line) of the configuration is
of what
: Livingood, Jason [mailto:jason_living...@cable.comcast.com]
Sent: Tuesday, February 04, 2014 6:53 PM
To: Octavio Alvarez; North American Network Operators' Group
Subject: Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
On 2/4/14, 7:48 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote:
What I'm
To: Octavio Alvarez; North American Network Operators' Group
Subject: Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
On 2/4/14, 7:48 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote:
What I'm failing to understand, and again, please excuse me if I'm
oversimplifying, is what data do you
- Original Message -
From: Octavio Alvarez alvar...@alvarezp.ods.org
Maybe I'm oversimplifying things but I'm really curious to know why
can't the nearest-to-end-user ACL-enabled router simply have an ACL to
only allows packets from end-users that has a valid source-address
from the
On 2/5/14, 1:24 PM, Jay Ashworth wrote:
- Original Message -
From: Octavio Alvarez alvar...@alvarezp.ods.org
Maybe I'm oversimplifying things but I'm really curious to know why
can't the nearest-to-end-user ACL-enabled router simply have an ACL to
only allows packets from end-users
On 2/5/14, 13:24, Jay Ashworth wrote:
The common answer, Octavio, at least*used to* be our line cards aren't
smart enough to implement strict-unicast-RPF, and our boxes don't have
enough horsepower to handle every packet through the CPU.
As I've noted, I'm not sure I believe that's true of
On Wednesday, February 05, 2014 11:24:42 PM Jay Ashworth
wrote:
As I've noted, I'm not sure I believe that's true of
current generation gear, and if it *is*, then it should
cost manufacturers business.
But only matters if you're refreshing or just starting out.
A lot of operators have a
Sure. Part of the data collection task. Making sure all the current new gear
knows how, still a good idea.
On February 5, 2014 11:32:26 PM EST, Mark Tinka mark.ti...@seacom.mu wrote:
On Wednesday, February 05, 2014 11:24:42 PM Jay Ashworth
wrote:
As I've noted, I'm not sure I believe that's
On Thursday, February 06, 2014 06:34:16 AM Jay Ashworth
wrote:
Sure. Part of the data collection task. Making sure all
the current new gear knows how, still a good idea.
Yep - like Joel said; current kit supports it (well, the
ones I buy, anyway), and certainly a good idea for operators
I'm going to be somewhat of a pain in everybody's ass this year, pounding on
the drum whenever the topic pops up. :-)
On February 5, 2014 11:38:08 PM EST, Mark Tinka mark.ti...@seacom.mu wrote:
On Thursday, February 06, 2014 06:34:16 AM Jay Ashworth
wrote:
Sure. Part of the data collection
On 2/5/2014 1:20 PM, Christopher Morrow wrote:
I here tell the spoofer project people are looking to improve their data
and stats... And reporting.
I know it's not possible due to the limitations of javascript
sandboxing, but this really needs to be browser based so it can be like
DNSSEC or
On the contrary, I encourage all competitors to block protocols
indiscriminately, especially ipv4 UDP. Nothing bad could ever come of that!
-Blake
On Tue, Feb 4, 2014 at 12:29 AM, Doug Barton do...@dougbarton.us wrote:
On 02/03/2014 05:10 PM, Majdi S. Abbas wrote:
NTP works best
On Sun, Feb 2, 2014 at 5:17 PM, Cb B cb.li...@gmail.com wrote:
And, i agree bcp38 would help but that was published 14 years ago.
Howdy,
If just three of the transit-free networks rewrote their peering
contracts such that there was a $10k per day penalty for sending
packets with source
On Feb 4, 2014, at 11:04 AM, William Herrin b...@herrin.us wrote:
On Sun, Feb 2, 2014 at 5:17 PM, Cb B cb.li...@gmail.com wrote:
And, i agree bcp38 would help but that was published 14 years ago.
Howdy,
If just three of the transit-free networks rewrote their peering
contracts such that
On Tue, Feb 4, 2014 at 11:23 AM, Jared Mauch ja...@puck.nether.net wrote:
On Feb 4, 2014, at 11:04 AM, William Herrin b...@herrin.us wrote:
If just three of the transit-free networks rewrote their peering
contracts such that there was a $10k per day penalty for sending
packets with source
On Feb 4, 2014, at 11:52 AM, William Herrin b...@herrin.us wrote:
Those that are up in arms about this stuff seem to not be the ones asking
the vendors for features and fixes.
Like I said, the tier 1's can't be the source of the solution until
they stop being part of the problem.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2/4/2014 10:03 AM, Jared Mauch wrote:
Ask your vendors for these features. Ask them to fix the bugs. The
ball rolls uphill here and it's in their lap. Blaming the carriers
is wrongheaded and putting it where it doesn't belong in many
cases.
Why not just provide a public API that lets users specify which of your
customers they want to null route? It would save operators the trouble of
having to detect the flows.. and you can sell premium access that allows the
API user to null route all your other customers at once.
Once everyone
On Tue, 04 Feb 2014 10:09:02 -0800, Paul Ferguson said:
I'd like to echo Jared's sentiment here -- collectively speaking,
service providers need to figure out a way to deal with this issue,
before some congresscritters start to try to introduce legislation
that will force you to to do it in a
On Tue, Feb 4, 2014 at 1:45 PM, Laszlo Hanyecz las...@heliacal.net wrote:
Why not just provide a public API that lets users specify which
of your customers they want to null route?
They're spoofed packets. There's no way for anyone outside your AS to
know which of your customers the packets
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2/4/2014 10:47 AM, valdis.kletni...@vt.edu wrote:
On Tue, 04 Feb 2014 10:09:02 -0800, Paul Ferguson said:
I'd like to echo Jared's sentiment here -- collectively
speaking, service providers need to figure out a way to deal with
this issue,
On Tue, Feb 4, 2014 at 1:52 PM, William Herrin b...@herrin.us wrote:
On Tue, Feb 4, 2014 at 1:45 PM, Laszlo Hanyecz las...@heliacal.net wrote:
Why not just provide a public API that lets users specify which
of your customers they want to null route?
They're spoofed packets. There's no way for
On Tue, Feb 4, 2014 at 1:03 PM, Jared Mauch ja...@puck.nether.net wrote:
On Feb 4, 2014, at 11:52 AM, William Herrin b...@herrin.us wrote:
Those that are up in arms about this stuff seem to not be the ones asking
the vendors for features and fixes.
Like I said, the tier 1's can't be the
I was joking, I meant that the operator provides an API for attackers, so they
can accomplish their goal of taking the customer offline, without having to
spoof or flood or whatever else. Automatically installing ACLs in response to
observed flows accomplishes almost the same thing. As a
On Tue, Feb 4, 2014 at 2:01 PM, Laszlo Hanyecz las...@heliacal.net wrote:
I was joking,
And I was being a tad obtuse. My apoligies.
Regards,
Bill Herrin
--
William D. Herrin her...@dirtside.com b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
On 02/04/2014 08:04 AM, William Herrin wrote:
On Sun, Feb 2, 2014 at 5:17 PM, Cb B cb.li...@gmail.com wrote:
And, i agree bcp38 would help but that was published 14 years ago.
Howdy,
If just three of the transit-free networks rewrote their peering
contracts such that there was a $10k per day
Please let us know your results.
Jared Mauch
On Feb 4, 2014, at 1:55 PM, William Herrin b...@herrin.us wrote:
On Tue, Feb 4, 2014 at 1:03 PM, Jared Mauch ja...@puck.nether.net wrote:
On Feb 4, 2014, at 11:52 AM, William Herrin b...@herrin.us wrote:
Those that are up in arms about this
- Original Message -
From: Jared Mauch ja...@puck.nether.net
Ask your vendors for these features. Ask them to fix the bugs. The
ball rolls uphill here and it's in their lap. Blaming the carriers is
wrongheaded and putting it where it doesn't belong in many cases.
Happy to discuss
On Tue, Feb 4, 2014 at 2:08 PM, Doug Barton do...@dougbarton.us wrote:
On 02/04/2014 08:04 AM, William Herrin wrote:
If just three of the transit-free networks rewrote their peering
contracts such that there was a $10k per day penalty for sending
packets with source addresses the peer should
- Original Message -
From: Valdis Kletnieks valdis.kletni...@vt.edu
Can somebody explain to me why those who run eyeball networks are able
to block outbound packets when the customer hasn't paid their bill,
but can't seem to block packets that shouldn't be coming from that
On Tue, Feb 4, 2014 at 2:28 PM, William Herrin b...@herrin.us wrote:
On Tue, Feb 4, 2014 at 2:08 PM, Doug Barton do...@dougbarton.us wrote:
On 02/04/2014 08:04 AM, William Herrin wrote:
If just three of the transit-free networks rewrote their peering
contracts such that there was a $10k per
On Tue, Feb 04, 2014 at 02:28:22PM -0500, William Herrin wrote:
Verizon Business is willing to do settlement-free peering with you but
you won't agree to a reciprocal penalty if either allows its customers
to forge packets? I call that a weed-out factor. Weed out the bad
actors because anyone
On Tue, Feb 4, 2014 at 2:48 PM, Majdi S. Abbas m...@latt.net wrote:
Are you willing to warrant the source, destination and lawful
purpose of every single frame exiting your network?
Yes, no and no respectively. As a BGP leaf node, I can guarantee that
no packets leave my network from a
On Tue, 4 Feb 2014, valdis.kletni...@vt.edu wrote:
On Tue, 04 Feb 2014 10:09:02 -0800, Paul Ferguson said:
I'd like to echo Jared's sentiment here -- collectively speaking,
service providers need to figure out a way to deal with this issue,
before some congresscritters start to try to
On Tue, Feb 4, 2014 at 1:47 PM, valdis.kletni...@vt.edu wrote:
Can somebody explain to me why those who run eyeball networks are able
to block outbound packets when the customer hasn't paid their bill,
but can't seem to block packets that shouldn't be coming from that
cablemodem?
The
If just three of the transit-free networks rewrote their peering
contracts such that there was a $10k per day penalty for sending
packets with source addresses the peer should reasonably have known
were forged, this problem would go away in a matter of weeks.
Won't work because no one will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2/4/2014 2:18 PM, John Levine wrote:
If just three of the transit-free networks rewrote their
peering contracts such that there was a $10k per day penalty
for sending packets with source addresses the peer should
reasonably have known were
On Tue, Feb 04, 2014 at 10:18:21PM -, John Levine wrote:
I was at a conference with people from some Very Large ISPs. They
told me that many of their large customers absolutely will not let
them do BCP38 filtering. (If you don't want our business, we can
find someone else who does.) The
On Tue, Feb 4, 2014 at 5:18 PM, John Levine jo...@iecc.com wrote:
I was at a conference with people from some Very Large ISPs. They
told me that many of their large customers absolutely will not let
them do BCP38 filtering. (If you don't want our business, we can
find someone else who does.)
-
We block all outbound UDP for our ~200,000 Users for this very reason
(with the exception of some whitelisted NTP and DNS servers). So far
we have had 0 complaints
-
Because those that might complain switched providers when their
On 04/02/14 14:18, John Levine wrote:
I was at a conference with people from some Very Large ISPs. They
told me that many of their large customers absolutely will not let
them do BCP38 filtering. (If you don't want our business, we can
find someone else who does.) The usual problem is that
Can somebody explain to me why those who run eyeball networks are able
to block outbound packets when the customer hasn't paid their bill,
but can't seem to block packets that shouldn't be coming from that
cablemodem?
i suspect the non-payment case is solved at a layer below three
randy
If ISP has customer A with multiple *known* valid networks --doesn't matter
if ISP allocated them to customer or not-- and ISP lets them all out, but
filters everything else, ISP is still complying with BCP 38.
Of course. The question is how the ISP knows what the customer's address
ranges
In message 52f17102.2000...@alvarezp.ods.org, Octavio Alvarez writes:
On 04/02/14 14:18, John Levine wrote:
I was at a conference with people from some Very Large ISPs. They
told me that many of their large customers absolutely will not let
them do BCP38 filtering. (If you don't want our
On Tue, Feb 4, 2014 at 6:24 PM, John R. Levine jo...@iecc.com wrote:
If ISP has customer A with multiple *known* valid networks --doesn't
matter if ISP allocated them to customer or not-- and ISP lets them all out,
but filters everything else, ISP is still complying with BCP 38.
Of course.
On 04/02/14 15:24, John R. Levine wrote:
If ISP has customer A with multiple *known* valid networks --doesn't
matter if ISP allocated them to customer or not-- and ISP lets them
all out, but filters everything else, ISP is still complying with BCP 38.
Of course. The question is how the ISP
Why does it have to be hard? Restricting the filter to addresses which
(A) the customer asserts are theirs
How does the customer do that in a way that scales?
I don't think any of this is rocket science, but it apparently is a
real block to BCP38/84 implementatin.
R's,
John
Can somebody explain to me why those who run eyeball networks are able
to block outbound packets when the customer hasn't paid their bill,
but can't seem to block packets that shouldn't be coming from that
cablemodem?
i suspect the non-payment case is solved at a layer below three
In a DOCSIS
In message 20140205002905.57856.qm...@joyce.lan, John Levine writes:
Why does it have to be hard? Restricting the filter to addresses which
(A) the customer asserts are theirs
How does the customer do that in a way that scales?
You implement SIDR to the extent where you issue your multi
On 04/02/14 16:31, Livingood, Jason wrote:
Can somebody explain to me why those who run eyeball networks are able
to block outbound packets when the customer hasn't paid their bill,
but can't seem to block packets that shouldn't be coming from that
cablemodem?
i suspect the non-payment case is
On 2/4/14, 7:48 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote:
What I'm failing to understand, and again, please excuse me if I'm
oversimplifying, is what data do you need from researchers,
specifically. What specific actionable data would be helpful? Why does
the lack of the data prevent
- Original Message -
From: John Levine jo...@iecc.com
Subject: Re: BCP38 is hard, was TWC (AS11351) blocking all NTP?
Why does it have to be hard? Restricting the filter to addresses
which
(A) the customer asserts are theirs
How does the customer do that in a way that scales?
I
How does the customer do that in a way that scales?
You implement SIDR to the extent where you issue your multi homed
customers CERTs for the address space you allocated to them. The
customer can then just send signed requests to a automated service
at the other ISPs along with the CERT
Hi,
I think I might have already deleted subject matter a few days ago in re: BCP38.
What exactly are you trying to do?
I agree my general comment about the recent NTP weaknesses should be addressed
via IPv6 RFC may have been mis-understood.
I meant mostly that with IPv6 NAT goes away, all
On Feb 3, 2014, at 3:24 PM, Michael DeMan na...@deman.com wrote:
I meant mostly that with IPv6 NAT goes away,
I don't know if this is true or not - and even if it is true, it's going to be
a long, long time before the IPv4 Internet goes away (like, maybe, pretty much
forever, heh).
An
On Sun, Feb 02, 2014 at 02:49:49PM -0800,
Matthew Petach mpet...@netflight.com wrote
a message of 49 lines which said:
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
On Mon, Feb 03, 2014 at 04:09:39AM +,
Dobbins, Roland rdobb...@arbor.net wrote
a message of 20 lines which said:
I also think that restricting your users by default to your own
recursive DNS servers, plus a couple of well-known, well-run public
recursive services, is a good idea - as
On Feb 3, 2014, at 4:55 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
I agree with you but I'm fairly certain that most ISP who deny their users
the ability to do DNS requests directly
(or to run their own DNS resolver) have no such opt-out (or they make it
expensive and/or
On Mon, 03 Feb 2014 00:24:08 -0800, Michael DeMan said:
An NTPv5 solution that could be done with NTP services already
Doesn't matter - the same people that aren't upgrading to a correctly
configured NTPv4 aren't going to upgrade to an NTPv5. No need at all
for a protocol increment (and
...@gmail.com
Date: Sun, 2 Feb 2014 15:09:55
To: Matthew 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
On Mon, 03 Feb 2014 06:14:30 -0800, TGLASSEY said:
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.
That's going to be one big VLAN.
/me makes popcorn.
pgp0cVq4AACgv.pgp
Description: PGP
Or a whole bunch of small ones Vladis - and yes we are capable of
handling the loads.
:-)
Todd
On 2/3/2014 6:34 AM, valdis.kletni...@vt.edu wrote:
On Mon, 03 Feb 2014 06:14:30 -0800, TGLASSEY said:
My suggestion is that for those that need access we set up VLAN trunked
private networking
On Mon, 03 Feb 2014 06:50:56 -0800, TGLASSEY said:
Or a whole bunch of small ones Vladis - and yes we are capable of
handling the loads.
38,917 vlans later...
/me makes even *more* popcorn...
pgphM_JWCrh3v.pgp
Description: PGP signature
On 2/3/14, 1:02 AM, Dobbins, Roland rdobb...@arbor.net wrote:
All that broadband access operators need to do is to a) enforce
antispoofing as close to their customers as possible,
Many probably do so already. But as well all know, it only takes a few
that don¹t to create a large scale issue.
Why burn the village when only one house is the problem? I thought
there might be some interest in hearing about work being done to use
SDN to automatically configure filtering in existing switches and
routers to mitigate flood attacks.
Real-time analytics based on measurements from
On Mon, Feb 3, 2014 at 12:42 PM, Peter Phaal peter.ph...@gmail.com wrote:
Why burn the village when only one house is the problem? I thought
there might be some interest in hearing about work being done to use
SDN to automatically configure filtering in existing switches and
routers to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2/2/2014 2:17 PM, Cb B wrote:
And, i agree bcp38 would help but that was published 14 years ago.
But what? Are you somehow implying that because BCP38 was
...published 14 years ago (RFC2267 was initially published in 1998,
and it was
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.
Most NTP servers only send legitimate traffic to a handful of masters,
often in the ntp.org pool, and to
On 03 Feb 2014 18:23:31 +, John Levine said:
It seems thata hosts sending large amounts of NTP traffic over the
public Internet can be safely filtered if you don't already know that
it's one of the handful that's in the ntp.org pools or another well
known NTP master.
You have that
On Feb 3, 2014, at 12:45 AM, Michael DeMan na...@deman.com wrote:
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
B cb.li...@gmail.com
Date: Sun, 2 Feb 2014 15:09:55
To: Matthew 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
On Feb 4, 2014, at 12:42 AM, Peter Phaal peter.ph...@gmail.com wrote:
Real-time analytics based on measurements from switches/routers
(sFlow/PSAMP/IPFIX) can identify large UDP flows and integrated hybrid
OpenFlow, I2RS, REST, NETCONF APIs, etc. can be used to program the
switches/routers
It seems thata hosts sending large amounts of NTP traffic over the
public Internet can be safely filtered if you don't already know that
it's one of the handful that's in the ntp.org pools or another well
known NTP master.
Speaking as one of the 3841 servers in the pool.ntp.org pool, I'm
On Mon, Feb 3, 2014 at 10:16 AM, Christopher Morrow
morrowc.li...@gmail.com wrote:
On Mon, Feb 3, 2014 at 12:42 PM, Peter Phaal peter.ph...@gmail.com wrote:
Why burn the village when only one house is the problem? I thought
there might be some interest in hearing about work being done to use
On Feb 4, 2014, at 12:11 AM, Brian Rak b...@gameservers.com wrote:
You can disable these quite easily, and still run a NTP server that provides
accurate time services.
Concur 100% - although it should be noted that 1:1 reflection without any
amplification is also quite useful to attackers.
On 2/3/2014 2:46 PM, Dobbins, Roland wrote:
On Feb 4, 2014, at 12:11 AM, Brian Rak b...@gameservers.com wrote:
You can disable these quite easily, and still run a NTP server that provides
accurate time services.
Concur 100% - although it should be noted that 1:1 reflection without any
On Feb 4, 2014, at 3:09 AM, Brian Rak b...@gameservers.com wrote:
It's pretty much the same issue with DNS, even authoritative-only servers can
be abused for reflection.
They are, every minute of every day - and they provide amplification, too.
;
It seems thata hosts sending large amounts of NTP traffic over the
public Internet can be safely filtered if you don't already know that
it's one of the handful that's in the ntp.org pools or another well
known NTP master.
Speaking as one of the 3841 servers in the pool.ntp.org pool, I'm happy
On Mon, Feb 3, 2014 at 2:42 PM, Peter Phaal peter.ph...@gmail.com wrote:
On Mon, Feb 3, 2014 at 10:16 AM, Christopher Morrow
morrowc.li...@gmail.com wrote:
On Mon, Feb 3, 2014 at 12:42 PM, Peter Phaal peter.ph...@gmail.com wrote:
There's certainly the case that you could drop acls/something
On Feb 3, 2014, at 3:29 PM, John R. Levine jo...@iecc.com wrote:
It seems thata hosts sending large amounts of NTP traffic over the
public Internet can be safely filtered if you don't already know that
it's one of the handful that's in the ntp.org pools or another well
known NTP master.
I was thinking that the ntp.org servers on any particular network are a small
set of exceptions to a general rule to rate limit outgoing NTP traffic.
www.pool.ntp.org allows any NTP operator to opt-in to receive NTP traffic
should their clock be available and accurate.
I believe you, but I
I was thinking that the ntp.org servers on any particular network are a
small set of exceptions to a general rule to rate limit outgoing NTP
traffic.
www.pool.ntp.org allows any NTP operator to opt-in to receive NTP traffic
should their clock be available and accurate.
I believe
On Mon, 03 Feb 2014 11:29:21 -0600, Joe Greco said:
There's a bootstrap issue here. I'm guessing that you may be picturing
a scenario where a network operator simply queries to obtain the list of
ntp.org servers and special-cases their own. However, I believe that
the system won't add NTP
On 02/03/2014 12:50 PM, John R. Levine wrote:
I was thinking that the ntp.org servers on any particular network are
a small set of exceptions to a general rule to rate limit outgoing
NTP traffic.
www.pool.ntp.org allows any NTP operator to opt-in to receive NTP
traffic should their clock be
On Mon, Feb 3, 2014 at 12:38 PM, Christopher Morrow
morrowc.li...@gmail.com wrote:
On Mon, Feb 3, 2014 at 2:42 PM, Peter Phaal peter.ph...@gmail.com wrote:
On Mon, Feb 3, 2014 at 10:16 AM, Christopher Morrow
morrowc.li...@gmail.com wrote:
On Mon, Feb 3, 2014 at 12:42 PM, Peter Phaal
On Mon, 03 Feb 2014 16:49:37 +1300
Geraint Jones gera...@koding.com wrote:
We block all outbound UDP for our ~200,000 Users for this very reason
(with the exception of some whitelisted NTP and DNS servers). So far
we have had 0 complaints
I've heard this sort of absence of complaint statement
On Mon, 3 Feb 2014 07:08:25 +
Dobbins, Roland rdobb...@arbor.net wrote:
There's nothing in IPv6 which makes any difference. The ultimate
solution is antispoofing at the customer edge.
There is at least one small thing that may change some part of this and
similar problems. If the threat
On Feb 4, 2014, at 5:38 AM, John Kristoff j...@cymru.com wrote:
I do realize in practice there are ways to discover systems, but the change
in address architecture could change things, not perfectly, but I'll venture
to suggest noticeably in some not so difficult to imagine
scenarios.
I
wait, so the whole of the thread is about stopping participants in the
attack, and you're suggesting that removing/changing end-system
switch/routing gear and doing something more complex than:
deny udp any 123 any
deny udp any 123 any 123
permit ip any any
is a good plan?
I'd direct you
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
switch/routing gear and doing something more complex than:
deny udp any 123 any
On Mon, Feb 3, 2014 at 2:58 PM, 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
switch/routing gear and doing something more complex than:
deny udp any 123
On Mon, Feb 03, 2014 at 03:50:03PM -0500, John R. Levine wrote:
I believe you, but I don't believe that the set of ntp.org servers
changes so rapidly that it is beyond the ability of network
operators to handle the ones on their own networks as a special
case.
I think you'd be
On Feb 3, 2014 10:23 AM, Paul Ferguson fergdawgs...@mykolab.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2/2/2014 2:17 PM, Cb B wrote:
And, i agree bcp38 would help but that was published 14 years ago.
But what? Are you somehow implying that because BCP38 was
On Mon, Feb 3, 2014 at 7:40 PM, Glen Turner g...@gdt.id.au wrote:
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
switch/routing
-larry directly since I'm sure he's either tired of this, or already
reading it via the nanog subscription.
On Mon, Feb 3, 2014 at 7:54 PM, Peter Phaal peter.ph...@gmail.com wrote:
On Mon, Feb 3, 2014 at 2:58 PM, Christopher Morrow
morrowc.li...@gmail.com wrote:
wait, so the whole of the
- Original Message -
From: Cb B cb.li...@gmail.com
I completely agree. My sphere of influence is bcp38 compliant. And,
networks that fail to support some form of bcp38 are nothing short of
negligent.
That said, i spend too much time taking defensive action against ipv4 amp
udp
1 - 100 of 120 matches
Mail list logo
