[ Bunch of replies to messages in thread bundled here. ]
On Tue, Apr 21, 2020 at 06:28:48PM -0400, Bryan Fields wrote:
> It's a mailman list, so nanog-ow...@nanog.org should work. If not reach out
> to the communications committee.
All mailing lists should support that, regardless of what's runn
On 4/23/20 6:43 AM, John Osmon wrote:
On Wed, Apr 22, 2020 at 08:05:39AM +0300, Töma Gavrichenkov wrote:
On Wed, Apr 22, 2020, 12:45 AM Randy Bush wrote:
sad. http://nanog.org used to be the brilliant example of a fully
featured web site sans javascript, flash, ...
That was long ago now
[ Apologies if you've seen this already - jtk ]
Friends,
Those of you with knowledge, interest, or deployment experience with
IP multicast in real networks should consider taking the survey linked
to below. Forwarded with knowledge and permission of the original email
author.
The survey deadline
Hello all,
I would appreciate if someone from Comcast could contact me about this.
We’re having serious throughput issues with our AS20326 pushing packets to
Comcast over v4. Our transfers are either the full line-speed of the
Comcast customer modem, or they’re seemingly capped at 200-300KB/s. Th
Do any of the large transit providers support FlowSpec to transit customers
/ other carriers, or is that not a thing since they want to sell DDoS
protection services? FlowSpec sounds much better than RTBH (remotely
triggered blackhole), but I am not sure if FlowSpec is widely implemented.
I see th
We have customers in CT with the same issues. When did this start?
On Thu, Apr 23, 2020 at 11:07 AM Nick Zurku wrote:
> Hello all,
>
> I would appreciate if someone from Comcast could contact me about this.
>
> We’re having serious throughput issues with our AS20326 pushing packets to
> Comcast
Hi Colton,
It is fairly common to use flowspec internally at an ISP for mitigation of DDoS
attacks. eBGP flowspec is not very common though. I know of only a couple of
ISPs that allow flowspec rules to be advertised by their customers. The
biggest issue with this is that other providers are v
On Thu, Apr 23, 2020 at 8:27 AM Dovid Bender wrote:
> We have customers in CT with the same issues. When did this start?
>
Seems to have started 5 years ago when we ran out of ipv4 and all comers
needed to embrace ipv4 life-support mechanisms
https://www.arin.net/vault/announcements/2015/201509
On 2020-04-23 18:13, Colton Conor wrote:
Do any of the large transit providers support FlowSpec to transit
customers / other carriers, or is that not a thing since they want to
sell DDoS protection services? FlowSpec sounds much better than RTBH
(remotely triggered blackhole), but I am not sure i
On 2020-04-23 18:13, Colton Conor wrote:
Do any of the large transit providers support FlowSpec to transit
customers / other carriers, or is that not a thing since they want to
sell DDoS protection services? FlowSpec sounds much better than RTBH
(remotely triggered blackhole), but I am not sure i
On 4/21/20 7:46 PM, Scott Weeks wrote:
--- m...@mtcc.com wrote:
From: Michael Thomas
To: nanog@nanog.org
Subject: Re: mail admins?
Date: Tue, 21 Apr 2020 17:34:36 -0700
On 4/21/20 5:19 PM, Scott Weeks wrote:
I think you just need to let scripts run in your browser for
nanog.org.
sad.
On 23 Apr 2020, at 22:57, Denys Fedoryshchenko wrote:
In general operators don't like flowspec
Its increasing popularity tens to belie this assertion.
Yes, you're right that avoiding overflowing the TCAM is very important.
But as Rich notes, a growing number of operators are in fact using
On Thu, Apr 23, 2020 at 8:06 AM Nick Zurku wrote:
> We’re having serious throughput issues with our AS20326 pushing packets to
> Comcast over v4. Our transfers are either the full line-speed of the Comcast
> customer modem, or they’re seemingly capped at 200-300KB/s. This behavior
> appears to
Christopher Morrow писал 2020-04-22 14:05:
a question about the data types here...
So, a neighbor with no downstream ASN could be filtered directly with
ROA == prefixlist-content.
A neighbor with a downstream ASN has to be ROA (per asn downstream) ==
prefixlist-content.
So you'd now have to do
On 2020-04-23 19:12, Roland Dobbins wrote:
On 23 Apr 2020, at 22:57, Denys Fedoryshchenko wrote:
In general operators don't like flowspec
Its increasing popularity tens to belie this assertion.
Yes, you're right that avoiding overflowing the TCAM is very
important. But as Rich notes, a grow
Vincent Bernat писал 2020-04-22 15:26:
❦ 22 avril 2020 12:51 -04, Andrey Kostin:
BTW, has anybody yet thought/looked into extending RPKI-RTR protocol
for validation of prefixes received from peer-as to make ingress
filtering more dynamic and move away prefix filters from the routers?
It could
On Thu, Apr 23, 2020 at 1:33 AM Rich Kulawiec wrote:
> - I've received erroneous bounces from @email.uscc.net as well.
> It should be possible to track down the culprit via Mailman's logs
> and the MTA's logs.
Hi Rich,
One of the annoyances with both those guys and the swedish folks is
that they
We started getting the wave of complaints over the last two weeks or so.
Perhaps up to a month ago was when the initial few issues that were
reported but were chalked up to being “an issues out on the internet.”
Did your issues in CT start on a certain date?
--
Nick Zurku
Systems Engineer
TeraSw
Hello,
I am looking for a Venmo network contact that can assist with a geolocation
error in their systems. We have customers on a particular IP prefix who are
being flagged by Venmo as outside of the USA but they are not outside of the
USA. All standard geolocation systems I can find, as well
--- m...@mtcc.com wrote
> So I should just get used to configuring routers with HTTP and
> Notepad and forget about that nasty, old, 20th century vi crap? :)
No, but complaining about javascript on websites
-
Just to be clear, I was only complaining about NAN
- On Apr 23, 2020, at 8:06 AM, Nick Zurku wrote:
> We’re having serious throughput issues with our AS20326 pushing packets to
> Comcast over v4. Our transfers are either the full line-speed of the Comcast
> customer modem, or they’re seemingly capped at 200-300KB/s. This behavior
> appears t
I'm trying to build a list that has anyone of consequence on it for
geolocation\VPN issues.
http://thebrotherswisp.com/index.php/geo-and-vpn/
If you get anywhere with Venmo, let me know so I can add it to the list.
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.
On Tue, 2020-04-21 at 18:54 +, Mel Beckman wrote:
> It’s not really oversold bandwidth. It’s just that the turnaround
> time for a bolus of data is too long for two-way video conferencing
> to be smooth or reliable. It’s like video conferencing using post
> cards :)
Except that videoconferenci
Is there a guide on how to get foreign ISPs to shut down reflectors used in
DDoS attacks?
I've tried sending emails listed under abuse contacts for their regional
registries. Either there is none listed, the email is full, email does not
exist, or they do not reply. Same results when sending to wh
It won't work.
Get a good DDoS protection and forget about it.
On Fri, Apr 24, 2020 at 5:17 AM Bottiger wrote:
> Is there a guide on how to get foreign ISPs to shut down reflectors used
> in DDoS attacks?
>
> I've tried sending emails listed under abuse contacts for their regional
> registries.
On Thu, Apr 23, 2020 at 12:45 PM Sabri Berisha
wrote:
> - On Apr 23, 2020, at 8:06 AM, Nick Zurku
> wrote:
>
> We’re having serious throughput issues with our AS20326 pushing packets to
> Comcast over v4. Our transfers are either the full line-speed of the
> Comcast customer modem, or they’r
We are unable to upgrade our bandwidth in those areas. There are no
providers within our budget there at the moment. Surely there must be some
way to get them to respond.
On Thu, Apr 23, 2020 at 2:23 PM Siyuan Miao wrote:
> It won't work.
>
> Get a good DDoS protection and forget about it.
>
> O
Sounds like you'll need to talk to your upstreams if they can provide DDOS
protection, alternatively look for remote DDOS protection options.
Regards,
Filip
On 23 April 2020 11:30:36 pm GMT+02:00, Bottiger wrote:
>We are unable to upgrade our bandwidth in those areas. There are no
>providers wi
This brings up an interesting question -- what is "good DDoS protection" on an
ISP scale? Apart from having enough bandwidth to weather the attack and having
upstream providers attempt to filter it for you/
-Original Message-
From: "Bottiger"
Sent: Thursday, April 23, 2020 5:30pm
T
The answer is “it depends”. What are you trying to accomplish? Are you trying
to detect and surgically mitigate every DDoS attack? If so, you will need a
good DDoS attack detection and mitigation solution and a team of people to run
it or a 3rd party company that can do this for you. Do you
Good luck with that. 😊 As Damian Menscher has presented at NANOG, even if we
do an amazing job and shut down 99% of all DDoS reflectors, there will still be
enough bandwidth to generate terabit size attacks. https://stats.cybergreen.net
I think we need to instead collectively focus on stopping
On Thu, Apr 23, 2020 at 2:38 PM Shawn L via NANOG wrote:
> This brings up an interesting question -- what is "good DDoS protection" on
> an ISP scale? Apart from having enough bandwidth to weather the attack and
> having upstream providers attempt to filter it for you/
Hi Shawn,
I believe the
On Thu, Apr 23, 2020 at 3:14 PM Compton, Rich A
wrote:
> Good luck with that. 😊 As Damian Menscher has presented at NANOG, even
> if we do an amazing job and shut down 99% of all DDoS reflectors, there
> will still be enough bandwidth to generate terabit size attacks.
> https://stats.cybergreen
There are many decent options for ddos protection in the US and Europe,
however there are very few in Brazil and Asia that support BGP. Servers and
bandwidth in these areas are much more expensive.
Even though we are already doing anycast to split up the ddos attack, a
majority of the attack traff
On 4/23/20 12:15 PM, Scott Weeks wrote:
--- m...@mtcc.com wrote
So I should just get used to configuring routers with HTTP and
Notepad and forget about that nasty, old, 20th century vi crap? :)
No, but complaining about javascript on websites
-
Just to be c
--- m...@mtcc.com wrote:
From: Michael Thomas
I'm not sure why the admins of nanog's site should
particularly care about appeasing the js tinfoil hat
set. i mean, computers computing! who will stop this
madness!
-
Not the tin foil hat crowd, sec
On 4/23/20 4:13 PM, Scott Weeks wrote:
--- m...@mtcc.com wrote:
From: Michael Thomas
I'm not sure why the admins of nanog's site should
particularly care about appeasing the js tinfoil hat
set. i mean, computers computing! who will stop this
madness!
---
On Thu, Apr 23, 2020 at 4:13 PM Scott Weeks wrote:
> --- m...@mtcc.com wrote:
>> I'm not sure why the admins of nanog's site should
>> particularly care about appeasing the js tinfoil hat
>> set.
>
> Not the tin foil hat crowd, security.
Can't it be both?
Mobile code (javascript) has a long a st
On 4/23/20 4:40 PM, William Herrin wrote:
On Thu, Apr 23, 2020 at 4:13 PM Scott Weeks wrote:
--- m...@mtcc.com wrote:
I'm not sure why the admins of nanog's site should
particularly care about appeasing the js tinfoil hat
set.
Not the tin foil hat crowd, security.
Can't it be both?
Mobile
On Thu, Apr 23, 2020 at 3:26 PM Ca By wrote:
> On Thu, Apr 23, 2020 at 3:14 PM Compton, Rich A
> wrote:
>
>> Good luck with that. 😊 As Damian Menscher has presented at NANOG,
>> even if we do an amazing job and shut down 99% of all DDoS reflectors,
>> there will still be enough bandwidth to ge
Bottiger,
If what you are saying is true and can be backed by documentation, I would
start at the abuse contact for the offending 'Amplifier' and then start
working your way up the transits of the offending AS# until someone cuts
them off.
The Squeaky wheel gets the grease!
On Thu, Apr 23, 2020 a
On Thu, Apr 23, 2020 at 04:30:28PM -0700, Michael Thomas wrote:
> Ironically it seems that the way to disable javascript is to install a
> browser extension.
Nope. chrome://settings/content/javascript for Chromium, about:config ->
javascript.enabled in Firefox.
- Matt
On Thu, Apr 23, 2020 at 09:10:37AM -0700, Michael Thomas wrote:
> javascript is a hell of a lot safer than downloading native apps on your
> phone, for example.
Because those are, of course, the *only* two possible options for accessing
information.
- Matt
On 4/23/20 6:07 PM, Matt Palmer wrote:
On Thu, Apr 23, 2020 at 09:10:37AM -0700, Michael Thomas wrote:
javascript is a hell of a lot safer than downloading native apps on your
phone, for example.
Because those are, of course, the *only* two possible options for accessing
information.
I'm sor
On Thu, Apr 23, 2020 at 4:57 PM Michael Thomas wrote:
> If you want an actual verifiable current day problem which is a clear
> and present danger, you should be running as fast as you can to retrofit
> every piece of web technology with webauthn to get rid of over the wire
> passwords.
>
> I thin
On 4/23/20 6:20 PM, William Herrin wrote:
On Thu, Apr 23, 2020 at 4:57 PM Michael Thomas wrote:
If you want an actual verifiable current day problem which is a clear
and present danger, you should be running as fast as you can to retrofit
every piece of web technology with webauthn to get rid
On 4/23/20 1:47 PM, William Herrin wrote:
> Even if mailman saw it, mailman doesn't use VERP.
Both 2.1 and 3.0 of mailman support VERP. I've had it running for some time
on mailman 2.1.
I'm not sure how it will impact delivery time (a consideration). I've found
it to be a non issue in my case.
On Thu, Apr 23, 2020 at 06:31:04PM -0700, Michael Thomas wrote:
> Passwords over the wire are the *key* problem of computer security. Nothing
> else even comes close.
Hmm, a bold claim, but I'm confident the author will have strong support for
their position.
> One only needs to look at the Linke
On 4/23/20 7:35 PM, Matt Palmer wrote:
On Thu, Apr 23, 2020 at 06:31:04PM -0700, Michael Thomas wrote:
Passwords over the wire are the *key* problem of computer security. Nothing
else even comes close.
Hmm, a bold claim, but I'm confident the author will have strong support for
their position
On 4/23/20 6:20 PM, William Herrin wrote:
On Thu, Apr 23, 2020 at 4:57 PM Michael Thomas wrote:
If you want an actual verifiable current day problem which is a clear
and present danger, you should be running as fast as you can to retrofit
every piece of web technology with webauthn to get rid
On 2020-04-23 7:31 p.m., Michael Thomas wrote:
On 4/23/20 6:20 PM, William Herrin wrote:
On Thu, Apr 23, 2020 at 4:57 PM Michael Thomas wrote:
Passwords over the wire are the *key* problem of computer security.
Nothing else even comes close. One only needs to look at the LinkedIn
salting prob
On Thu, Apr 23, 2020 at 07:47:58PM -0700, Michael Thomas wrote:
> On 4/23/20 7:35 PM, Matt Palmer wrote:
> > While I do think webauthn is a neat idea, and solves at least one very real
> > problem (credential theft via phishing), you do an absolutely terrible job
> > of making that case.
>
> see R
52 matches
Mail list logo
