Re: Password Reset

[J. Hellenthal via NANOG]

You'll have to do your own workNANOG Info Pagemailman.nanog.org--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Jan 2, 2024, at 13:25, Luiz Rosas  wrote:Hello, I'm trying to reset a password for username "guga0071", but the email address that is attached to this account I no longer have access to. Can you please update my account with the new email address "lrosas0...@gmail.com" and provide me with a link to reset my password.RegardsLuiz Rosas

Re: Ford.com network admin

[J. Hellenthal via NANOG]

FONDFound On Network Dead 浪--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Oct 30, 2023, at 12:13, Dennis Burgess  wrote:







That is what is not working.  If I go to the link from this specific prefix, it does not work, and I get the error I sent Becki. 
  
 

From: Brandon Jackson  
Sent: Monday, October 30, 2023 12:01 PM
To: Kain, Becki (.) 
Cc: Dennis Burgess ; NANOG list 
Subject: Re: Ford.com network admin

 


I get that too if I just go direct to
https://login ford.com, but if I use the link from the homepage while it still goes to the same domain it appends a bunch of stuff to the end of that link and does work.


On Mon, Oct 30, 2023, 12:11 Kain, Becki (.) via NANOG  wrote:




From inside of Ford, I get this:
 
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
 


From: NANOG ford@nanog.org>
On Behalf Of Dennis Burgess
Sent: Monday, October 30, 2023 12:01 PM
To: nanog@nanog.org
Subject: Ford.com network admin


 


WARNING: This message originated outside of Ford Motor Company. Use caution when opening attachments, clicking links, or responding.

 

I have a specific subnet of users that are getting denied access to even get to the login page at

https://login.ford.com.  Looking for someone to contact me offlist about this issue please
 



Dennis Burgess


Mikrotik : Trainer, Network Associate, Routing Engineer, Wireless Engineer, Traffic Control Engineer, Inter-Networking Engineer, Security Engineer, Enterprise Wireless Engineer

Hurricane Electric: IPv6 Sage Level

Cambium: ePMP


 

Author of "Learn RouterOS- Second Edition”


Link Technologies, Inc -- Mikrotik & WISP Support Services


Office: 314-735-0270  Website:
http://www.linktechs.net


Create your own Tickets via 
https://hd.linktechs.net 

Create Wireless Coverage’s with 
www.towercoverage.com


Need MikroTik Cloud Management: 
https://cloud.linktechs.net 

Remote Winbox Service: 
http://rwb.linktechs.net 
 

Re: TACACS+ server recommendations?

[J. Hellenthal via NANOG]

Just going to drop this in here ...Privileged Access Management Solutions for Enhanced Cybersecurity | PAM Systems | Fudo Securityfudosecurity.comIf you are looking for something a little more upbeat --  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Sep 22, 2023, at 16:00, Mike Lewinski via NANOG  wrote:We are using Okta's RADIUS service for 2fa to network gear currently, but looking to switch to tacacs+ for many reasons. Would prefer to implement tacacs+ with two-factor if possible.tac_plus-ng from https://www.pro-bono-publico.de/projects/tac_plus-ng.html has LDAP and PAM backends, among others, so I believe you can implement 2FA through them. I haven't implemented this yet but it's on my to-do list (and I'm also warily watching passkey developments and wondering how much effort I should put into something that likely won't be best practice in another year or two).I see Marc Huber is also promoting/supporting tacacs+ extension for SSH public key authhttps://github.com/MarcJHuber/event-driven-servers/wiki/TACACS_PLUS---SSH-Public-Key-Authentication

Re: it's mailman time again

[J. Hellenthal via NANOG]

You didn't lose your /. account because of a mailing list config.You lost it due to the bad practices or knowledge at the time.\o/--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Sep 2, 2023, at 17:08, Richard Porter  wrote:







Pouring kerosine on fire? *flame me back if warranted*


Voice networks have no POTS left in them? *mostly?* ….





Get Outlook for iOS


From: NANOG  on behalf of Randy Bush 
Sent: Saturday, September 2, 2023 4:30:07 PM
To: Jim Popovitch via NANOG 
Subject: Re: it's mailman time again
 


> Mail in transit is mostly TLS transport these days,

yep.  mostly.  opsec folk are not fond of 'mostly.'

> BUT mail in storage and idle state isn't always secured.  I'm sure
> that most any of us could find a public s3 bucket with an mbox file on
> it if we cared to look.

sigh

randy

Re: Questionnaire on building real network configuration dataset

[J. Hellenthal via NANOG]

It might be a better option for you to un-signin this survey...

Just a suggestion.

On Thu, Apr 27, 2023 at 01:46:49PM +0800, 徐惠三 wrote:
>Dear NANOG community members,
> 
>We are post graduate students majoring in computer network and we are now
>conducting a research project aimed at setting up an open dataset of real
>network configurations for experiment needs. We think it will be a
>contributing work for network verification evaluations. As part of this
>effort, we are reaching out to the community to request your help in
>filling out a short questionnaire.
> 
>Your participation in this survey would be greatly appreciated and
>valuable for our research. It will take only about 2-3 minutes of your
>time and your responses will be kept strictly confidential. 
> 
>To participate in the survey, please click on the following
>link: 
> https://docs.google.com/forms/d/1XPBxVH40UcQRMZf-H-ENj4AUZQDEw8xxQtllyylCl4E/edit
> 
>Please note that the survey will be open for one month, and we kindly ask
>you to complete it by the end of May. Thank you in advance for your
>participation and support of our research. 
> 
>Best regards,
> 
>Huisan

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Land Mobile Radio (LMR) for Information Technology (IT) Professionals

[J. Hellenthal via NANOG]

CISA always 6 pages long and full of catchy words.

Is there anything beyond this that really adds any real substantial value ?

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 17, 2023, at 11:59, Sean Donelan  wrote:
> 
> 
> IT professionals are often tasked with planning, provisioning, implementing, 
> and managing LMR networks with the assumption that all computer networks are 
> basically the same and have the same general requirements. However, in some 
> cases this assumption has resulted in LMR networks being inadequately 
> provisioned, resourced, and managed or maintained. While each system is a 
> network, significant differences between the two must be considered to 
> address the infrastructure, planning, and lifecycle needs of typical IT 
> networks versus the unique requirements of LMR networks.
> 
> https://www.cisa.gov/news-events/news/safecom-and-ncswic-develop-land-mobile-radio-lmr-information-technology-it-professionals

Re: intuit DNS

[J. Hellenthal via NANOG]

Ruhroh someone took the ai out again

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Feb 12, 2023, at 02:01, Saku Ytti  wrote:
> 
> ╰─ dig NS intuit.com|grep ^intuit|ruby -nae 'puts $F[-1]'|while read dns;do
> echo $dns:;dig smartlinks.intuit.com @$dns|grep CNAME
> done
> a7-66.akam.net.:
> smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.com.
> a11-64.akam.net.:
> smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.com.
> a24-67.akam.net.:
> smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.com.
> a1-182.akam.net.:
> smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.com.
> a6-66.akam.net.:
> smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.com.
> a18-64.akam.net.:
> smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.com.
> dns1.p01.nsone.net.:
> dns2.p01.nsone.net.:
> dns3.p01.nsone.net.:
> dns4.p01.nsone.net.:
> ╭─ ytti@ytti   ~ 
>    0|0|0|1 ↵  09:58:40 
> 
> 
>> On Sat, 11 Feb 2023 at 23:01, Daniel Sterling  
>> wrote:
>> 
>> Someone at Intuit please look into why your DNS for this A record
>> hasn't been consistently resolving, this has been going on for several
>> days if not weeks
>> 
>> https://dnschecker.org/#A/smartlinks.intuit.com
>> 
>> -- Dan
> 
> 
> 
> -- 
>  ++ytti

Re: Large RTT or Why doesn't my ping traffic get discarded?

[J. Hellenthal via NANOG]

As well if this persists you may consider disabling hardware rx/tx checksumming 
to see if it clears up your results. Some net cards can get glitchy causing 
this exact behavior.

GL

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Dec 21, 2022, at 13:58, William Herrin  wrote:
> 
> On Wed, Dec 21, 2022 at 9:10 AM Jason Iannone  
> wrote:
>> Here's a question I haven't bothered to ask until now. Can someone please 
>> help me understand why I receive a ping reply after almost 5 seconds?
>> 
>> 64 bytes from 4.2.2.2: icmp_seq=398 ttl=54 time=4915.096 ms
>> 64 bytes from 4.2.2.2: icmp_seq=399 ttl=54 time=4310.575 ms
>> 64 bytes from 4.2.2.2: icmp_seq=400 ttl=54 time=4196.075 ms
>> 64 bytes from 4.2.2.2: icmp_seq=401 ttl=54 time=4287.048 ms
>> 64 bytes from 4.2.2.2: icmp_seq=403 ttl=54 time=2280.466 ms
>> 64 bytes from 4.2.2.2: icmp_seq=404 ttl=54 time=1279.348 ms
>> 64 bytes from 4.2.2.2: icmp_seq=405 ttl=54 time=276.669 ms
> 
> Hi Jason,
> 
> This usually means a problem on the Linux machine originating the
> packet. It has lost the ARP for the next hop or something similar so
> the outbound ICMP packet is queued. The glitch repairs itself,
> briefly, releasing the queued packets. Then it comes right back.
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> For hire. https://bill.herrin.us/resume/

Re: Sites blocking ISP Addresses

[J. Hellenthal via NANOG]

Formal snail mail is your only option.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Nov 30, 2022, at 12:26, James Dexter  wrote:
> 
> 
> Dear list, 
> We have address ranges that are being blocked by sites like Ticketmaster. 
> Customer support is able to assist, and unable to receive a response from 
> legal or hostmaster emails. What are the recommendations for requesting a 
> removal from the blocked list at these sites? 
> 

Re: ingress/egress 9/8 gov.xxx.ticket; was: Re: pls pls me 80/81...

[J. Hellenthal via NANOG]

Nothing like a good ole April fools please fill my empty repo with your code. Happy 旅 genocide day everyone.--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Nov 24, 2022, at 14:12, Matthew Petach  wrote:Whoa!Is it the start of April already?  I must have overslept last night, I could have sworn we just barely made it to Thanksgiving!MattOn Tue, Nov 22, 2022 at 6:48 AM AQ Glass  wrote:anybody interested in this project?@oracle can own the .ticket tld; NS * ticket. -> virtualhost 96hr netflow + tech/biz/admin for adnetworks to reg their new xxx. with gov.xxx.ticket signup and further instructions//https://twitter.com/element9v/status/1579552246911885312?t=NdYwACGQsPkg0o0sHtIiqA=19codedevs can commit tohttps://github.com/element9v/takebackdarpathx-eOn Thu, Nov 17, 2022, 3:50 PM AQ Glass  wrote:https://twitter.com/element9v/status/1592162934658334720?t=f1cpwD_kr3wwIVlnrzCT4A=19#routetonull discuss#takebackdarpa-e

Re: ingress/egress 9/8 gov.xxx.ticket; was: Re: pls pls me 80/81...

[J. Hellenthal via NANOG]

That's a hard no!--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Nov 22, 2022, at 08:47, AQ Glass  wrote:anybody interested in this project?@oracle can own the .ticket tld; NS * ticket. -> virtualhost 96hr netflow + tech/biz/admin for adnetworks to reg their new xxx. with gov.xxx.ticket signup and further instructions//https://twitter.com/element9v/status/1579552246911885312?t=NdYwACGQsPkg0o0sHtIiqA=19codedevs can commit tohttps://github.com/element9v/takebackdarpathx-eOn Thu, Nov 17, 2022, 3:50 PM AQ Glass  wrote:https://twitter.com/element9v/status/1592162934658334720?t=f1cpwD_kr3wwIVlnrzCT4A=19#routetonull discuss#takebackdarpa-e

Re: Router ID on IPv6-Only

[J. Hellenthal via NANOG]

Right!

Personally it just needs to be unique. Relying on a Id to be unique when 
ascociated to an IP address that may be used on a failover system seems really 
poor to me.

Assign a random ID and plug it into your IPAM!. If at anything assign a router 
ID to a rack location and associate every bit of information  about that 
location in whatever you're tracking management can provide.

Personally I prefer date originated generated numbers that allow me to filter 
upon such and spill out the results to tell me where its at what rack its in, 
slot number etc...

But then again this is from a failover system perspective...


BOL

> On Sep 8, 2022, at 10:13, Randy Bush  wrote:
> 
>> During some IPv6 numbering discussions at work today, someone had a
>> question that I hadn't really considered before. How to choose 32-bit
>> router IDs for IPv6-only routers.
> 
> arbitrary 32 bit number unique in the autonomous system.  even in an
> ipv4 world it does not need to match any configured interface address.
> 
> randy


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

Re: U.S. Court PACER system overloaded by public interest

[J. Hellenthal via NANOG]

> and linked to 
> https://file///Users/Shared/Internet%20Downloads/gov.uscourts.flsd.617854.102.1_1.pdf
>  . (It's still there as I write this.)

Doubt that link is going to work for anyone 浪

Re: Zayo/as6461 will now drop invalid prefixes from our peers.

[J. Hellenthal via NANOG]

Week or so ?

Care to clarify to be a "little bit more exact" on the start date at least ...

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Aug 18, 2022, at 12:58, Rob Robertson  wrote:
> 
> 
> The Zayo/as6461 network will  shortly start dropping all RPKI-invalid route 
> announcements that we receive from our peers.  This should be rolled
> out over our network in the next week or so.
> While we will still continue to accept existing invalid route announcements 
> from our customers for now, we will be working with our customers to reduce  
> and/or eliminate invalid announcements.
> Thank you,
> ;rob
> 
> Rob Robertson
> Network Architect | Zayo Group
> 

Re: Tool for virtual networks

[J. Hellenthal via NANOG]

I couldn't have replied better--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Jul 18, 2022, at 10:38, Tom Beecher  wrote:But in the mean time (and generally) this should really only be used in a dedicated VM.  And the *primary* audience is my networks class--even though I shared with the broader networking community, in case others might find it useful or have feedback (thank you!).It's a cardinal rule that anything built with a set of assumptions about the environment it operates in will inevitably be run in a different environment somewhere, someday. :) On Fri, Jul 15, 2022 at 11:09 AM Casey Deccio <ca...@deccio.net> wrote:> On Jul 15, 2022, at 8:25 AM, J. Hellenthal <jhellent...@dataix.net> wrote:
> 
> For a quick cursory overview of this project, I would urge you to add an adendum or change the following line in the installation documentation...
> 
> "%sudo   ALL=(ALL:ALL) NOPASSWD: ALL"
> 
> This is technically influencing bad behavior with sudo for those that are not aware of the security impacts of such decisions.
> 
> I'm not one to provide a negative remark usually without suggesting a result that provides a positive impact that can be built upon. So with that said and along the lines of that id suggest adjusting the documentation to contain something of the sorts of a guided only per user or separate group other than "%sudo"... maybe "%cougarnet" and add instructions for creating the group and adding users to that group.
> 
> Beyond that... nice project and thank you for your contribution to networking. This may be beyond the scope of just this one mailing list and wish you the best.

Thanks so much for the feedback.  As noted, this is still a work-in-progress.  Now that I'm mostly past the proof-of-concept phase of development, and one of my near-term to-do items is to improve least privilege in the code.  I think it does fairly well in other places, but the sudo access is still too liberal.  At the moment, the plan is to enumerate the commands used with sudo in the code and apply them to a group of which a user must be a part.  For example:

%cougarnet   ALL=(ALL:ALL) NOPASSWD: /usr/bin/ip, /usr/sbin/sysctl

But in the mean time (and generally) this should really only be used in a dedicated VM.  And the *primary* audience is my networks class--even though I shared with the broader networking community, in case others might find it useful or have feedback (thank you!).

Cheers,
Casey

Re: Tool for virtual networks

[J. Hellenthal via NANOG]

For a quick cursory overview of this project, I would urge you to add an 
adendum or change the following line in the installation documentation...

"%sudo   ALL=(ALL:ALL) NOPASSWD: ALL"

This is technically influencing bad behavior with sudo for those that are not 
aware of the security impacts of such decisions.

I'm not one to provide a negative remark usually without suggesting a result 
that provides a positive impact that can be built upon. So with that said and 
along the lines of that id suggest adjusting the documentation to contain 
something of the sorts of a guided only per user or separate group other than 
"%sudo"... maybe "%cougarnet" and add instructions for creating the group and 
adding users to that group.

Beyond that... nice project and thank you for your contribution to networking. 
This may be beyond the scope of just this one mailing list and wish you the 
best.

Regards,

> On Jul 14, 2022, at 17:01, Casey Deccio  wrote:
> 
> Dear colleagues,
> 
> I've been developing a tool for building and experimenting with virtual 
> networks, primarily for use with teaching network protocols.  It's an active 
> work-in-progress, but I thought it might be time to reach out to NANOG in 
> case anyone else might find it useful and/or might have feedback to offer.  
> Here is the code:
> 
> https://github.com/cdeccio/cougarnet
> 
> It includes layer-2 switches, VLANs and trunking, and routers, all using 
> Linux processes in their own namespaces as network "nodes".  It was inspired 
> by mininet (https://mininet.org) but it was developed from scratch to meet 
> different needs.
> 
> The README has additional information.  If you install and run the code, 
> *please* do it in a *virtual machine*.  At this point, it requires superuser 
> capabilities to run things like "ip link", "ip addr", and "sysctl", among 
> other things, using sudo.  Much on the to-do list, but it meets my immediate 
> needs.  Just wanted to share in the mean time.
> 
> Cheers,
> Casey


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

Re: cf is down?

[J. Hellenthal via NANOG]

Huh ?

Although the https://www.cryptopp.com/wiki/Ed25519 lib exploit could have 
something to do with this. Butt eh!


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Jun 21, 2022, at 11:55, Doug Barton  wrote:
> 
> Was someone scanning the Internet for vulnerabilities?
> 
> 
> On 6/21/22 12:20 AM, Eric Kuhnke wrote:
>> Massive spike in consumer facing services reported as broken by 
>> downdetector, almost all are likely cf customers. See downdetector homepage.

Re: Scanning the Internet for Vulnerabilities

[J. Hellenthal via NANOG]

To what extent and to whom will you authorize to do that? 100 random college 
students? X number of new security firms? At some point it will break.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jun 20, 2022, at 17:04, b...@theworld.com wrote:
> 
> 
> It seems to me there's vulnerability testing and there's vulnerability
> testing and just lumping them all together motivates disparate
> opinions.
> 
> For example it's one thing to perhaps see if home routers
> login/passwords are admin/admin or similar, or if systems seem to be
> vuln to easily exploitable bugs and reporting such problems to someone
> in charge versus, say, hammering at some network to see when/if DDoS
> mitigation kicks in.
> 
> For example I've gotten email in the past that some of my servers were
> running ntp in a way which makes them vuln to being used for DDoS
> amplification and, I believe, fixed that. I didn't mind.
> 
> Anyhow, you all probably get my point without further hypotheticals or
> examples.
> 
> Scanning for known vulns and reporting can be ok, testing to
> destruction? Not so much.
> 
> -- 
>-Barry Shein
> 
> Software Tool & Die| b...@theworld.com | 
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*

Re:

[J. Hellenthal via NANOG]

It's not about what you use as aposed more of where it's used from.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jun 20, 2022, at 13:47, Josh Luthman  wrote:
> 
> 
> I use Cogent: https://www.cogentco.com/en/looking-glass and HE which is 
> easier to remember: https://lg.he.net/
> 
>> On Mon, Jun 20, 2022 at 9:56 AM Glenn Kelley  
>> wrote:
>> Good Monday Morning Everyone. 
>> 
>> Quick Question: 
>> 
>> What is everyone's favorite software for running a looking glass. 
>> 
>> A friend asked me this over the weekend - and while there are others 
>> available on the internet to use - it would be helpful for them to run one 
>> within their own network. 
>> 
>> It has been a while since i have played setting one up so figured might as 
>> well ask 
>> 
>> 
>> Glenn S. Kelley, Connectivity.Engineer 
>> Text and Voice Direct:  740-206-9624
>> 
>> 
>> 

Re: Scanning the Internet for Vulnerabilities

[J. Hellenthal via NANOG]

On Mon, Jun 20, 2022 at 11:02:25AM -0400, Michael Butler via NANOG wrote:
> I treat these folk with the same respect they afford me. Not once in 30
> years of having a connected network (v4 or v6) has any entity asked "is it
> OK if we .. ?".
> 
> To my mind, it seems rather idiotic and self-defeating to have the plumbing
> congested with packets intended to measure congestion :-(
> 
>   Michael

Well put!

> 
> On 6/20/22 09:46, Mel Beckman wrote:
> > Carsten,
> > 
> > No, it’s more like 50,000 furnace guys who show up several times a day to 
> > rattle doorknobs, attempt to push slim Jim’s into window latches, hack your 
> > garage door opener, sneak into your back garden, and fly drones around your 
> > home to see what valuables you might have. Yes, some of them are 
> > altruistic, but some are self-righteous officious boobs, and the vast 
> > majority are career criminals that will rob your house, drain your 
> > retirement account, and kill your family with a spoofed SWAT raid.
> > 
> >   -mel beckman
> > 
> > > On Jun 20, 2022, at 4:20 AM, Carsten Bormann  wrote:
> > > On 2022-06-20, at 04:18, Mel Beckman  wrote:
> > > > 
> > > > When researchers, or whoever, claim their scanning an altruistic 
> > > > service, I ask them if they would mind someone coming to their home and 
> > > > trying to open all the doors and windows every night.
> > > 
> > > Well, it is more like the guy who comes once a year and checks that your 
> > > central heating is not going to blow up.
> > > 
> > > (Disclaimer: I have supervised students who designed and executed benign 
> > > mass-scans of the IPv4 Internet in order to validate hypotheses about 
> > > market penetration of certain security updates, and I definitely would do 
> > > that again if there is a good reason to perform such a scan.)
> > > 
> > > Grüße, Carsten
> 

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Test email

[J. Hellenthal via NANOG]

This is like setting a read-receipt-to: to a mailing list. The results
are phenom !

But on the other hand you get a nice handy list of replies that say "did
not read" ;) leaking their address as a member.

Done this by accident myself :(

On Mon, Jun 20, 2022 at 02:11:50AM -0600, h...@interall.co.il wrote:
> 
> Hello,
> 
> Checking Email Functionality.
> 
> Hosting Support
> Thank you,

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Scanning the Internet for Vulnerabilities

[J. Hellenthal via NANOG]

On Mon, Jun 20, 2022 at 02:47:27PM +0200, Carsten Bormann wrote:
> J.,
> 
> > On 2022-06-20, at 14:14, J. Hellenthal  wrote:
> > 
> > Yeah that's another thing, "research" cause you need to learn it let's have 
> > them do it too, multiply that by every university \o/
> 

No no not saying there wasnt. Research is needed for sure and education
is very important. But the fact of most matters stand in that area where
some code may not exactly be up to par from "some students" and still
exaust itself on the public internet of things where little real
oversight actually happens from its origin until it has already impacted
multiple destinations that did not ask for it.

Definately did sign up for it! and with all the proper checks and
balances, can handle them appropriately at 2am when when N students have
been asleep letting their code run wild.

Sorry not picking on "you/this" in particular on your part. It's just
not all of them are exactly up to par while following what they believe
are best practices governed by an instructor(not you) that deems it
benign where I have found some instructors/educators have very little
knowledge in the field whatsoever beyond a textbook and a home
computer/lab. I look forward to the school years to begin, it brings a
challenge where traffic from skids drops between certain hours in
different countries and the detection begins for advertisement scanners
and real threats.

Noise is cool, it gives pretty results where the ugly of the networks
typically just annoy you. Not cool when its amplified by N number of
whatever (advertising/company/students) like a udp amplification attack
but initiated by india.edu, america.edu, X.edu all at the wrong time.

Anyway I retract

Happy fathers day yesterday and hope all your're weekends have been
great.

> there was some actual research involved.
> 
> I agree that there should be a very good reason to expend a tiny bit of 
> everyone’s resources on this.
> 
> I do not agree that this externality makes any research in this space 
> unethical.
> 
> You signed up for this when you joined the Internet (er, stuck with the IPv4 
> Internet, I should probably say).
> 
> Grüße, Carsten
> 

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Scanning the Internet for Vulnerabilities

[J. Hellenthal via NANOG]

Yeah that's another thing, "research" cause you need to learn it let's have 
them do it too, multiply that by every university \o/

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jun 20, 2022, at 06:22, Carsten Bormann  wrote:
> 
> On 2022-06-20, at 04:18, Mel Beckman  wrote:
>> 
>> When researchers, or whoever, claim their scanning an altruistic service, I 
>> ask them if they would mind someone coming to their home and trying to open 
>> all the doors and windows every night. 
> 
> Well, it is more like the guy who comes once a year and checks that your 
> central heating is not going to blow up.  
> 
> (Disclaimer: I have supervised students who designed and executed benign 
> mass-scans of the IPv4 Internet in order to validate hypotheses about market 
> penetration of certain security updates, and I definitely would do that again 
> if there is a good reason to perform such a scan.)
> 
> Grüße, Carsten
> 

Re: Scanning the Internet for Vulnerabilities

[J. Hellenthal via NANOG]

Wish I still had that email from them where person "possibly not speaking for the company" stated that "they scan the entire internet for vulns and other nefarious things.Where I stated "don't care get your unwanted advertisement scans off my edge, if I want you in the future I know where to find you". And he kept beating around the bush.--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Jun 20, 2022, at 01:09, Owen DeLong via NANOG  wrote:shadow server (to the best of my knowledge) only scans sites that have invited them to do so.OwenOn Jun 19, 2022, at 10:43 , Forrest Christian (List Account)  wrote:See shadowserver.netOn Sun, Jun 19, 2022, 4:13 AM Ronald F. Guilmette  wrote:I would like to solicit the opinions of network operators on the practice
of scanning all of, or large chunks of the internet for known vulnerabilities.

In earlier times, this was generally viewed as being distinctly anti-social
behavior, but perhaps attitudes have changed relative to earlier eras.
I would thus like to know how people feel about it now, in 2022.


Regards,
rfg


P.S.  Just to be clear, I personally have neither any desire nor any intent
to undertake such activity myself, nor am I in communiacation with any party
or parties that have such an intent or desire.  I cannot however say that I
am unaware of any parties that may currently be involved in such activities.

Re: Test email

[J. Hellenthal via NANOG]

Novices 浪

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jun 20, 2022, at 03:36, Hank Nussbacher  wrote:
> 
> On 20/06/2022 11:30, Peter Potvin wrote:
> 
> I did not send this to the list.  I assume the admins are testing out what 
> has been blocking my emails for the past month and somehow this email slipped 
> thru.  Just ignore and delete.
> 
> -Hank
> 
>> Why did moderation let this through the filters? I don't believe that 
>> testing email functionality is the intended use case of the NANOG mailing 
>> list.
>> Also worth noting that the website for the domain this came from says the 
>> owner of the site specializes in "anti-spam", which based on this email 
>> alone doesn't look to be the case. Anyone else agree?
>> Regards,
>> Peter
>> On Mon., Jun. 20, 2022, 4:15 a.m. , > <mailto:h...@interall.co.il>> wrote:
>>Hello,
>>Checking Email Functionality.
>>Hosting Support
>>Thank you,
>> The information contained in this message may be privileged, confidential 
>> and protected from disclosure. This message is intended only for the 
>> designated recipient(s). It is subject to access, review and disclosure by 
>> the sender's Email System Administrator. If you have received this message 
>> in error, please advise by return e-mail so that our address records can be 
>> corrected and please delete immediately without reading, copying or 
>> forwarding to others. Any unauthorized review, use, disclosure or 
>> distribution is prohibited.
>> Copyright © 2022 Accuris Technologies Ltd. All Rights Reserved.
>> L'information contenue dans ce message pourrait être de nature privilégiée, 
>> confidentielle et protégée contre toute divulgation. Ce message est destiné 
>> à l'usage exclusif du(des) destinataire(s) visé(s). Le gestionnaire de 
>> système du courrier électronique de l'expéditeur pourrait avoir accès à ce 
>> message, l'examiner et le divulguer. Si ce message vous est transmis par 
>> erreur, veuillez nous en aviser par courrier électronique à notre adresse, 
>> afin que l'on puisse corriger nos registres, puis veuillez le supprimer 
>> immédiatement, sans le lire, le copier ou le transmettre à des tiers. Tout 
>> examen, toute utilisation, divulgation ou distribution non autorisé de cette 
>> information est interdit.
>> Droit d'auteur © 2022 Accuris Technologies Ltd. Tous droits réservés.
> 

Re: Scanning the Internet for Vulnerabilities

[J. Hellenthal via NANOG]

Yep that's exactly what that is. While the intention is good, it's all still unwarranted.--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Jun 19, 2022, at 21:18, Mel Beckman  wrote:




When researchers, or whoever, claim their scanning an altruistic service, I ask them if they would mind someone coming to their home and trying to open all the doors and windows every night. 


 -mel beckman


On Jun 19, 2022, at 6:14 PM, J. Hellenthal via NANOG  wrote:




 Had to send these guys a cease and desist a few years back as they became so noisy it was causing to much of a disconnect between information we were trying to compare.






Personally I don't care who you are. Probably not hiring your services (free or not), stay off my edge.


-- 
 J. Hellenthal


The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.

On Jun 19, 2022, at 13:56, Amreesh Phokeer  wrote:





Project Sonar from Rapid7 conducts internet-wide surveys and is kind enough to share the data with researchers:
https://www.rapid7.com/research/project-sonar/


On Sun, Jun 19, 2022 at 10:24 PM Mark Seiden <m...@seiden.com> wrote:


btw, if you want to do this yourself, you might consider using something like


https://github.com/opsdisk/scantron





-- 
Amreesh Phokeer

Re: Scanning the Internet for Vulnerabilities

[J. Hellenthal via NANOG]

Had to send these guys a cease and desist a few years back as they became so noisy it was causing to much of a disconnect between information we were trying to compare.Can't for for more idiot services to just jump on the wagon and deploy their own scanners and pollute edges without a just cause. Personally I don't care who you are. Probably not hiring your services (free or not), stay off my edge.--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Jun 19, 2022, at 13:56, Amreesh Phokeer  wrote:Project Sonar from Rapid7 conducts internet-wide surveys and is kind enough to share the data with researchers:https://www.rapid7.com/research/project-sonar/On Sun, Jun 19, 2022 at 10:24 PM Mark Seiden  wrote:btw, if you want to do this yourself, you might consider using something likehttps://github.com/opsdisk/scantron-- Amreesh Phokeer

Re: Bgpmon alternative

[J. Hellenthal via NANOG]

BGPlay isn't so bad. Alerting could be worked in they're somewhere but the 
explicit use case you need it for is somewhat vague ATM. As in "I have this 
scenario X that I am trying to get Y & Z information about.

-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Jun 15, 2022, at 08:45, Mehmet Akcin  wrote:
> 
> Hi there
> 
> What are the best alternatives to BGPmon these days?
> 
> Goal is to try to monitor bgp routing changes for specific prefixes.
> 
> Mehmet
> -- 
> Mehmet
> +1-424-298-1903

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[J. Hellenthal via NANOG]

Faster off the line then more open connections are always available putting 
less strain on providers and endpoints allowing them to serve more people right 
off the line.

But we all know where bandwidth goes... once it's increased. ;)

-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Jun 7, 2022, at 09:45, Denis Fondras  wrote:
> 
> Le Tue, Jun 07, 2022 at 08:12:07AM -0500, Mike Hammett a écrit :
>> Would it matter if it took 10 minutes or an hour? 
>> 
> 
> Yes, it means the computer could be off for 50 minutes.
> Also everyone who had a connection reset when uploading a big file after 55
> minutes understands why it is good if it only would take 10 minutes.
> 
> Peace of mind is under-rated :)
> 
>> 
>> What's the OneDrive rate limit? 
>> 
>> 
>> 
>> 
>> - 
>> Mike Hammett 
>> Intelligent Computing Solutions 
>> http://www.ics-il.com 
>> 
>> Midwest-IX 
>> http://www.midwest-ix.com 
>> 
>> - Original Message -
>> 
>> From: "Tony Wicks"  
>> To: nanog@nanog.org 
>> Sent: Monday, June 6, 2022 5:36:13 PM 
>> Subject: RE: FCC proposes higher speed goals (100/20 Mbps) for USF providers 
>> 
>> 
>> 
>>> This whole thread is about hypothetical futures, so it's not hard to 
>>> imagine downloads filling to available capacity. 
>>> Mike 
>> 
>> So, a good example of how this capacity is used, In New Zealand we have a 
>> pretty broad fibre network covering most of the population. My niece asked 
>> me to share my backup copy of her wedding photo’s/video’s the other day. I 
>> have a 4Gb/s / 4Gb/s XGSPON connection and she’s got a 1Gb/s / 500Mb/s GPON 
>> connection. I simply dropped a copy of the 5.1G directory into a one drive 
>> folder and shared it, 10 minutes later (one drive is still limited in how 
>> fast you can upload) she had it all and she was very happy. With these 
>> speeds its not even a consideration to think about capacity, everything just 
>> works. 

Re: Open source tool for network map visualization

[J. Hellenthal via NANOG]

Greylog has a feature to visualize attacks/threats on a map visualized by 
syslog messages being sent by IDS systems like snort/suricata. If either of 
those are deployed at your locations then you can get a map for each location 
among number of threats detected.

Just a simple related mapping feature.
https://www.graylog.org/

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On May 27, 2022, at 07:41, Marinos Dimolianis  
> wrote:
> 
> Hi all,
> 
> I was looking for an open source tool to visualize our network infrastructure 
> in a world map including also our link utilization.
> 
> Any ideas?
> 
> Thank you in advance,
> 
> Marinos
> 

Re: BGP Javascript Map/Visualization

[J. Hellenthal via NANOG]

https://github.com/anvaka/pm/tree/master/about#software-galaxies-documentation

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On May 26, 2022, at 17:46, Adam Thompson  wrote:
> 
> Neat.  Any idea who to ask questions of, regarding the incorrectness of the 
> data?  I would have assumed Job, but he's long gone from NTT, is this 
> abandonware or maintained?  Anyone know?
> 
> Adam Thompson
> Consultant, Infrastructure Services
> MERLIN
> 100 - 135 Innovation Drive
> Winnipeg, MB R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> https://www.merlin.mb.ca
> Chat with me on Teams: athomp...@merlin.mb.ca
> 
> 
>> -Original Message-
>> From: NANOG  On Behalf
>> Of b...@uu3.net
>> Sent: Thursday, May 26, 2022 3:50 PM
>> To: nanog@nanog.org
>> Subject: Re: BGP Javascript Map/Visualization
>> 
>> You were close... I think you mean this one?
>> https://as2914.net/
>> 
>> -- Original message --
>> 
>> From: Brian Johnson 
>> To: nanog@nanog.org
>> Subject: BGP Javascript Map/Visualization
>> Date: Thu, 26 May 2022 20:07:51 +
>> 
>> Hey all,
>> 
>> Sorry for the noise.  Years ago someone here built and shared a
>> javascript
>> visualization of what their routers saw for the state of BGP and paths
>> to
>> get to various ASs. One could use WSAD and other keys to fly around
>> and
>> examine various other ASs.  I thought it was as2814.net, but that
>> seems to
>> not be a thing anymore.  Can someone refresh my memory where that
>> might be?
>> Or did it get taken down?
>> 
>> Thanks in advance,
>> - brian
>> 
>> 
>> 
>> 
> 

Re: Comcast/Florida

[J. Hellenthal via NANOG]

Good find Jeff !



-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Apr 26, 2022, at 08:25, JeffP  wrote:
> 
> Joe-
> 
> Another wayward backhoe strikes again..
> 
> https://www.heraldtribune.com/story/news/local/2022/04/25/comcast-outage-no-internet-florida/7446019001/
> 
>> On 4/25/22 15:34, Joe Carroll wrote:
>> Comcast in Florida
> -- 
> JeffP
> 

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

[J. Hellenthal via NANOG]

Hope this is 40 business hours

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Apr 5, 2022, at 22:42, Rubens Kuhl  wrote:
> 
> For the inclusion of proxy objects in ALTDB for ARIN-NONAUTH, this is
> the current state of objects among known IRRs:
> 
> 
> source  total obj rt objaut-num obj
> 
> AFRINIC127024  99313   2116
> ALTDB   29342  21385   1481
> APNIC  879374 572495  17737
> ARIN   151087  61535   2461
> ARIN-NONAUTH34334  29291932(* Final
> mirror obtained April 4 *)
> BBOI 1200869 57
> BELL29827  29613105
> CANARIE  1832   1425177
> HOST2  0  1
> IDNIC9301   4886   1845
> JPIRR   13404  11398425
> LACNIC   8008   4742   1039
> LEVEL3 111542  90593300
> NESTEGG 8  4  2
> NTTCOM 453257 444518548
> OPENFACE   25 17  1
> PANIX  42 40  1
> RADB  15943761397813   9077
> REACH   20280  18177  2
> RGNET  80 43  6
> RIPE  1394165 379711  37475
> RIPE-NONAUTH57851  54281   2140
> TC  29936  12207   3703
> WCGDB   65135  62849773None
> 
> 
> Rubens
> 
>> On Mon, Apr 4, 2022 at 12:57 PM Job Snijders via NANOG  
>> wrote:
>> 
>> Dear all,
>> 
>>> On Sat, Apr 02, 2022 at 09:09:58PM +, John Curran wrote:
>>> As previously reported here, ARIN will be shutting down the
>>> ARIN-NONAUTH IRR database on Monday, 4 April 2022 at 12:00 PM ET.
>>> 
>>> It is quite likely that some network operators will see different
>>> route processing as a result of this change, as validation against the
>>> ARIN-NONAUTH IRR database will not longer be possible.
>>> 
>>> Please be aware of this upcoming event and make alternative
>>> arrangements if you are presently relying on upon routing objects in
>>> the ARIN-NONAUTH IRR database.
>> 
>> I ran an analysis just now in which I created an intersection between
>> prefixes observed in the BGP default-free zone and exactly matching
>> route:/route6: objects in ARIN-NONAUTH. I then substracted exact
>> matching objects found in the RADB, ALTDB, TC, NTTCOM, LEVEL3, RIPE, and
>> APNIC IRR sources. The result is a list of routes which might
>> experience service disruptions due to missing IRR objects.
>> 
>> The below 2,749 Prefix + Origin AS pairings are at risk as a result of
>> ARIN shutting down the ARIN-NONAUTH IRR database. Any potential effects
>> are likely to manifest themselves in the coming 24 - 32 hours. Prior to
>> this announcement, ARIN consulted with its community on the future of
>> its IRR service.
>> 
>> I voiced objection and raised concerns about (what appeared to be)
>> limited visibility into what exactly the effects of such a database
>> shutdown would mean for the Internet: 
>> https://lists.arin.net/pipermail/arin-consult/2021-March/001237.html
>> Other community members also shared concerns: 
>> https://lists.arin.net/pipermail/arin-consult/2021-February/001195.html
>> A number of graceful alternative mechanisms were proposed, but not
>> acted upon: 
>> https://lists.arin.net/pipermail/arin-consult/2021-March/001240.html
>> 
>> One might argue "well, folks had more than a year to move their
>> objects!", but on the other hand, it is entirely possible not all the
>> right people were reached, or in cases where affected parties did
>> receive a communication from ARIN, they perhaps were unable to
>> understand the message.
>> 
>> Please check if any of your prefixes are on the below list, and if so,
>> double check whether your IRR administration is able to overcome the
>> disappearance of ARIN-NONAUTH. Godspeed!
>> 
>> This tool might be useful: https://irrexplorer.nlnog.net/
>> 
>> Kind regards,
>> 
>> Job
>> 

Re: "Permanent" DST

[J. Hellenthal via NANOG]

On Thu, Mar 17, 2022 at 12:51:56PM -0700, Owen DeLong via NANOG wrote:
> 
> 
> > On Mar 16, 2022, at 12:24 , Chris Adams  wrote:
> > 
> > Once upon a time, Owen DeLong  said:
> >> You’re right… Two changes to a single file in most cases:
> >> 
> >> 1. Set the correct new timezone (e.g. MST for California).
> > 
> > And now your system displays wrong info 100% of the time, since as I
> > understand it, the zones will be changed (e.g. for me, CST will change
> > from UTC-0600 to UTC-0500).  How will you distinguish between "old" MST
> > and "new" MST when you see it listed?
> 
> As I said, if necessary for your situation, rename the appropriate file and 
> then keep
> the TZ name and simply change the DST on/off flag to off.

that'll be done by most major distribution without thought.

> 
> Owen
> 

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Dropping support for the .ru top level domain

[J. Hellenthal via NANOG]

Thank you for you're support.?.


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Mar 12, 2022, at 04:47, Patrick Bryant  wrote:
> 
> I don't like the idea of disrupting any Internet service. But the current 
> situation is unprecedented.
> 
> The Achilles Heel of general public use of Internet services has always been 
> the functionality of DNS. 
> 
> Unlike Layer 3 disruptions, dropping or disrupting support for the .ru TLD 
> can be accomplished without disrupting the Russian population's ability to 
> access information and services in the West.
> 
> The only countermeasure would be the distribution of Russian national DNS 
> zones to a multiplicity of individual DNS resolvers within Russia. Russian 
> operators are in fact implementing this countermeasure, but it is a slow and 
> arduous process, and it will entail many of the operational difficulties that 
> existed with distributing Host files, which DNS was implemented to overcome. 
> 
> The .ru TLD could be globally disrupted by dropping the .ru zone from the 13 
> DNS root servers. This would be the most effective action, but would require 
> an authoritative consensus. One level down in DNS delegation are the 5 
> authoritative servers. I will leave it to the imagination of others to 
> envision what action that could be taken there...
> 
> ru  nameserver = a.dns.ripn.net
> ru  nameserver = b.dns.ripn.net
> ru  nameserver = d.dns.ripn.net
> ru  nameserver = e.dns.ripn.net
> ru  nameserver = f.dns.ripn.net
> 
> The impact of any action would take time (days) to propagate.
> 

Re: Cogent cutting links to Russia?

[J. Hellenthal via NANOG]

Yet another trash understanding from Jeff.

Give it a break dude!

-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Mar 7, 2022, at 09:07, Masataka Ohta  
> wrote:
> 
> JeffP wrote:
> 
>> Actually, try this:
>> https://home.treasury.gov/news/press-releases/jy0628
> 
> Are you saying "sanctioning numerous Russian elites and their
> family members" has something to do with NANOG?
> 
>   Masataka Ohta

Re: Russia to disconnect from global Internet

[J. Hellenthal via NANOG]

This whole convo is out of hand for this list

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 6, 2022, at 18:36, Jorge Amodio  wrote:
> 
> 
> 
> kick your leader out of the window first ...
> - Elon
> 
>> On Sun, Mar 6, 2022 at 5:54 PM Jay Hennigan  wrote:
>> Dear Elon:
>> 
>> Us next?
>> 
>> - Russian citizens
>> 
>> > 

Re: Get in touch with Cloudflare

[J. Hellenthal via NANOG]

There are a couple to a few that lurk here. Give it a few hours.

This list is a lot less volume than they have on the interim communications.

-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Feb 28, 2022, at 08:52, Oskar Borgqvist via NANOG  wrote:
> 
> Hi
> 
> We have tried to get hold of cloudflare because we have migrated from one ASN 
> to another.
> 
> We have tried with the contact information that is public (peeringdb). We 
> have been waiting for several weeks without a response.
> 
> Would have appreciated if anyone here could have helped us with this.
> 
> With kind regards,
> Oskar Borgqvist
> Bahnflow AB

Re: Authoritative Resources for Public DNS Pinging

[J. Hellenthal via NANOG]

Huh


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Feb 11, 2022, at 09:10, Tom Beecher  wrote:
> 
> I am disappointed but not surprised to see this discussion on NANOG. 
> Encouraging Users to use a tool (that is often ignored by the hardware 
> targeted) by providing a non-revenue-creating special target does not make 
> business sense.
> 
> To be fair, I don't think this is unique to this community. Plenty of 
> conversations on the IETF lists that are fundamentally the same. ( Proposals 
> to change X or implement standard Y to solve something that is already 
> solvable with current tech and standards. ) Really it's just the complexity 
> of the existing solution that's different. :) 
> 
> On Fri, Feb 11, 2022 at 9:51 AM james.cut...@consultant.com 
>  wrote:
> On Feb 11, 2022, at 8:33 AM, Tom Beecher  wrote:
>> 
>> The prediciate assumption that "pinging one destination is a valid check 
>> that my internet works' is INCORRECT. There is no magical unicorn that could 
>> be built that could make that true, and 'they're gonna do it anyways' is a 
>> poor excuse to even consider it. 
>> 
> 
> The predicate assumption that unsuccessful pinging one destination is a valid 
> check that my internet DOES NOT work' is  ALSO INCORRECT. Still no magical 
> unicorn. 
> 
> I am disappointed but not surprised to see this discussion on NANOG. 
> Encouraging Users to use a tool (that is often ignored by the hardware 
> targeted) by providing a non-revenue-creating special target does not make 
> business sense.
> 
> An allied issue is educating ‘Users’ about traceroute AKA sequential ping 
> with TTL progression:
> 
>   •  Seeing missing or excessively long traceroute results from 
> intermediate nodes does NOT indicate a real problem, especially when the 
> target node is reachable with acceptable delay. 
> 
> I’ve lost count of my replies on user forums explaining this issue, even to 
> otherwise well educated users. 
> 
> To be blunt, browsing to amazon.com, apple.com or another vendor site is a 
> simple and easy to teach Internet aliveness check and, at least, offers the 
> chance for the targeted vendor site to receive revenue from sales. I have no 
> crisis of conscience from clicking an vendor shortcut for a basic end-to-end 
> Internet functional test. Or for teaching a User to do the same. This meets 
> the business purpose locally and requires no $pecial effort from Users, 
> network providers, or target systems. This precludes memorization of IP 
> addresses by end Users thus reducing the offered load from the likes of 
> excessive ping 8.8.8.8. 
> 
> I would expect NANOG members to have favorite ping target addresses based on 
> their environment, e.g., default router and a few designated targets. These 
> are useful for manual debugging but, as mentioned previously, are not 
> suitable as singular input to network monitoring.

Re: Authoritative Resources for Public DNS Pinging

[J. Hellenthal via NANOG]

Not to mention. It is viable traffic to monitor, if I know that I get X
number of icmp traffic through a point in tranfer consistently and that
starts to drop off considerably that it may be a failing connection due
to some circumstance I should start checking that equipment.

And if im that connection in the middle... that is money !

On Wed, Feb 09, 2022 at 03:02:19PM +, J. Hellenthal wrote:
> 
> Just think of all the smokeping probes that are out there plus services
> like UptimeRobot and similiar.
> 
> you can't just put something up as a provider of a service and say ...
> ya know im not going to plan for this... traffic for them of any kind is
> money... not only to them but to their IX's as well.
> 
> ya just don't willy nilly cut that shit down and not expect a huge
> blowup to happen.
> 
> On Wed, Feb 09, 2022 at 03:53:15PM +0100, Łukasz Bromirski wrote:
> > 
> > Yup. And Google folks accounted for the world pinging them all day long.
> > 
> > I wouldn't call using DNS resolvers as best "am I connected to internet 
> > over this interface" tool though. A day, year or 5 years from now the same 
> > team may decide to drop/filter and then thousands of hardcoded "handmade 
> > automation solutions" will break. And I believe that's closer to what 
> > Masataka was trying to convey.
> > 
> > — 
> > Łukasz Bromirski
> > 
> > > On 9 Feb 2022, at 14:23, Mark Tinka  wrote:
> > > 
> > >> On 2/9/22 15:00, Masataka Ohta wrote:
> > >> 
> > >> 
> > >> Wrong. It is not bad, at least not so bad, pinging properly
> > >> anycast DNS servers.
> > >> 
> > >> The point of anycast is resistance to DDoS.
> > >> 
> > >> But, relying on hard coded 8.8.8.8 is not a good idea because
> > >> DNS service of the address may be terminated.
> > >> 
> > >> Instead, properly anycast root name servers are authoritative
> > >> resources provided for public DNS queries which can be used for
> > >> pinging, though pinging so with ICMP should be less painful
> > >> for the servers.
> > > 
> > > That's like saying you won't have an egg for dinner because it's 
> > > typically had for breakfast.
> > > 
> > > Users don't care what infrastructure has been designated for. If they can 
> > > find another use for it other than designed, which serves their 
> > > interests, they will use it.
> > > 
> > > We need to allow, and account, for that.
> > > 
> > > Mark.
> 
> -- 
> The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
> lot about anticipated traffic volume.



-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Authoritative Resources for Public DNS Pinging

[J. Hellenthal via NANOG]

Anyone willing to write a icmp(8/0) concatenation/concentration/proxy tool ? 
That can be deployed at the provider edge ?

Catch all the packets !!!

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Feb 8, 2022, at 21:18, Mike Hammett  wrote:
> 
> 
> What irked me today was an equipment manufacturer. I found out because Google 
> had some issues handling ICMP to their DNS resolvers today and some of my 
> devices started spazzing out.
> 
> There's no reason this manufacturer doesn't just setup a variety their own 
> servers to handle this, other than being lazy.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> 
> Midwest Internet Exchange
> 
> The Brothers WISP
> 
> From: "Mark Delany" 
> To: "NANOG" 
> Sent: Tuesday, February 8, 2022 5:13:30 PM
> Subject: Re: Authoritative Resources for Public DNS Pinging
> 
> On 08Feb22, Mike Hammett allegedly wrote:
> 
> > Some people need a clue by four and I'm looking to build my collection of 
> > them. 
> 
> > "Google services, including Google Public DNS, are not designed as ICMP 
> > network testing services"
> 
> Hard to disagree with "their network, their rules", but we're talking about 
> an entrenched,
> pervasive, Internet-wide behaviorial issue.
> 
> My guess is that making ping/ICMP less reliable to the extent that it becomes 
> unusable
> wont change fundamental behavior. Rather, it'll make said "pingers" reach for 
> another tool
> that does more or less the same thing with more or less as little extra 
> effort as possible
> on their part.
> 
> And what might such an alternate tool do? My guess is one which SYN/ACKs 
> various popular
> TCP ports (say 22, 25, 80, 443) and maybe sends a well-formed UDP packet to a 
> few popular
> DNS ports (say 53 and 119). Let's call this command "nmap -sn" with a few 
> tweaks, shall
> we?
> 
> After all, it's no big deal to the pinger if their reachability command now 
> exchanges
> 10-12 packets with resource intensive destination ports instead of a couple 
> of packets to
> lightweight destinations. I'll bet most pingers will neither know nor care, 
> especially if
> their next-gen ping works more consistently than the old one.
> 
> So. Question. Will making ping/ICMP mostly useless for home-gamers and lazy 
> network admins
> change internet behaviour for the better? Or will it have unintended 
> consequences such as
> an evolutionary adaptation by the tools resulting in yet more unwanted 
> traffic which is
> even harder to eliminate?
> 
> 
> Mark.
> 

Re: Request to participate in 2-min study survey on IPv6 Adoption

[J. Hellenthal via NANOG]

That's just plain as* bullsh** right there.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 30, 2022, at 19:09, Töma Gavrichenkov  wrote:
> 
> 
> Peace,
> 
>> On Thu, Jan 27, 2022, 4:38 PM Smahena Amakran  
>> wrote:
>> For my studies, I am researching IPv6 adoption.
> 
> 
> For your consideration, there's one thing that's always overlooked.
> 
> E.g. I've been talking once to a big employee of a large content provider, 
> and that person told me they don't enable IPv6 because doing otherwise 
> produces tons of comment spam.
> 
> The thing is, we have this spam problem. This is not really the "information 
> security issue" you've mentioned, this is just a glimpse of a real issue.
> 
> IPv6 is now cheap as chips. It's very dirty therefore. All kinds of bots, 
> spammers, password brute force programs live in there, and it's significantly 
> harder to correlate and ditch these with the sparse IPv6 address space.
> 
> ISPs don't typically focus on these kinds of things but ISPs, speaking of 
> large ones, are also typically champions in IPv6 deployment.  It's usually 
> content providers who don't do their stuff.  And, as sad as it gets, it's not 
> getting away any time soon since it's there for a reason.
> 
> --
> Töma

Re: [EXTERNAL] Happy Holidays

[J. Hellenthal via NANOG]

HH -

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Dec 22, 2021, at 17:13, Mann, Jason via NANOG  wrote:
> 
> 
> Same to everyone out there!!
>  
> From: NANOG  On Behalf Of Nanog News
> Sent: Wednesday, December 22, 2021 3:17 PM
> To: nanog-annou...@nanog.org; nanog@nanog.org
> Subject: [EXTERNAL] Happy Holidays
>  
> Wishing you + yours a very warm holiday season from NANOG. 

Re: Theorical question about cyclic dependency in IRR filtering

[J. Hellenthal via NANOG]

Coin phrase ... IRR (dedup)

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Nov 29, 2021, at 07:17, Job Snijders via NANOG  wrote:
> 
> 
> Hi Anurag,
> 
> Circular dependencies definitely are a thing to keep in mind when designing 
> IRR and RPKI pipelines!
> 
> In the case of IRR: It is quite rare to query the RIR IRR services directly. 
> Instead, the common practise is that utilities such as bgpq3, peval, and 
> bgpq4 query “IRRd” (https://IRRd.net) instances at for example whois.radb.net 
> and rr.ntt.net. You can verify this with tcpdump. These IRRd instances serve 
> as intermediate caches, and will continue to serve old cached data in case 
> the origin is down. This phenomenon in the global IRR deployment avoids a lot 
> of potential for circular dependencies.
> 
> Also, some organisations use threshold checks before deploying new IRR-based 
> filters to reduce risk of “misfiring”.
> 
> 
> The RPKI case is slightly different: the timers are far more aggressive 
> compared to IRR, and until “Publish in Parent” (RFC 8181) becomes common 
> place, there are more publication points, thus more potential for operators 
> to paint themselves into a corner.
> 
> Certainly, in the case of RPKI, all Publication Point (PP) operators need to 
> take special care to not host CAs which have the PP’s INRs listed as 
> subordinate resources inside the PP.
> 
> See RFC 7115 Section 5 for more information: “Operators should be aware that 
> there is a trade-off in placement of an RPKI repository in address space for 
> which the repository’s content is authoritative. On one hand, an operator 
> will wish to maximize control over the repository. On the other hand, if 
> there are reachability problems to the address space, changes in the 
> repository to correct them may not be easily access by others”
> 
> Ryan Sleevi once told me: "yes, it strikes me that you should prevent 
> self-compromise from being able to perpetually own yourself, by limiting an 
> attacker’s ability to persist beyond remediation."
> 
> A possible duct tape approach is outlined at  
> https://bgpfilterguide.nlnog.net/guides/slurm_ta/
> However, I can’t really recommend the SLURM file approach. Instead, RPKI 
> repository operators are probably best off hosting their repository *outside* 
> their own address space.
> 
> Just like with Authoritative DNS servers, make sure you also can serve your 
> records via a competitor! :-)
> 
> For example, if ARIN moved one of their three publication point clusters into 
> address space managed by any of the other four RIRs, some risk would be 
> reduced.
> 
> Kind regards,
> 
> Job
> 
>> On Mon, 29 Nov 2021 at 13:37, Anurag Bhatia  wrote:
>> Hello everyone, 
>> 
>> While discussing IRR on some groups recently, I was thinking if there can be 
>> (and if there is) cycling dependency in filtering where IRR (run by whoever 
>> APNIC, RIPE, RADB etc) uses some upstream and accepts only routes with 
>> existing & valid route object. 
>> 
>> 
>> 
>> So hypothetical case (can apply to any IRR): 
>> 
>> APNIC registry source is whois.apnic.net and points to 202.12.28.136 / 
>> 2001:dc0:1:0:4777::136. The aggregate of both these has a valid route object 
>> at the APNIC registry itself. 
>> 
>> Their upstreams say AS X, Y and Z have tooling in place to generate and push 
>> filters by checking all popular IRRs. All is well till this point. 
>> 
>> Say APNIC has some server/service issue for a few mins and X Y and Z are 
>> updating their filters at the same time. They cannot contact whois.apnic.net 
>> and hence miss generating filters for all APNIC IRR hosted prefixes. 
>> 
>> X, Y and  Z drop APNIC prefixes including those of IRR & the loop goes on 
>> from this point onwards. 
>> 
>> So my question is: Can that actually happen? 
>> If not, do X, Y and Z and possible all upstreams till default-free zone 
>> treat these prefixes in a special manner to avoid such loop in resolution? 
>> 
>> 
>> 
>> 
>> Thanks! 
>> 
>> -- 
>> Anurag Bhatia
>> anuragbhatia.com

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[J. Hellenthal via NANOG]

Just replying to Joe's post here to add a little more context to at least one 
of the problems that will certainly appear if this would come about.

FreeBSD operators have been using this space for quite a long time for many 
NAT'ing reasons including firewalls and other services behind them for jail 
routing and such.

https://dan.langille.org/2013/12/29/freebsd-jails-on-non-routable-ip-addresses/

That's just one example that I've seen repeated in multiple other ways. One of 
which a jail operator with about 250 addresses out of that range that enabled 
his jail routed services.

Of course that can be changed but really for just this small of a influx of 
addresses ? Seems really wasteful to me.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Nov 20, 2021, at 23:54, Joe Maimon  wrote:
> 
> 
> Jay Hennigan wrote:
>>> On 11/19/21 10:27, William Herrin wrote:
>>> Howdy,
>>> That depends on your timeline. Do you know many non-technical people
>>> still using their Pentium III computers with circa 2001 software
>>> versions? Connected to the Internet?
>> 
>> There are lots of very old networked industrial machines with embedded 
>> computers operated by non-network-savvy people that are still very much in 
>> use.
>> 
>> Think CNC machines in machine shops, SCADA systems, etc. I wouldn't be a bit 
>> surprised to find quite a few 2001-era boxes still in service.
> In the context of re-purposed IPv4 address scopes specialized equipment will 
> tend to be fairly limited in its communication needs and unlikely to be 
> affected.
> 
> I certainly hope they are, otherwise the security implications are severe.
> 
> How about we recast this as general purpose internet communicating platforms 
> likely to have occasion to interact with these re-purposed addresses are 
> nearly certain to undergo an upgrade or more over the next decade, or how 
> many non-technical people are still using the original wrtg platform to 
> connect them to the internet?
> 
> And yes, its quite possible that even then those addresses may have some more 
> baggage than the typical IPv4 block in use today (which are hardly clean 
> bills of health more often than not).
> 
> But the sooner the effort begins the more likely the utilitarian value will 
> be there if or when its needed.
> 
> Joe

Re: Need for historical prefix blacklist (`rogue' prefixes) information

[J. Hellenthal via NANOG]

He answered it completely. "You" worried about interception of RPKI exchange 
over the wire are failing to see that there is nothing there important to 
decrypt because the encryption in the transmission is not there !

And yet you've failed to even follow up to his question... "What's your point 
regarding your message? ROV does not use (nor needs) encryption."

So maybe you could give some context on that so someone can steer you out of 
the wrong direction.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 30, 2021, at 10:31, A Crisan  wrote:
> 
> 
> Hi Matthew, 
> 
> Quantum computing exists as POCs, IBM being one of those advertising them and 
> announced to extend their project. There are others on the market, Amazon 
> advertised quantum computing as a service back in 2019: 
> https://www.theverge.com/2019/12/2/20992602/amazon-is-now-offering-quantum-computing-as-a-service.
>  The bottle neck of the current technology is scalability: we will not see QC 
> as personal computing level just yet (to go in more detail, current 
> technologies work at cryogenic temperatures, thus they are hyper expensive 
> and not really scalable), but they exist and one could be imagine they 
> are/will be used for various tasks.
> 
> On the other hand, you've actually commented every word of my mail, minus the 
> stated question. Thanks. 
> 
> Best Regards, 
> Dora Crisan 
> 
> 
> 
>  
> 
>> On Fri, Oct 29, 2021 at 8:10 PM Matthew Walster  wrote:
>> 
>> 
>>> On Fri, 29 Oct 2021, 15:55 A Crisan,  wrote:
>>> Hi Matthew,
>>> I was reading the above exchange, and I do have a question linked to your 
>>> last affirmation. To give you some context, the last 2021 ENISA report seem 
>>> to suggest that internet traffic is "casually registered" by X actors to 
>>> apply post Retrospective decryption (excerpt below). This would be at odds 
>>> with your (deescalating) affirmation that hijacks are non-malicious and 
>>> they are de-peered quickly, unless you pinpoint complete flux arrest only. 
>>> Are there any reportings/indicators... that look into internet flux 
>>> constant monitoring capabilities/capacities? Thanks.
>> 
>> 
>> RPKI uses authentication not confidentiality. There is no encryption taking 
>> place, other than the signatures on the certificates etc.
>> 
>>> Excerpt from the introduction: "What makes matters worse is that any cipher 
>>> text intercepted by an attacker today can be decrypted by the attacker as 
>>> soon as he has access to a large quantum computer (Retrospective 
>>> decryption).
>> 
>> 
>> Which do not exist (yet).
>> 
>>> Analysis of Advanced Persistent Threats (APT) and Nation State capabilities,
>> 
>> 
>> Buzzwords.
>> 
>>> along with whistle blowers’ revelations
>> 
>>>  have shown that threat actors can and are casually recording all Internet 
>>> traffic in their data centers
>> 
>> 
>> No they're not. It's just not possible or indeed necessary to duplicate 
>> everything at large scale. Perhaps with a large amount of filtering, certain 
>> flows would be captured, but in the days of pervasive TLS, this seems less 
>> and less worthwhile.
>> 
>>>  and that they select encrypted traffic as interesting and worth 
>>> storing.This means that any data encrypted using any of the standard 
>>> public-key systems today will need to be considered compromised once a 
>>> quantum computer exists and there is no way to protect it retroactively, 
>>> because a copy of the ciphertexts in the hands of the attacker. This means 
>>> that data that needs to remain confidential after the arrival of quantum 
>>> computers need to be encrypted with alternative means"
>> 
>> 
>> None of this is relevant to RPKI (ROV) at all. In fact, it reads like the 
>> fevered dreams of a cyber security research student. What's your point 
>> regarding your message? ROV does not use (nor needs) encryption.
>> 
>> M
>> 

Re: Safe Geo-location Defaults

[J. Hellenthal via NANOG]

I'd agree with that wholly. I've had a drunk couple show up at my place years 
back insisting I had her phone. Once the guy tried to push through the door he 
got the business end of good ole Louie and a cute little breaking and entering 
sentence at a vacation destination known as lockup 浪

With enough said if this was a business location or courthouse it may have 
saved them a little gas and time getting there, and myself not having to wake 
up so damn late.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 21, 2021, at 09:02, Sean Donelan  wrote:
> 
> Has anyone published "safe" geo-location defaults? By safe I mean default 
> lat/lon coordinates for a country, state/province, city, postal code which do 
> not resolve near a residence.
> 
> It seems like too many people use "Find My " or other geo-location 
> services, and then go to the exact location shown on the mapping service for 
> the default lat/lon which is often a default location.  Knock on the person 
> which happens to live near the default centroid, and acuse them of stealing 
> their  because "Find My " showed that location.
> 
> 
> 

Re: Linux WiFi Package Issues

[J. Hellenthal via NANOG]

Shrug... almost straight to junk 

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 12, 2021, at 08:02, Pascal Masha  wrote:
> 
> 
> Hello All,
> 
> I have been wondering whether there is any known issue with the Linux WiFi 
> package since the last 3 days or so? I'm Ubuntu 20.04.3 LTS 64bit Distro and 
> WiFi has been dropping almost every 5 minutes. A colleague on another Linux 
> Disto also contacted me about the same thing. Has anyone in the community 
> experienced the same issue?
> 
> Regards
> Paschal Masha

Re: DNS pulling BGP routes?

[J. Hellenthal via NANOG]

They most likely sent an update to the DNS servers for TLV DNSSEC and in 
oversight forgot they needed to null something's out of the workbook to not 
touch the BGP instances.

I'd hardly believe that would be triggered by the dns server itself.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 6, 2021, at 12:45, Michael Thomas  wrote:
> 
> So if I understand their post correctly, their DNS servers have the ability 
> to withdraw routes if they determine are sub-optimal (fsvo). I can certainly 
> understand for the DNS servers to not give answers they think are unreachable 
> but there is always the problem that they may be partitioned and not the 
> routes themselves. At a minimum, I would think they'd need some consensus 
> protocol that says that it's broken across multiple servers.
> 
> But I just don't understand why this is a good idea at all. Network topology 
> is not DNS's bailiwick so using it as a trigger to withdraw routes seems 
> really strange and fraught with unintended consequences. Why is it a good 
> idea to withdraw the route if it doesn't seem reachable from the DNS server? 
> Give answers that are reachable, sure, but to actually make a topology 
> decision? Yikes. And what happens to the cached answers that still point to 
> the supposedly dead route? They're going to fail until the TTL expires anyway 
> so why is it preferable withdraw the route too?
> 
> My guess is that their post while more clear that most doesn't go into enough 
> detail, but is it me or does it seem like this is a really weird thing to do?
> 
> Mike
> 
> 
>> On 10/5/21 11:56 PM, Bjørn Mork wrote:
>> Masataka Ohta  writes:
>> 
>>> As long as name servers with expired zone data won't serve
>>> request from outside of facebook, whether BGP routes to the
>>> name servers are announced or not is unimportant.
>> I am not convinced this is true.  You'd normally serve some semi-static
>> content, especially wrt stuff you need yourself to manage your network.
>> Removing all DNS servers at the same time is never a good idea, even in
>> the situation where you believe they are all failing.
>> 
>> The problem is of course that you can't let the servers take the
>> decision to withdraw from anycast if you want to prevent this
>> catastrophe.  The servers have no knowledge of the rest of the network.
>> They only know that they've lost contact with it.  So they all make the
>> same stupid decision.
>> 
>> But if the servers can't withdraw, then they will serve stale content if
>> the data center loses backbone access. And with a large enough network
>> then that is probably something which happens on a regular basis.
>> 
>> This is a very hard problem to solve.
>> 
>> Thanks a lot to facebook for making the detailed explanation available
>> to the public.  I'm crossing my fingers hoping they follow up with
>> details about the solutions they come up with.  The problem affects any
>> critical anycast DNS service. And it doesn't have to be as big as
>> facebook to be locally critical to an enterprise, ISP or whatever.
>> 
>> 
>> 
>> Bjørn

Re: FYI: NANOG and ICANN

[J. Hellenthal via NANOG]

You mean they could not come together enough to share even the same page yet 
even a domain name or central corporation to oversee these needs ?

Personally I'm calling partially "bullshit" the Matthew McConaughey way!

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 4, 2021, at 09:33, Patrick W. Gilmore  wrote:
> 
> NANOG’s version: 
> https://www.nanog.org/stories/nanog-signs-a-memorandum-of-understanding-with-internet-society-icann/
> 
> -- 
> TTFN,
> patrick
> 
> 
>> On Oct 4, 2021, at 4:42 AM, Hank Nussbacher  wrote:
>> 
>> https://www.icann.org/en/announcements/details/icann-signs-a-memorandum-of-understanding-with-nanog-27-9-2021-en
>> 
>> Regards,
>> Hank
> 

Re: The great Netflix vpn debacle! (geofeeds)

[J. Hellenthal via NANOG]

Also don't get a smart litterbox... ;-)

Yeah that's a thing and connects to the local Wi-Fi. Kinda want to DMZ that 
mutha and wait for a script kiddie to turn one of my cats upside down...

dubs litter-robot.com

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Aug 31, 2021, at 19:16, Jay Hennigan  wrote:
> 
> On 8/31/21 16:32, Jeroen Massar via NANOG wrote:
> 
>> Fun part being that it is hard to get a Dumb TV... though that is primarily 
>> simply because of all the tracking non-sense in them that makes them 
>> 'cheaper'... (still wonder how well that tracking stuff complies with GDPR, 
>> I am thinking it does not ... Schrems anyone? :) )
> 
> Just get a "smart" TV, don't connect it to the Internet, and use its HDMI 
> ports for your cable box, Apple TV, etc. and/or antenna input for local 
> off-air reception.
> 
> -- 
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV

Re: netflow in the core used for surveillance

[J. Hellenthal via NANOG]

Im finding this really hard to believe for the "Team Cymru" part at least. 
Being originally a provider of security centric configuration of network 
components... IOS ... Juniper etc... and maintaining such a high standard for 
years that they turn foot and resell/sell data on customer traffic obtained 
from other networks they themself are a customer of for resale of data. This 
feels like a hit job on a company that secures more than it insecures by gov't 
passage.

Not trying to start a flame war here but... what do you do to your most secure 
threat? (That has financial and influential aspects)... 


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Aug 25, 2021, at 16:13, Randy Bush  wrote:
> 
> https://www.vice.com/en/article/jg84yy/data-brokers-netflow-data-team-cymru
> 
> used to get dissidents, activists, and journos killed
> 
> at, comcast, ... zayo, please tell us you do not do this.
> 
> randy

Re: google fi outage?

[J. Hellenthal via NANOG]

Can confirm t-mobile as working in south east wi

> On May 28, 2021, at 08:23, Dan Walters via NANOG  wrote:
> 
> 
> Just figured id let everyone know if they haven’t seen yet that at least in 
> the WI area the only working carrier for fi right now is T-Mobile. The rest 
> will assign the wrong phone numbers to the activated sim.
> 

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[J. Hellenthal via NANOG]

Nail -> Head <- Hammer

Well put ! I don’t know if it could have been put better than that.

-- 
J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 23, 2021, at 10:57, Emil Pfeffer  wrote:
> 
> On Tue, Mar 23, 2021 at 09:20:14AM -0500, Mike Hammett wrote:
>> "But why it should or shouldn't be clicked..."
>> Sorta like most man pages.
> 
> They both need prior knowledge to use. 
> We tend to simplify things in order to save time but then the new generation 
> comes
> in and thinks the simple things it's all there is and have no willingness to 
> go
> back in time and accumulate "useless" knowledge. It is useless because the 
> problems
> it fixes were already fixed but it is paramount in understanding whats behind 
> the 
> simple things. Knowledge can only be simplified so much and there's no 
> shortcut to
> accumulating it. (hence why most people will prefer to just use the tools)
> 
> The generational gap is not an issue it is how things need to be. The network
> engineering the younger generation deals with is not the same networking the 
> old
> generation deals with but built upon this old networks. This two generations 
> do
> not need the same knowledge and it is in each others best interest that they 
> stay
> separated. Although we would gladly help someone that is obviously putting in 
> the
> effort and is looking to learn we have not volunteered to be teachers and 
> some people
> need to understand that we prefer to keep it simple because we have no time 
> to waste.
> 
> It is easy to believe that the method you are using is the one but eventually
> the good ones will have to pass the test of time which mailling lists and a 
> plethora
> of the old tools successfully did. 
> --

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[J. Hellenthal via NANOG]

Can we end this troll here

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 20, 2021, at 20:48, Eric Kuhnke  wrote:
> 
> 
> It's one thing to use a GUI tool when it's convenient and quick. I think 
> anyone that's ever experienced setting up a Unifi controller would probably 
> prefer provisioning a new 802.11ac AP from the GUI rather than doing it 
> manually at a command line. 
> 
> But it's another thing to consider that we have a whole new generation of 
> people who don't know and don't care what's going underneath the GUI and 
> might not be able to do anything with the OS running on bare metal, if they 
> have to. 
> 
> If we intend to abstract away configuring devices to a GUI level only and not 
> care about what's going on under the hood, then it's time for everyone to 
> just run out and renew their MCSE certifications and buy Meraki subscriptions.
> 
> 
> 
>> On Sat, Mar 20, 2021 at 6:35 PM David Siegel  wrote:
>> 
>> ...not to mention that all mature networks are moving more towards GUI front 
>> ends for their automated network.  As the complexity of a network increases, 
>> CLI access becomes considerably more risky.
>> 
>> The idea that "real engineers use the CLI" is dinosaur thinking that will 
>> eventually land those with that philosophy out of a job.  Just my personal 
>> $.02 (though I'm certainly not alone in my opinion).
>> 
>> But I'd like to reiterate that the board's goal with modernization is not to 
>> alienate anyone from the existing community by forcing them into a 
>> web-interface.  Discourse is under evaluation, and if it doesn't accomplish 
>> the goal we'll try something else or build our own tool.
>> 
>> Dave
>> 
>> 
>> 
>> 
>>> On Sat, Mar 20, 2021 at 6:52 PM Matthew Petach  
>>> wrote:
>>> 
>>> 
>>> On Sat, Mar 20, 2021 at 5:13 PM scott  wrote:
>>> [...] 
>>>>  Of course, one would 
>>>> not find an HTTP GUI on the bigger networks dealt with on this list; 
>>>> only on the tiny networks.  So they're beginning learners and are, of 
>>>> course, welcome.  They will lean a lot, just as I did in the early days 
>>>> and do every day now days.
>>> [...] 
>>>> scott
>>> 
>>> Let's see...
>>> Google: Gmail
>>> Microsoft: Hotmail/Outlook/Office365
>>> Yahoo/VerizonMedia: Yahoo Mail
>>> 
>>> I'd have to say, there's some pretty big networks on this list that 
>>> use HTTP GUIs for their email.
>>> 
>>> Of course, you might be big enough that you look down on the 
>>> networks of Google, Microsoft, and VZM as "tiny networks" -- in 
>>> which case, you're definitely entitled to your opinion, as all 8000
>>> pound gorillas that look down on the puny 800 lb gorillas are.  ;)
>>> 
>>> Matt
>>>  

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[J. Hellenthal via NANOG]

Here here !

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 20, 2021, at 19:13, scott  wrote:
> 
> 
> :: The board has been thinking about enhancements to the NANOG list for a 
> couple of years now
> 
> Please let me put in my $0.02.  I would like to ask that there're no changes. 
>  For myself, it has been 24 years here and I see no problems.  I enjoy the 
> off-topic as much as the on-topic...most times.  If a person can't figure out 
> how to filter out a subject or sender in an email client they will have way 
> more problems trying to be a network engineer on anything but the tiniest of 
> networks.  I would think a person who can't figure out how use filters on a 
> mail client would rather configure routers through the HTTP GUI, rather than 
> the CLI.  Of course, one would not find an HTTP GUI on the bigger networks 
> dealt with on this list; only on the tiny networks.  So they're beginning 
> learners and are, of course, welcome.  They will lean a lot, just as I did in 
> the early days and do every day now days.
> 
> In agreement with others here, randy's comment:
> 
> "i do not find the volume or diversity on the nanog list problematic.
> in fact, i suspect its diversity and openness are major factors in
> it being the de facto global anything-ops list.  perhaps we do not
> need to fix that."
> 
> Is spot on.
> 
> And last, John Covici also hit the nail on the head and all network engineers 
> will recognize his comment "Keep it simple, please" as a very nice way of 
> saying KISS, which any network engineer who has had time on a network will 
> realize as the basic design principle.
> 
> scott
> 

Re: Saudi Arabia

[J. Hellenthal via NANOG]

ROFL 

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 18, 2021, at 11:54, Randy Bush  wrote:
> 
> 
>> 
>> https://www.itc.sa/en/
> 
> mehmet, you actually answered rod's question.  that is not allowed on
> the nanog list.  you need to start a 20 message thread excoriating him
> for asking for actual operational help finding a circuit in a difficult
> place.
> 
> what is this world coming to?  sheesh!
> 
> randy
> 
> ---
> ra...@psg.com
> `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
> signatures are back, thanks to dmarc header butchery

Re: Cable Landing Station Address

[J. Hellenthal via NANOG]

Can you talk to …. Mehmet Akcin meh...@akcin.net “copied in” or someone he may 
be able to refer you to ?



https://www.infrapedia.com/app/cls/vung-tau-vnpt



> On Mar 10, 2021, at 08:13, Rod Beck  wrote:
> 
> Vung Tau


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

Re: Network / Infrastructure security testing services

[J. Hellenthal via NANOG]

Huh

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 9, 2021, at 13:57, Nathanael Cariaga  wrote:
> 
> 
> Apologies for this shameless plug, but wanted to ask if any folks on this 
> list who does network/infrastructure security testing? Please to reach back 
> to me off the list.   
> 
> Thank you for your time.
> 

Re: gnail rejecting logwatch reports

[J. Hellenthal via NANOG]

Rejected with what error codes? 

Let’s carry this off list ... can you send through the full headers ?

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 4, 2021, at 11:11, jimmy keffer  wrote:
> 
> i have a server that use gmail for smtp it working excpt its rejecting
> my  logwatch reports other mail is sending fine the reject page at
> google is no help
> thanks jimmy

Re: Suspicious IP reporting

[J. Hellenthal via NANOG]

Sorry wasn’t meant directly aimed at you… unless you are the same person \?

> On Feb 5, 2021, at 09:12, J. Hellenthal  wrote:
> 
> And just like deploying IoT devices in vehicles without proper security 
> preparations will lead you to a C network … just saying the hammer swings 
> both ways here and getting a IP reported isn’t going to do you any damn good 
> at ALL.
> 
> Personally I’d rip those IoT vehicles off the market for a recall but I 
> suspect we’ll be hearing of that in the not to distant future.
> 
> So in hindsight why don’t we just close down this thread here.
> 
>> On Feb 5, 2021, at 08:50, Joe  wrote:
>> 
>> Much like your banning of an email address is an ability you have with your 
>> provider (gmail), you should have the same abilities with your cellular 
>> provider for an IP address. 
>> I would think (at a minimum) you would be able to negotiate such an action 
>> with them, perhaps it is time to re-negotiate that contract?
>> If your simply trying to report an offending IP for brute force stuff 
>> perhaps the tact you may find more helpful is to ask for a contact at xzy 
>> ISP on list, versus asking folks to do reporting for you. As well there are 
>> like 100s of lists to report this to outside of NANOG  
>> As well, if I am reading this correctly, deployment of devices that have 
>> public facing IPs and do not have a means to protect themselves is 
>> concerning to say the least. 
>> This is about as reckless as putting up a login page without a password and 
>> crying foul when something gains access that you didn't expect. Again, I do 
>> not know all of the details of this so I may be way off base with that 
>> respect. 
>> 
>> If your ability to prevent issues is due to lack of a firewall/control to 
>> your network, possibly asking for help in mitigating such threats would be 
>> better, as there are a lot of very well versed/clever folks that help out.
>> Regards,
>> -Joe
>> 
>> 
>> On Thu, Feb 4, 2021 at 7:17 PM JoeSox  wrote:
>> Ryan,
>> Thanks but like I said these devices are in moving vehicles ok?
>> I stated we have a plan but it is ways out.  
>> FACT: we have a known malicious C
>> FACT: We know what networks it is hitting and the cellular network is the 
>> most vulnerable, imo.
>> FACT: this IP is against Verizon terms of service so the way to address it 
>> is to report it to them as they request.
>> 
>> I honestly got what I needed from this thread, thanks. And I thank the 
>> nonbullies that helped me off list.
>> --
>> Thank You,
>> Joe 
>> 
>> 
>> On Thu, Feb 4, 2021 at 5:11 PM Ryan Hamel  wrote:
>> Joe,
>> 
>> 
>> 
>> It isn’t on Verizon to setup a firewall, especially if you have a direct 
>> public IP service. The device being attached directly to the Internet (no 
>> matter the transmission medium), must be able to protect itself. ISPs 
>> provide routers which function as a NAT/Firewall appliance, to provide a 
>> means of safety and convenience for them, but also charge you a rental fee.
>> 
>> 
>> 
>> Stick a Cradlepoint router or something in front of your device, if you want 
>> an external means of protection. Otherwise you’ll need to enable the Windows 
>> Firewall if it’s a Windows system, or setup iptables on Linux, ipfw/pf on 
>> *BSD, etc.
>> 
>> 
>> 
>> Ryan
>> 
>> 
>> 
>> From: JoeSox  
>> Sent: Thursday, February 4, 2021 5:04 PM
>> To: r...@rkhtech.org
>> Cc: TJ Trout ; NANOG 
>> Subject: Re: Suspicious IP reporting
>> 
>> 
>> 
>> How do I setup a firewall when I am not a Verizon engineer?
>> 
>> There is a firewall via the antivirus and operating system but that's it.
>> 
>> Do you not understand my issue? I thought that is the real problem with the 
>> online bullies in this thread.
>> 
>> --
>> 
>> Thank You,
>> 
>> Joe
>> 
>> 
>> 
>> 
>> 
>> On Thu, Feb 4, 2021 at 5:01 PM Ryan Hamel  wrote:
>> 
>> Joe,
>> 
>> 
>> 
>> The underlying premise here is, “pick your battles”. If you don’t want an IP 
>> address to access your device in anyway, setup a firewall and properly 
>> configure it to accept whitelisted traffic only, or just expose a VPN 
>> endpoint. The Internet is full of both good and bad actors that probe and 
>> scan anything and everything.
>> 
>> 
>> 
>> While some appreciate the notification here, others will find it annoying. 
>> We cannot report

Re: Suspicious IP reporting

[J. Hellenthal via NANOG]

 LOL
> 
> I think if everyone gets off their high horse, the list communication would 
> be less noisy for the list veterans.
> 
> --
> 
> Thank You,
> 
> Joe
> 
>  
> 
>  
> 
> On Thu, Feb 4, 2021 at 4:36 PM TJ Trout  wrote:
> 
> This seems like a highly suspect request coming from a North American network 
> operator...? 
> 
>  
> 
>  
> 
> On Thu, Feb 4, 2021 at 10:23 AM JoeSox  wrote:
> 
>  
> 
> This IP is hitting devices on cellular networks for the past day or so.
> 
>   https://www.abuseipdb.com/whois/79.124.62.86  
> 
> I think this is the info to report it to the ISP.  Any help or if everyone 
> can report it, I would be a happy camper.
> 
>  
> 
> ab...@4cloud.mobi; ab...@fiberinternet.bg
> 
>  
> 
> https://en.asytech.cn/check-ip/79.124.62.25#gsc.tab=0
> 
>  
> 
> --
> 
> Thank You,
> 
> Joe
> 


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

Re: Nice work Ron

[J. Hellenthal via NANOG]

Cool nice work Ron! Maybe a new subject for what this is really about  ...

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 24, 2021, at 13:36, JORDI PALET MARTINEZ via NANOG  
> wrote:
> 
> Again, I'm not saying is the best way, is what the community *decided* 
> before I added a clarification. The 50% was not a change, just to make it 
> explicit, what was the actual interpretation.
> 
> If you don't like it, stop complaining, and send a policy proposal, I could 
> even support it, but I'm not convinced it will reach consensus.
> 
> 
> 
> El 24/1/21 15:34, "NANOG en nombre de Masataka Ohta" 
>  mo...@necom830.hpcl.titech.ac.jp> escribió:
> 
>JORDI PALET MARTINEZ via NANOG wrote:
> 
>> I fully understand what you mean, however, I don’t think this is a
>> problem even if all the RIRs ask for “%50 or even 100%” of usage in
>> the region.
> 
>So, you don't know how most, if not all, ISPs are operating
>their network.
> 
>> That will make your life more complex, as you will need to obtain
> 
>It makes ISP's operations a lot more complex and a lot less
>profitable to be ignored by almost all, if not all, ISPs.
> 
>Your theory that ISPs could have behaved otherwise is not
>helpful in the real world of business and not practically
>acceptable by RIRs mostly consisting of ISPs.
> 
>Masataka Ohta
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the exclusive use of the 
> individual(s) named above and further non-explicilty authorized disclosure, 
> copying, distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited and will be 
> considered a criminal offense. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, even if partially, including attached files, is strictly 
> prohibited, will be considered a criminal offense, so you must reply to the 
> original sender to inform about this communication and delete it.
> 
> 
> 

Re: Alexandria Ocasio-Cortez' Office is on NANOG?? Or, what is the policy about sharing email offlist?

[J. Hellenthal via NANOG]

Yeah he did the same dolt act to me to. Just a really bored dolt looking for 
nonsense with a crush on AOC.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 19, 2021, at 00:40, Javier J  wrote:
> 
> 
> you too, why are you emailing me?
> 
> I didn't ask anyone to contact me off list.
> 
>> On Mon, Jan 18, 2021 at 8:53 PM Sam Silvester  
>> wrote:
>> Archives are browsable by anybody. How do you expect to keep political types 
>> out of the discussion?
>> 
>>> On Tue, 19 Jan 2021 at 11:36 am, Javier J  
>>> wrote:
>>> I couldn't agree more.
>>> If I want to talk politics, I will go to other places. I use this mailing 
>>> list to talk about things relevant to technology and operation of networks 
>>> in North American and other places.
>>> 
>>> - Javier
>>> 
>>> 
>>>> On Mon, Jan 18, 2021 at 4:19 PM Mel Beckman  wrote:
>>>> javier,
>>>> 
>>>> I concur. What we don’t need on Nanog is outside parties deciding to 
>>>> “reign in” our discussions on political grounds!
>>>> 
>>>>  -mel beckman
>>>> 
>>>>> On Jan 18, 2021, at 12:38 PM, Javier J  wrote:
>>>>> 
>>>>> 
>>>>> I agree 100%.
>>>>> 
>>>>> I know the emails on this list are public and that is fine.  What I don't 
>>>>> appreciate is that now my email address is in some politico's address 
>>>>> list because of someone's behavior.
>>>>> 
>>>>> - Javier
>>>>> 
>>>>>> On Mon, Jan 18, 2021 at 3:20 PM Jon Lewis  wrote:
>>>>>> There's a world of difference between "don't expect list posts to be 
>>>>>> private to list members" and "don't forward the list to autoresponders."
>>>>>> The stupidity of the latter, if it can be tracked down to who did it, 
>>>>>> should result in their removal from the list, at least until they 
>>>>>> explain 
>>>>>> what caused them to do that and have undone it.
>>>>>> 
>>>>>> On Mon, 18 Jan 2021, Paul Timmins wrote:
>>>>>> 
>>>>>> > The list has public archives. Draw your own conclusions on the policy.
>>>>>> >
>>>>>> > https://mailman.nanog.org/pipermail/nanog/
>>>>>> >
>>>>>> > On 1/18/21 2:40 PM, Anne P. Mitchell, Esq. wrote:
>>>>>> >>  Not under that impression at all. That's very different from "what 
>>>>>> >> is the
>>>>>> >>  policy" - at least in the groups I run, if the policy is "no sharing
>>>>>> >>  offlist" and then someone does, there are consequences for that 
>>>>>> >> someone.
>>>>>> >>  Anne
>>>>>> >>
>>>>>> >>  --
>>>>>> >>  Anne P. Mitchell,  Attorney at Law
>>>>>> >>  Dean of Cyberlaw & Cybersecurity, Lincoln Law School
>>>>>> >>  Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam 
>>>>>> >> law)
>>>>>> >>  Board of Directors, Denver Internet Exchange
>>>>>> >>  Chair Emeritus, Asilomar Microcomputer Workshop
>>>>>> >>  Former Counsel: Mail Abuse Prevention System (MAPS)
>>>>>> >> 
>>>>>> >
>>>>>> 
>>>>>> --
>>>>>>   Jon Lewis, MCP :)   |  I route
>>>>>>   StackPath, Sr. Neteng   |  therefore you are
>>>>>> _ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Nashville

[J. Hellenthal via NANOG]

That’s funny... sure you don’t want to watch her do some home decorating or 
house projects like fixing the sink ? ;-)

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 17, 2021, at 14:06, Javier J  wrote:
> 
> 
> WTF is this? Responding to a thread on NANOG is now emailing politicians?
> 
> -- Forwarded message -
> From: 
> Date: Sun, Jan 17, 2021 at 1:31 PM
> Subject: Re: Re: Nashville
> To: Javier J 
> 
> 
> Hi there,
> 
> Thanks very much for your message, and for reaching out to the campaign 
> office of Representative Ocasio-Cortez!  
> For press inquiries, please reach out to our Press Secretary, Ivet Contreras, 
> at i...@ocasiocortez.com. We also recommend following Alexandria on Twitter 
> for direct quotes and real-time updates. Sign up for our press advisory list 
> here.
> If you are a resident of New York's 14th Congressional District and are 
> reaching out for assistance, please contact Alexandria's congressional team 
> directly by visiting https://ocasio-cortez.house.gov/contact.
> If you are reaching out to request a meeting or invite Alexandria to an 
> event, please visit https://ocasio-cortez.house.gov/scheduling-request and 
> submit a Scheduling Request for review by Alexandria's congressional 
> schedulers. 
> If your inquiry is not press-related, please email u...@ocasiocortez.com.
> 
> Thank you again for reaching out, and we hope to be able to connect with you 
> soon!

Re: Looking for hosted SMTP service for small ISP

[J. Hellenthal via NANOG]

Check out sendgrid.net

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 14, 2021, at 12:59, chiel  wrote:
> 
> Hello,
> 
> We are a small ISP. Most of our customers have a hosted e-mail service
> (gmail/office365/etc..) and have their own outgoing email sorted.
> 
> But a handful of customers rely on our SMTP server for outgoing e-mail.
> Currently we host this our self with a physical box. But I would like to
> have a hosted solution so that I don't have to worry about keeping up
> with updates and latest spam techniques.
> 
> Preferred I'm looking to make a DNS name like smtp.example.com and point
> this to a hosted solution. This excepts any email from our IP ranges.
> All controlled with a nice dashboard.
> 
> I was in contact with Solarwinds (Mail Assure) but they don't seem to be
> able to help.
> 
> Chiel

Re: DoNotPay Spam?

[J. Hellenthal via NANOG]

Any chance the HTML can be turned off ? 

;-)

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 13, 2021, at 19:18, Mel Beckman  wrote:
> 
>  Tons, and we are litigating them. They are spamming most of the addresses 
> in several of our domains. 
> 
> -mel via cell
> 
>>> On Jan 13, 2021, at 2:18 PM, Mike Hammett  wrote:
>>> 
>> 
>> I have reached out to the list admins and the donotpay people and they're 
>> working on it.
>> 
>> In short, someone that uses that service reported the NANOG list as SPAM to 
>> the DoNotPay service.
>> 
>> 
>> 
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>> 
>> Midwest-IX
>> http://www.midwest-ix.com
>> 
>> From: "Robert Webb" 
>> To: "NANOG list" 
>> Sent: Wednesday, January 13, 2021 4:06:15 PM
>> Subject: DoNotPay Spam?
>> 
>> Anyone else getting spam from DoNotPay everytime they send an email to the 
>> list?
>> 
>> I have not sent anything in a while until my ATT email and now I am getting 
>> this on every new email I send to the list.
>> 
>> 
>> 
>> You’re almost there! Sign up once to unlock lifetime protection (and even 
>> compensation) on all spam emails.
>> 

Re: Parler

[J. Hellenthal via NANOG]

Then again as a network operator you don’t discriminate against what is coming 
through you to a user or customer ... right ? ... :-D 

Unless it directly impacts you or the actual customer or you’ve been served by 
our ubermint to do otherwise non-advantageous things whatever they may be ;-)

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 10, 2021, at 15:31, Jay Hennigan  wrote:
> 
> On 1/10/21 12:40, Matthew Petach wrote:
> 
>> There's easy solutions to the problem--hiring really good engineers
>> to write your own AWS-lookalike where you can host whatever content
>> you want, hosted in buildings you've built on land you've bought.
> 
> There's also the issue of carrying the packets from those servers to your 
> audience and from your audience to those servers.
> 
> -- 
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV

Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study

[J. Hellenthal via NANOG]

Comment inline

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 4, 2021, at 14:35, b...@theworld.com wrote:
> 
> 
> Why wouldn't we just build this into 10-year battery smoke alarms, a
> simple radio receiver?

Someone contact  gentex.com to go over the IoT thoughts.


> 
> Why does anyone think this must be a feature of the internet when, as
> people here have described, that entails all sorts of complexities.
> 
> You just want something that goes BEEP-BEEP-BEEP KISS YOUR ASS
> GOODBYE! BEEP BEEP BEEP really loudly on command, perhaps with some
> more detail.
> 
> Probably about 10c in circuitry involved.
> 
> We're really getting way into the cargo cult worship of the internet
> much like how TV in the 1950s was supposed to be the answer to every
> one of society's problems but mostly what we got were sitcoms and ads
> for bad beer.
> 
> Ok, proceed with the list of edge cases. But at least there are laws
> requiring smoke alarms most everywhere.
> 
> -- 
>-Barry Shein
> 
> Software Tool & Die| b...@theworld.com | 
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*

Re: The Real AI Threat?

[J. Hellenthal via NANOG]

Let me know when a program will rewrite itself and add its own features ... 
then we may have a problem... otherwise they only do what you want them to do.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Dec 10, 2020, at 12:41, Mel Beckman  wrote:
> 
> 
>> 
>>> Jeez... some guys seem to take a joke literally - while ignoring a real and 
>>> present danger - which was the point.
> 
> Miles,
> 
> With all due respect, you didn’t present this as a joke. You presented "AI 
> self-healing systems gone wild” as a genuine risk. Which it isn’t. In fact, 
> AI fear mongering is a seriously debilitating factor in technology policy, 
> where policymakers and pundits — who also don’t get “the joke” — lobby for 
> silly laws and make ridiculous predictions, such as Elon Musks claim that, by 
> 2025, “AI will be where AI conscious and vastly smarter than humans.”
> 
> That’s the kind of ignorance that will waste billions of dollars. No joke.
> 
>  -mel
> 
> 
> 
>>> On Dec 10, 2020, at 8:47 AM, Miles Fidelman  
>>> wrote:
>>> 
>>> Ahh invasive spambots, running on OpenStack ... "the telephone bell is 
>>> tolling... "
>>> 
>>> Miles
>>> 
>>> adamv0...@netconsultings.com wrote:
>>> > Automated resource discovery + automated resource allocation = recipe for 
>>> > disaster
>>> That is literally how OpenStack works. 
>>>  
>>> For now, don’t worry about AI taking away your freedom on its own, rather 
>>> worry about how people using it might…
>>>  
>>>  
>>> adam
>>>  
>>> From: NANOG  On 
>>> Behalf Of Miles Fidelman
>>> Sent: Thursday, December 10, 2020 2:44 PM
>>> To: 'NANOG' 
>>> Subject: Re: The Real AI Threat?
>>>  
>>> adamv0...@netconsultings.com wrote:
>>> > Put them together, and the nightmare scenario is:
>>> > - machine learning algorithm detects need for more resources
>>> All good so far
>>>  
>>> > - machine learning algorithm makes use of vulnerability analysis library 
>>> > to find other systems with resources to spare, and starts attaching
>>> > those resources
>>> Right so a company would built, trained and fine-tuned an AI, or would have 
>>> bought such a product and implemented it as part of its NMS/DDoS mitigation 
>>> suite, to do the above? 
>>> What is the probability of anyone thinking that to be a good idea?
>>> To me that does sound like an AI based virus rather than a tool one would 
>>> want to develop or buy from a third party and then integrate into the day 
>>> to day operations.
>>>  
>>> You can’t take for instance alpha-0 or GPT-3 and make it do the above. 
>>> You’d have to train it to do so over millions of examples and trials. 
>>> Oh and also these won’t “wake up” one day and “think” to themselves oh I’m 
>>> fed up with Atari games I’m going to learn myself some chess and then do 
>>> some reading on wiki about the chess rules. 
>>> 
>>> Jeez... some guys seem to take a joke literally - while ignoring a real and 
>>> present danger - which was the point.
>>> 
>>> Meanwhile, yes, I think that a poorly ENGINEERED DDoS mitigation suite 
>>> might well have failure modes that just keep eating up resources until 
>>> systems start crashing all over the place.  Heck, spinning off processes 
>>> until all available resources have been exhausted has been a failure mode 
>>> of systems for years.  Automated resource discovery + automated resource 
>>> allocation = recipe for disaster.  (No need for AIs eating the world.)
>>> 
>>> Miles
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> In theory, there is no difference between theory and practice.
>>> In practice, there is.   Yogi Berra
>>>  
>>> Theory is when you know everything but nothing works. 
>>> Practice is when everything works but no one knows why. 
>>> In our lab, theory and practice are combined: 
>>> nothing works and no one knows why.  ... unknown
>> 
>> 
>> -- 
>> In theory, there is no difference between theory and practice.
>> In practice, there is.   Yogi Berra
>> 
>> Theory is when you know everything but nothing works. 
>> Practice is when everything works but no one knows why. 
>> In our lab, theory and practice are combined: 
>> nothing works and no one knows why.  ... unknown
> 

Re: Cable Company Hotspots

[J. Hellenthal via NANOG]

Sad that in some cases the extra WiFi usage results in higher electric bills 
for the consumer and cannot be opted out of.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Nov 22, 2020, at 11:49, kwo...@citywest.ca wrote:
> 
> 
>> 
>> How do the cable companies generally deliver this service? A friend
> insists it
>> piggybacks off the WIFI radios of existing cable company subscribers. In
> other
>> words, the cable company WIFI router in a flat is providing both a private
> link
>> for the flat's subscriber, but also a public hotspot service.
>> 
>> 
>> I concede it is possible, but I am skeptical that the high quality of
> hotspot
>> service we get here in Budapest could be achieved that way.
> 
> Calix has this option on the 844G/E CPE. The G is used with fibre based
> drops and the
> E is used with cable modems.
> 
> It is called Community Wifi and is an option that can be enabled in both
> units. It uses GRE tunnels
> to backhaul traffic.
> 
> Never used it so have limited knowledge on actual workings, but have
> deployed many
> of both types of CPE's.
> 
> 
> 
> 
> 
> 

Re: Apple Catalina Appears to Introduce Massive Jitter - SOLVED! - Update!

[J. Hellenthal via NANOG]

You can supposedly still use 4.5 4.6 on Big Sur if you do the following but I 
have not tested it on Little Snotch, works fine for personal software and 
others ...

codesign -dvvv littlesnitch.package name
Save the team identifier
Boot into recovery mode
Open terminal and type the following...
spctl kext-consent add 
Reboot into normal user mode and install version 4



-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Nov 22, 2020, at 11:55, d...@darwincosta.com wrote:
> 
> 
>>> On 22 Nov 2020, at 10:17, Mark Tinka  wrote:
>>> 
>>  So after installing Little Snitch and basically denying "trustd" any kind 
>> of Internet access, I have been seeing reasonably normal jitter with 
>> Bluetooth enabled.
> I actually “saw the same” on Catalina while using little snitch. 
> 
> “Saw the same” after installing yesterday Big Sur and suddenly received a 
> notification “this version of little snitch is no longer supported by macOS. 
> It’s looks like I have to pay 25€ for a new compatible version. 
>> 
>> It's not that Bluetooth stops scanning, but it's not scanning as 
>> aggressively. So after a few minutes, there will be very high jitter when 
>> Bluetooth scans the environment, but it would affect only a single packet. 
>> It's easily reduced its chattiness by 99%.
>> 
>> I don't have any empirical data to support the claim that Little Snitch has 
>> anything to do with it (and I am too lazy to dig further into it), but the 
>> reduction in jitter is massively noticeable since Little Snitch. Which means 
>> I can now run Catalina with Bluetooth enabled and not have any wi-fi 
>> problems.
>> 
>> Just FYI, for the archives :-).
>> 
>> Mark.
> 
> Cheers,
> Darwin-. 

Re: Apple Catalina Appears to Introduce Massive Jitter - SOLVED!

[J. Hellenthal via NANOG]

Hey Mark,

Went through a bunch of tests here. Seems I’ve cleared up the matter on this 
macOS[1] Big Sur at least by disabling Wi-Fi Networking under “Location 
Services -> System Services -> Wi-Fi Networking [2]”. It seems at least from 
perspective that something changed there and causes the Mac to scan more 
aggressively when more than one access point (generally speaking your SSID & 
SSID + 5G) has been logged at a location as accessible. This same thing could 
be observed at least on my system while having those settings turned off, 
bluetooth on and location services enabled and opening (Wi-Fi Explorer[3]) 
which puts the interface into “monitor mode” which seems to be causing the 
contention somewhere. After those changes keep in mind I had to restart from a 
full shutdown to get to some real clean ms traffic to the router and I prefer 
to be connected to 5Ghz before 2.4Ghz.


1. Darwin Kernel Version 20.1.0: Thu Oct 29 05:35:40 PDT 2020; 
root:xnu-7195.50.5~4/RELEASE_X86_64
2. 
https://www.dropbox.com/s/m3xm3fpoziwe01d/Screen%20Shot%202020-11-10%20at%2008.20.08.png?dl=0
3. https://apps.apple.com/us/app/wifi-explorer/id494803304?mt=12


> On Nov 5, 2020, at 00:43, Mark Tinka  wrote:
> 
> Just an update on this re: the Bluetooth.
> 
> I had my AirPods paired previously for single use. I don't use them on the 
> laptop (there is some latency), so I prefer the wired earphones. But it seems 
> like Bluetooth was aggressively scanning for them. After removing them from 
> the system, the scanning remained, but reduced significantly.
> 
> So looking at Console again, every so often, Bluetooth is scanning the 
> network on behalf of the "sharingd" process.
> 
> sharingd is a sharing daemon that supports features such as AirDrop, Handoff, 
> Instant Hotspot, Shared Computers and Remote Disc in Finder.
> 
> Still keeping Bluetooth off, however.
> 
> Mark.


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

Re: Apple Catalina Appears to Introduce Massive Jitter - SOLVED!

[J. Hellenthal via NANOG]

Heya ! Doug!

Yeah I wouldn’t put this on BT either. On the other hand it seems that whether 
the scheduler is newreno or cubic that this situation persists pasts my 
previous suggestions. Seems tho that when you put strain on an upload that the 
jitter gets considerably worse... 90m out of a 100m link it starts to get to 
1000+ms

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 30, 2020, at 16:59, Doug Barton  wrote:
> I would hesitate to blame BT. I have a macbook pro from ~1 year ago, on 
> Catalina, and I use BT extensively ... mouse, keyboard, and headset. I do 
> have location services trimmed down to just find my mac.
> 
> I ran: ping -c 1000 -i 0.1 
> 
> 1000 packets transmitted, 998 packets received, 0.2% packet loss
> round-trip min/avg/max/stddev = 1.255/2.378/9.095/0.634 ms
> 
> One thing that may contribute to blaming BT however is if you are using wifi 
> on 2.4G only, and/or preferring it, as BT operates in the same frequency 
> range neighborhood. My macbook is connected using 5G.
> 
> Happy to compare other settings if there is interest.
> 
> Doug
> 
> 
>> On 10/30/20 12:08 PM, Mark Tinka wrote:
>> Hi all.
>> So I may have fixed this for my end, and hopefully others may be able to use 
>> the same fix.
>> After a tip from Karl Auerbach and this link:
>> https://developer.apple.com/forums/thread/97805
>> ... I was able to fix the problem by disabling Bluetooth.
>> However, disabling Bluetooth was not enough. I also had to disable all 
>> Location Services.
>> After that, I re-enabled Location Services and only allowed for two features:
>> - NetSpot
>> - Find My Mac
>> With just those two location services, as well as Bluetooth disabled, I have 
>> no more high jitter.
>> App performance like Zoom and Youtube uploads are now crisp, with 0.0% 
>> packet loss.
>> So looks like that Bluetooth is a huge problem. Confirmed by opening the 
>> "Console" app, and adding "scan" in the filter bar, top right.
>> A peak latency of 13.5ms after 300 packets:
>> Marks-MacBook-Pro.local (172.16.0.239) 2020-10-30T21:06:05+0200
>> Keys:  Help   Display mode   Restart statistics   Order of fields   quit
>> Packets   Pings
>>  Host Loss%   Snt   Last   Avg  Best  Wrst StDev
>>  1. 172.16.0.254 0.0%   3003.1   4.8   2.2  13.5   1.9
>> Mark.


smime.p7s
Description: S/MIME cryptographic signature

Re: Apple Catalina Appears to Introduce Massive Jitter

[J. Hellenthal via NANOG]

Should also state here that net.inet.icmp.icmplim=0 and the command I have been 
testing from is: (ping -c 5000 -i 0.1 router)

--- router ping statistics ---
5000 packets transmitted, 5000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.118/4.060/172.031/6.841 ms


> On Oct 29, 2020, at 09:08, J. Hellenthal  wrote:
> 
> I believe I have seen the same thing with a Mid 2015 11,4 running catalina. 
> Not diagnosing further because I could not find a reason for it fast enough 
> and not sure if it really had an impact at the moment…. but could you try the 
> following 
> 
> 
> sudo sysctl net.link.generic.system.hwcksum_tx=0
> sudo sysctl net.link.generic.system.hwcksum_rx=0
> sudo ifconfig en0 -rxcsum
> 
> 
> in reverse … to restore the settings 
> 
> sudo sysctl net.link.generic.system.hwcksum_tx=1
> sudo sysctl net.link.generic.system.hwcksum_rx=1
> sudo ifconfig en0 rxcsum
> 
> 
> If you have some specific tests to run I would be willing to run them here on 
> Big Sur with the same laptop but I have nothing now that runs Catalina
> 
> 
> Wireshark used to in Catalina rack up cksum errors a lot while these were all 
> at their defaults.
> 
> 
> 
>> On Oct 29, 2020, at 08:23, Mark Tinka  wrote:
>> 
>> 
>> 
>> On 10/29/20 15:04, Cory Sell wrote:
>> 
>>> Might be worth disabling each AP to see if there's one out there having an 
>>> issue playing nice with the MacBook. Also try different combinations of two 
>>> APs working together. It's possible the MacBook is flip flopping because 
>>> the power levels are fighting each other.
>> 
>> Tested all that, as well as dropping Tx power levels on each of the AP's to 
>> Low so that there isn't any power coming from any other AP (despite being 
>> quite far, already).
>> 
>> And to confirm, when the laptop locks into an AP, it doesn't try to join 
>> another one. When in range, power is very good (between -37dB and -52dB). 
>> When I walk away, that AP becomes too far (as bad as -80dB), but the next 
>> one close by is far better (same good values as before) and laptop connects 
>> and sticks to that.
>> 
>> Again, only impacts Catalina. No other Apple device, or the Windows PC that 
>> is on the same WLAN.
>> 
>> 
>>> Does the Mac have this issue at your local coffee shop or another 
>>> establishment with Wi-Fi? You can try to rule out the AirPort card in the 
>>> Mac itself.
>> 
>> Never tried, I generally work from home. If I'm out, it's faster to tether 
>> to my 4G service rather than any public wi-fi.
>> 
>> Mark.
> 
> 
> -- 
> 
> J. Hellenthal
> 
> The fact that there's a highway to Hell but only a stairway to Heaven says a 
> lot about anticipated traffic volume.
> 
> 
> 
> 
> 
> 


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

Re: Apple Catalina Appears to Introduce Massive Jitter

[J. Hellenthal via NANOG]

I believe I have seen the same thing with a Mid 2015 11,4 running catalina. Not 
diagnosing further because I could not find a reason for it fast enough and not 
sure if it really had an impact at the moment…. but could you try the following 


sudo sysctl net.link.generic.system.hwcksum_tx=0
sudo sysctl net.link.generic.system.hwcksum_rx=0
sudo ifconfig en0 -rxcsum


in reverse … to restore the settings 

sudo sysctl net.link.generic.system.hwcksum_tx=1
sudo sysctl net.link.generic.system.hwcksum_rx=1
sudo ifconfig en0 rxcsum


If you have some specific tests to run I would be willing to run them here on 
Big Sur with the same laptop but I have nothing now that runs Catalina


Wireshark used to in Catalina rack up cksum errors a lot while these were all 
at their defaults.



> On Oct 29, 2020, at 08:23, Mark Tinka  wrote:
> 
> 
> 
> On 10/29/20 15:04, Cory Sell wrote:
> 
>> Might be worth disabling each AP to see if there's one out there having an 
>> issue playing nice with the MacBook. Also try different combinations of two 
>> APs working together. It's possible the MacBook is flip flopping because the 
>> power levels are fighting each other.
> 
> Tested all that, as well as dropping Tx power levels on each of the AP's to 
> Low so that there isn't any power coming from any other AP (despite being 
> quite far, already).
> 
> And to confirm, when the laptop locks into an AP, it doesn't try to join 
> another one. When in range, power is very good (between -37dB and -52dB). 
> When I walk away, that AP becomes too far (as bad as -80dB), but the next one 
> close by is far better (same good values as before) and laptop connects and 
> sticks to that.
> 
> Again, only impacts Catalina. No other Apple device, or the Windows PC that 
> is on the same WLAN.
> 
> 
>> Does the Mac have this issue at your local coffee shop or another 
>> establishment with Wi-Fi? You can try to rule out the AirPort card in the 
>> Mac itself.
> 
> Never tried, I generally work from home. If I'm out, it's faster to tether to 
> my 4G service rather than any public wi-fi.
> 
> Mark.


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

Re: Vint Cerf & Interplanetary Internet

[J. Hellenthal via NANOG]

NASOG

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 21, 2020, at 22:59, Mark Andrews  wrote:
> 
> It wouldn’t be NANOG.  Perhaps LUNOG or MOONOG.
> 
>> On 22 Oct 2020, at 14:07, scott weeks  wrote:
>> 
>> 
>> *From:* NANOG  on behalf of Rod 
>> Beck 
>>> https://www.quantamagazine.org/vint-cerfs-plan-for-building-an-internet-in-space-20201021/
>> 
>> 
>> On 10/21/20 2:27 PM, Suresh Ramasubramanian wrote:
>> 
>> Right. This means we are going to catch a spaceship for a future nanog / have
>> interplanetary governance federation debates with space aliens from 
>> Andromeda,
>> and we will finally run out of v6 and ipv9 will rule the roost while there’s 
>> a
>> substantial aftermarket + hijack scene going on for the last remaining v6 
>> blocks.
>> 
>> 
>> 
>> More like IP to Nokia's new cell network on the moon:
>> 
>> https://www.theguardian.com/science/2020/oct/20/talking-on-the-moon-nasa-and-nokia-to-install-4g-on-lunar-surface
>> (Everyone on the moon will want to have access to LOL cats!)
>> 
>> Or... using DTN (https://datatracker.ietf.org/wg/dtn/about) to reach Mars 
>> and other
>> planets by being relayed through communications relay satellites similar to 
>> the
>> Mars Telecommunication Orbiter (canceled),  Mars Odyssey or Mars
>> Reconnaissance Orbiter spacecraft.
>> 
>> Or... IP to robots visiting other non-planet objects in the solar system like
>> comets/asteroids:
>> https://spacenews.com/osiris-rex-touches-down-on-asteroid
>> https://www.bbc.com/news/science-environment-47293317
>> 
>> Or... 
>> 
>> The IPI idea has been around for a long time now:
>> https://en.wikipedia.org/wiki/Interplanetary_Internet
>> 
>> The main question is will NANOG On The Road meet on the moon?  I missed
>> the only Hawaii one, so maybe I could make the moon one!
>> 
>> scott
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: Cogent emails

[J. Hellenthal via NANOG]

geeks@nanog works just fine 

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Sep 22, 2020, at 07:53, Rich Kulawiec  wrote:
> 
> On Mon, Sep 21, 2020 at 06:30:24PM -0600, Grant Taylor via NANOG wrote:
>> Is this simply being aggregated by a NANOG member / subscriber and thus
>> something unofficial?
> 
> That's exactly right.  Whether NANOG itself ever wants to do anything
> with the results is entirely up to them.
> 
> ---rsk


smime.p7s
Description: S/MIME cryptographic signature

Re: curious spam...

[J. Hellenthal via NANOG]

Hey google, siri, or Alexa phoning home and your information put into a local 
database as a new person in the area for which they have bought your 
address I could believe that.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Sep 14, 2020, at 13:33, William Herrin  wrote:
> 
> Howdy,
> 
> I've noticed something odd. When I lived in Virginia, I started
> receiving email directly to my gmail box from my U.S. Representative.
> Unsolicited spam from Congressmen is nothing new but it was a little
> odd that they found my gmail box (which I don't give out) and not one
> of the hundreds of aliases at herrin.us or dirtside.com which I do
> give out. The gmail box exists only in mail headers; "From" is always
> a different address.
> 
> I moved to Seattle. Today I found my grmail box subscribed to a
> congressman's list from a nearby Washington jurisdiction. Not some
> random congressman. And not any of the addresses I give out; my gmail
> box's address which I don't.
> 
> Anyone else have a similar experience? Any idea how a hidden address
> is making it on to relevant congressmens' lists but not any others?
> That's weird right?
> 
> Regards,
> Bill Herrin
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/


smime.p7s
Description: S/MIME cryptographic signature

Re: Help configuring Dell Server

[J. Hellenthal via NANOG]

Dell Support or some other group may be more appropriate for this…


Good luck, In IRC land you may want to visit Freenode #Ubuntu #Linux #Centos….. 
If you are searching for an IRC client after thus message check out mIRC for 
Windows or XChat for *IX variations and hang out on those for a while. They’ll 
be willing to help.


> On Aug 31, 2020, at 09:51, Brielle  wrote:
> 
> 
> Um, this is a list for North American network operators, not r/techsupport...
> 
> If you aren’t capable of doing even the most basic configuration of name 
> servers, you are in the wrong place.
> 
> 
> Sent from my iPhone
> 
>> On Aug 31, 2020, at 8:38 AM, peter agakpe  wrote:
>> 
>> 
>> Can I get some help deploy my server online. I have Ubuntu and centos 
>> installed but still having some problems. I keep getting; “server IP address 
>> could not be found. DNS_PROBE_FINISHED_NXDOMAIN.”
>> 
>> COULD USE, NO, NEED HELP.
>> 
>>  
>> 
>> THANKS
>> 
>>  
>>  
>> Sent from Mail for Windows 10


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.








smime.p7s
Description: S/MIME cryptographic signature

Re: 100g PCS Errors

[J. Hellenthal via NANOG]

Id hope by this point you’ve already reseated not only the card but the 
connection to the card as well ?.

Possibly a faulty card.

> On Aug 19, 2020, at 07:46, Nicholas Warren  wrote:
> 
> We've got a 100g qsfp in an mx204 that has 1207 bit errors and 29666 errored 
> blocks after 24 hours of just being linked up...
> I would assume this is not normal behavior, but I haven't used 100g before. 
> Do others see high error rates on their 100g optics?


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.








smime.p7s
Description: S/MIME cryptographic signature

Re: ISPs are hit hardest by COVID-19 disruption

[J. Hellenthal via NANOG]

Just more hype looking to boost marketing

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Aug 6, 2020, at 21:23, Hank Nussbacher  wrote:
> 

Re: Internet Providers in 111 8th Ave, NYC

[J. Hellenthal via NANOG]

Paranoid much?

Mehemet is an upstanding guy doing the right thing as well as his site of 
countless very useful information.

But considering this wasn’t even for you ... maybe you have a better solution ?




-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.
> On Jul 24, 2020, at 09:51, Tom Hill  wrote:

Re: Internet Providers in 111 8th Ave, NYC

[J. Hellenthal via NANOG]

This might be of assistance….

https://live.infrapedia.com/app

> On Jul 24, 2020, at 08:27, Pete Rohrman  wrote:
> 
> Looking for an Internet provider that is in the Level3/CenturyLink space (3rd 
> floor) in 111 8th Ave, New York City.  There are plenty of providers in the 
> building, but I'm trying to avoid riser costs.
> 
> Feel free to pass this along to your sales team, and if so, give them my 
> direct number 212 497 8015.  If you know a good sales rep, please send me 
> their contact info off thread.
> 
> Thank you in advance.
> 
> Pete
> 
> -- 
> Pete Rohrman
> Stage2 Support
> 212 497 8000, Opt. 2
> 


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.








smime.p7s
Description: S/MIME cryptographic signature

Re: Anyone running C-Data OLTs?

[J. Hellenthal via NANOG]

Almost no surprise they are all third world, still scary in a sense. Might just 
have to rethink a blacklist strategy for traffic originating behind those 
locations.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jul 10, 2020, at 15:30, blakan...@gmail.com wrote:
> 
>  Well here are a couple hundred:
> 
> https://www.shodan.io/search?query=Command+Line+Interface+for+EPON+System
> 
> -Keith
> 
> Mel Beckman wrote on 7/10/2020 1:07 PM:
> 
>> Perhaps you’re confusing OLT with ONT? An OLT is a “curbside” distribution 
>> node, the ONT is the CPE. The vulnerability is in the distribution node, not 
>> the CPE. No provider with any sense exposes their distribution node admin 
>> interface to the Internet. 
>> 
>> -mel via cell
>> 
>>> On Jul 10, 2020, at 1:01 PM, m...@beckman.org wrote:
>>> 
>>> The “WAN” port of an OLT _is_ it’s management port. Data, IPTV, and VoIP 
>>> traffic pass on VLANs, typically encrypted. These are passive optical 
>>> network (PON) devices, where all CPE in a group of, say, 32 premises 
>>> receive the same light via an optical splitter. Thus network partitioning 
>>> is a requirement of the architecture. There is no concept of a traditional 
>>> “WAN” port facing the Internet. 
>>> 
>>> -mel via cell
>>> 
>>>> On Jul 10, 2020, at 12:21 PM, Owen DeLong  wrote:
>>>> 
>>>> 
>>>> Um, from the article it appears that this isn’t on the Management 
>>>> interface, but the WAN port of the OLT.
>>>> 
>>>> Owen
>>>> 
>>>> 
>>>>> On Jul 10, 2020, at 11:01 , Mel Beckman  wrote:
>>>>> 
>>>>> But who, who I ask, opens their management interface to the public 
>>>>> Internet?!?!
>>>>> 
>>>>> Maybe this is vulnerability if you have a compromised management network, 
>>>>> but anybody who opens CPE up to the Internet is just barking mad :-)
>>>>> 
>>>>> -mel via cell
>>>>> 
>>>>>> On Jul 10, 2020, at 10:00 AM, Owen DeLong  wrote:
>>>>>> 
>>>>>>  
>>>>>> https://www.zdnet.com/article/backdoor-accounts-discovered-in-29-ftth-devices-from-chinese-vendor-c-data/?ftag=TRE-03-10aaa6b=29077120342825113007211255328545=12920625=2211510872
>>>>>> 
>>>>>> Wow… Just wow.
>>>>>> 
>>>>>> Owen
>>>>>> 
>>>> 
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: Client-side information gathering tool

[J. Hellenthal via NANOG]

On Tue, Jun 16, 2020 at 11:30:23AM -0500, Matt Harris wrote:
>Hey folks,
>I was hoping maybe someone could point me in a useful direction here. I'm
>looking into software tools (ideally, they'd support Windows, Mac, and
>Linux, though Windows is perhaps the only critical one) that can be sent
>over to random users with varying (mostly very little) knowledge of how
>the internet works to gather a bunch of data that they can then provide to
>us to help identify connectivity issues between the client and a chosen
>endpoint. IPv4 and IPv6 support are requirements. I've got a lot of
>clients with VPN connections of varying sorts running on internet
>connections of often very low quality, and sometimes even in places where
>reasonable quality doesn't seem to even exist. 
>Right now, when these users complain, this often means my support folks
>get to walk them through downloading winmtr and running that as well as
>other command line tools to gather a bunch of other information about
>their computer, its connection to their LAN, their LAN configuration as
>best as we can tell, and their connection to the greater internet. This is
>somewhat cumbersome of a process though. If we could send them something
>they could click on and then copy/paste out of or otherwise direct the
>data to us, that would save a fair bit of time and also be a lot less
>patience-grating on the part of our clients. 
>Any links to potentially useful tools (commercial or free are both fine)
>would be appreciated. The main goal is getting lots of relevant
>information to us without having to walk an end-user through lots of steps
>to do so. The more relevant data, the better. 
>Thanks,
>Matt
> 
> Matt Harris​ | Infrastructure Lead Engineer 
> 816‑256‑5446 | Direct   
>Looking for something?   
>Helpdesk Portal | Email Support | Billing Portal 
> We build and deliver end‑to‑end IT solutions.   

Since noone else has replied here.

Good to hear from you and thank you for posting something that may be
useful to some others that lurk in the future.

Personally to answer on only my behalf and a few others (mainly corss),
scriptinng your solutions and distributing thhose baseics through
whatever meanns to each provisioned host can go a long way.

e.g.Winderz: \.Bin or \.Support [hidden depending on how much you.
macOS: somewhere suitable to where you want to store them.
Linux: ... (same)

Write the output to a file and open it with the appropriate editor ask
user to hit Ctrl+A & Ctrl+C or the equivelant on other OS's and paste
the contents to you. Form a script to automatically submit it to a
ticket system ?


Ofcourse you could go ansible/salt/etc... and make every user/client cooperate .


If you look for specifics then take advantage of your ability to
provision or package.


-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Survey on the use of IP blacklists for threat mitigation

[J. Hellenthal via NANOG]

Guess we all better start rewriting all of the documentation out there because 
some PC marketing snowflake wants to get extra brownie points and attention for 
classifying a color in RGB into a racial divide for which it never originated.

blacklists are not always deny/block/disallow and conformed of things that 
allow you to take actions whatever your choosing upon their contents and your 
policies.

What’s next ? redlisting ? Don’t offend the Russians ... blue ? Don’t want to 
offend the police ...

Leave this crap off the list, it’s not helping anyone.

SMH


-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jun 16, 2020, at 13:27, Ryan Landry  wrote:
> 
> 
> In kind, I'd like to encourage the use of terms like permit/accept list or 
> deny/block list.
> 
> Respectfully,
> -Ryan
> 
>> On Tue, Jun 16, 2020 at 11:33 AM Rachee Singh  wrote:
>> Hi NANOG community,
>> 
>> We are a group of researchers studying the use of IP blacklists as a 
>> mechanism to mitigate security threats -- particularly over the IPv6 
>> Internet. We would like to understand if and how you use IP blacklists to 
>> secure your networks. Please consider taking our short survey: 
>> https://forms.gle/ZEsxyiBivJAfLF7e6
>> 
>> The survey will be anonymous unless you choose to identify yourself.
>> 
>> Thanks,
>> Rachee
>> UMass Amherst


smime.p7s
Description: S/MIME cryptographic signature

Re: ARIN

[J. Hellenthal via NANOG]

Well said my friend. Support often not gets the respect they deserve, when it 
comes to ARINthiugh a big shout out! Always outstanding.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jun 12, 2020, at 18:11, John Sweeting  wrote:
> 
>  Thank you for taking time out to recognize the great team in RSD Mehmet! 
> The fact is they go above and beyond each and every day and it’s great to see 
> that pointed out. Lisa and her team are amazing. Thank you again. 
> 
> Sent from my iPhone
> 
>>> On Jun 12, 2020, at 6:45 PM, Mehmet Akcin  wrote:
>>> 
>> 
>> hey there,
>> 
>> I just wanted to share my experience dealing with ARIN support this week. I 
>> think it's not very common to see people taking the time to write something 
>> like this but I personally think we should do more often. 
>> 
>> It has been long time since I had to deal with RIRs and this week I had to 
>> do several things in ARIN. The support has team was very quick responding, 
>> very useful with their recommendations to my questions, and had a great 
>> attitude towards solving problems. I can certainly say they went above and 
>> beyond when I opened a ticket with wrong request type and they asked me if 
>> they can close it and open a new one for me? I mean.. this is called going 
>> Above and Beyond!  
>> 
>> thank you all ARIN support desk and especially Lisa Liedel for this great 
>> experience. and @John Curran please accept this sincere thanks on your 
>> team's behalf! 
>> 
>> Mehmet


smime.p7s
Description: S/MIME cryptographic signature

Re: six pages for rov issues

[J. Hellenthal via NANOG]

Thank you Randy

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jun 13, 2020, at 14:21, Randy Bush  wrote:
> 
> chris at the ever fantastic six has done a stunning bit of work to let
> six members see rpki/irr announcement issues
> 
>   https://www.seattleix.net/rs-drops
> 
> randy


smime.p7s
Description: S/MIME cryptographic signature

Re: LTE modem where I can control the MTU

[J. Hellenthal via NANOG]

On Fri, May 01, 2020 at 11:56:57AM -0400, Dovid Bender wrote:
>I currently have an airlink that is connected directly to a raritan
>console server. The public IP sits on the raritan. The airlink does not
>seem to have any MTU options. Ideally I would change the MTU on the
>interface of the LTE modem wich would force the raritan to send all data <
>1400 bytes per packet. I never thought about the reverse so we may need
>something that would tinker with the MSS as well.
> 

Not too familiar with airlink but it perhaps doesn't happen to have a
(ALG)/Application Layer/Level Gateway in it does it ?

If so I could reccomend attempting to turn it off. Ive seen this
similiar sort of thing in other routing equipemnt that either didn't
work at all or would bomb out on particular services.

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Abuse Desks

[J. Hellenthal via NANOG]

Enforcing rate limiting comes to mind. And if there is a blatant problem then 
very strict rate limiting to make even surfing yahoo news a pain is a good idea.

Not to mention conn tracking and limiting to allow a customer to fix their 
problem is much better than a plain cut-off.

The Oh my gawd!!! I’m being port scanned ... pffft it’s moot. There is blatant 
abuse and internet fuzz coming from legitimate sec corps that believe they are 
making the internet better by scanning your equipment without you asking them 
too and hoping to sell you services, and those are all just bullshit.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Apr 29, 2020, at 07:35, Mike Hammett  wrote:
> 
> 
> "What is it, exactly, that you expect a provider to do with your report of a 
> few failed SSH login attempts to stop the activity?... disconnect the 
> customer."
> 
> Yes.
> 
> Comcast does it. My wife's aunt and uncle had a compromised box on their 
> network. They don't check their e-mail, so they didn't see the warnings from 
> Comcast. They shut them off until the problem was resolved.
> 
> 
> "Forcing disconnection for a port scan is also, by the way, a *great* way to 
> create an absolute gold-plated A+ denial-of-service: "
> 
> Surely they have flow records showing suspicious activity from that customer. 
> They may not confirm the specific IP being attacked, but they will see 
> massive numbers of SSH, SMTP, SIP, etc. connections going out. It's likely if 
> there's outbound activity of that nature and *someone* complained about it, 
> not only were they a victim of it, but the activity is probably undesired by 
> anyone else receiving it as well.
> 
> 
> "cost you practically nothing." You're right. An insecure Internet doesn't 
> cost any of us anything.
> 
> 
> "there's no One True Format for automated abuse notifications"
> 
> So then "let's" make one? No one can follow it if it doesn't exist.
> 
> 
> 
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> Midwest-IX
> http://www.midwest-ix.com
> 
> From: "Matt Palmer" 
> To: nanog@nanog.org
> Sent: Wednesday, April 29, 2020 6:48:51 AM
> Subject: Re: Abuse Desks
> 
> On Wed, Apr 29, 2020 at 12:24:01PM +0530, Mukund Sivaraman wrote:
> > On Tue, Apr 28, 2020 at 11:40:16PM -0700, Matt Corallo wrote:
> > > Sadly dumb kids are plentiful. If you have to nag an abuse desk every
> > > time they sell a server to a kid who’s experimenting with nmap for the
> > > first time then we’ll end up exactly where we are - abuse contacts
> > > are not a reliable way to get in touch with anyone, and definitely not
> > > a reliable way to do so fast or with any reasonably large
> > > network. Please don’t clog the otherwise-useful system.
> > > 
> > > If you have trouble sleeping at night, I’d recommend the
> > > “PasswordAuthentication no” option in sshd_config.
> > 
> > Yes we use that, and PermitRootLogin no and an AllowUsers list.
> > 
> > I asked in my first email, if with security practices as above and use
> > of fail2ban to filter attempts, should we just ignore this problem and
> > think that nobody is ultimately reponsible to get rid of this activity?
> 
> In theory, no.  In practice, unfortunately, yes.
> 
> The typical service provider has so much low-level "noise" going on that if
> everyone reported everything to them, they'd semi-literally drown. 
> Certainly, there's no possible way they could economically handle all that
> abuse reporting -- hiring all the people to examine, determine the veracity
> of, and act upon the reports would cost a fortune, because you better
> believe there's no One True Format for automated abuse notifications, nor
> will there ever likely be one, so it's all humans, all the time.
> 
> Now, you could argue that they should clean up their network so they don't
> have that volume of abuse reports coming in -- and you'd be right, in
> theory.  But there's a *lot* of low-level stuff that it isn't practical to
> stop, in and of itself.
> 
> Consider your own reports.  What is it, exactly, that you expect a provider
> to do with your report of a few failed SSH login attempts to stop the
> activity?  Say it's a residential ISP, or an IaaS provider.  They have only
> a few very large hammers at their disposal -- they can (maybe) filter the
> destination port, filter your destination IP, or disconnect the customer. 
> Any of those will very possibly result in a support call, or lost customer. 
> That'

Re: idiot reponse

[J. Hellenthal via NANOG]

Wtf kinda one word response is that lol

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Feb 26, 2020, at 15:03, Selphie Keller  wrote:
> 
> 
> postfix =)
> 
> /^From: .*@electricforestfestival\.com/ DISCARD
> 
>> On Wed, 26 Feb 2020 at 09:54, Christopher Morrow  
>> wrote:
>> 
>> 
>>> On Wed, Feb 26, 2020 at 11:46 AM Mike Hammett  wrote:
>>> I send to nanog-ow...@nanog.org, but I never hear back.
>>> 
>>> 
>> 
>> I had sent this privately but I thought/think: nanog-admin@
>> 
>> I could totally be wrong :)  


smime.p7s
Description: S/MIME cryptographic signature

Re: Recommended DDoS mitigation appliance?

[J. Hellenthal via NANOG]

Hopefully you would be sending those flows out a different circuit than the one 
that’s going to get swamped with a DDoS otherwise... it might just take a while 
to mitigate that ;-) depending on the type obviously.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Feb 3, 2020, at 11:01, Javier Juan  wrote:
> 
> 
> Hi !
> 
> I was looking around (a couple years ago) for mitigation appliances (Riorey, 
> Arbor, F5 and so on) but the best and almost affordable solution I found 
> was Incapsula/Imperva.
> https://docs.imperva.com/bundle/cloud-application-security/page/introducing/network-ddos-monitoring.htm
>  
> 
> Basically, You send your flows to Imperva on cloud for analysis. As soon as 
> they find DDoS attack , they activate mitigation. It´s some kind of 
> elegant-hybrid solution without on-premise appliances . Just check it out :)
> 
> Regards,
> 
> JJ
> 
> 
> 
>> On Sun, Nov 17, 2019 at 11:20 PM Rabbi Rob Thomas  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> 
>> Hello, NANOG!
>> 
>> I'm in the midst of rebuilding/upgrading our backbone and peering -
>> sessions cheerfully accepted :) - and am curious what folks recommend
>> in the DDoS mitigation appliance realm?  Ideally it would be capable
>> of 10Gbps and circa 14Mpps rate of mitigation.  If you have a
>> recommendation, I'd love to hear it and the reasons for it.  If you
>> have an alternative to an appliance that has worked well for you
>> (we're a mix of Cisco and Juniper), I'm all ears.
>> 
>> Private responses are fine, and I'm happy to summarize back to the
>> list if there is interest.
>> 
>> Thank you!
>> Rob.
>> - -- 
>> Rabbi Rob Thomas   Team Cymru
>>"It is easy to believe in freedom of speech for those with whom we
>> agree." - Leo McKern
>> -BEGIN PGP SIGNATURE-
>> 
>> iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAl3Rx08ACgkQQ+hhYvqF
>> 8o0snw/8CxTOujcodNh/huMXZaUNlMNoNRz3IoPqBiAP9BZomMz9xqlpDW/qvWBF
>> xhoJ07C0O0mo5ilNjnPR308uifIBu6ylw02PshOCU06dV0afgtndxGg5AoG9npUV
>> 7uCi2afWaf22dq5TwKLut8QPNNQJTRzndX88xJw9MzzoBTemxRtM7ft4H3UhJ0hv
>> oKo83FCNZQt36I+GZA9GBJeXM+o0f5h0w6fhRqARzttf6brJZdXgROyIQ7jptGuZ
>> N3Yrjk/8RM4XKMnYbtIwl8NS3c0nEGN3ndn+Bz7p2FE7QJrZKonk/o03dvr2kU0Y
>> 7gUQliOOzV9EsptVGyLCVyDJSElvXTBaps0giEVZhdmEIDJPWvBc+93j1g7xbmti
>> 27lT6+5qBmEN0oKJWxXgtw9/n1yX9vsc7tXlgYDoXGhIlszdB3baRao1tYEp8BBQ
>> hTGAULRfHe94tRzvOOQUQIuhzNcK1Q4E2jU6kzBB1wJsBD4zuHk+QIJLSHBmmnka
>> VNKlQ+5zP8dmSMBp6k4feqAtt3hy0Bj+34FbdQZYPutIe3VXHEjpWI3jI9vKjhtC
>> g7U/9CQIjVUl2APn1IllArpUpETBlNq7dSeJNUN/4Xh+eHglUnEn/m2kFG5mizmP
>> d0YvLEVe0/+WzDUz+y3KxDVP5tdJT1VM46FHIgeiB4KrWNGRPUo=
>> =uuel
>> -END PGP SIGNATURE-


smime.p7s
Description: S/MIME cryptographic signature

Re: akamai yesterday - what in the world was that

[J. Hellenthal via NANOG]

That’s what she said

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 25, 2020, at 13:42, Alistair Mackenzie  wrote:
> 
> 
> Off-peak hours are on-peak somewhere else in the world. 
> 
>> On Sat, Jan 25, 2020 at 7:37 PM Darin Steffl  wrote:
>> Shouldn't game patches like this be released overnight during off-peak 
>> hours? Fortnite releases their updates around 3 or 4am when most ISP's 
>> networks are at their lowest utilization. It seems somewhat reckless to 
>> release such a large patch during awake hours. 
>> 
>>> On Sat, Jan 25, 2020, 12:08 PM Brandon Jackson via NANOG  
>>> wrote:
>>> "Call of Duty: Modern Warfare fragged our business VOIP: US ISP blames 
>>> outage on smash-hit video game rush
>>> This is Windstream, going dark..."
>>> https://www.theregister.co.uk/2020/01/23/windstream_fvoip_outage/ 
>>> 
>>> Apparently not everyone came out unscathed.
>>> 
>>> --
>>> Brandon Jackson
>>> bjack...@napshome.net
>>> 
>>> 
>>>> On Thu, Jan 23, 2020 at 10:14 AM Aaron Gould  wrote:
>>>> My gosh, what in the word was that coming out of my local Akamai aanp 
>>>> servers yesterday !?  starting at about 12:00 noon central time lasting 
>>>> several hours ?
>>>> 
>>>>  
>>>> 
>>>> -Aaron


smime.p7s
Description: S/MIME cryptographic signature

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[J. Hellenthal via NANOG]

... because you should be able to verify the site you are at is actually the 
site you intended to be at...

Let the old crap go. Besides the sheer amount of ppl left that have the older 
phones most likely are not going to Wikipedia anyway.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Dec 31, 2019, at 04:05, John Adams  wrote:
> 
> because no one should know what you read about or check out at wikipedia
> 
> Sent from my iPhone
> 
>> On Dec 31, 2019, at 00:30, Matt Hoppes  
>> wrote:
>> 
>> Why do I need Wikipedia SSLed?  I know the argument. But if it doesn’t work 
>> why not either let it fall back to 1.0 or to HTTP. 
>> 
>> This seems like security for no valid reason.


smime.p7s
Description: S/MIME cryptographic signature

Re: Paging anyone from ntpd.org

[J. Hellenthal via NANOG]

Rofl

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Dec 30, 2019, at 22:33, Seth Mattinen  wrote:
> 
> On 12/30/19 8:22 PM, Seth Mattinen wrote:
>> Is anyone from ntpd.org on here? You're pointing DNS at me for some reason. 
>> That zone (ntpd.org) isn't in our system. Your NS looks odd too, 
>> *.darkness-reigns.net and .nl? Is that legit? I don't know what it was 
>> before because I've never looked, but that seems off.
> 
> nevermind, I'm tired and confused ntpd.org with ntp.org. Just going to 
> wildcard *.ntpd.org to 127.0.0.1 and go back to sleep.


smime.p7s
Description: S/MIME cryptographic signature

Re: ServiceFinder: Ärendenummer 185392

[J. Hellenthal via NANOG]

Well if that ain’t just plain spam I don’t know what is!

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Dec 29, 2019, at 16:18, i...@servicefinder.com wrote:
> 
> 
> Vänligen skriv endast ovanför denna markering när du svarar på meddelandet. 
> Hej Scott Weeks, 
> Tack för din fråga!
> 
> Vi har nu registrerat ditt ärende och du kommer inom kort att bli kontaktad 
> av oss på Kundservice.
> 
> Du kan också få hjälp själv via vårt Support Center på 
> www.support.servicefinder.se.
> 
> Du har ärendenummer 185392 – och alla våra ärenden hanteras i den turordning 
> som de kommer in.
> 
> Vi kontaktar dig så snart vi bara kan, din fråga är viktig för oss.
> 
> Ha en fortsatt bra dag,
> --
> Med vänliga hälsningar
> Kundservice
> Öppettider: Vardagar 9-17 | Växel: 08-653 00 00
> Hemsida: www.servicefinder.se 
> --
> Detta meddelande skickades till sur...@mauigateway.com med hänvisning till 
> ärende 185392.
> [[a6e862e24e9f255dfb1e2e9c14f288dfee770f40-1483209862]]


smime.p7s
Description: S/MIME cryptographic signature

Re: Iran cuts 95% of Internet traffic

[J. Hellenthal via NANOG]

Yeah sorry to say any email list or not is going to be one of the things that 
are not going to get through unless ... you’ve taken extra measures to 
circumvent that.

Personally, email would be the easiest to block behind riuting.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Dec 29, 2019, at 15:57, Scott Weeks  wrote:
> 
> 
> 
> :: If you're trying to get information in/out of a 
> :: society that is raising network barriers to 
> :: realtime communication, then you need methods 
> :: that don't rely on a network and aren't realtime.
> 
> 
> This is a great idea, but 99.9% of folks use GUI
> email. :-(
> 
> scott
> 
> 
> 
> 
> --- r...@gsp.org wrote:
> 
> From: Rich Kulawiec 
> To: nanog@nanog.org
> Subject: Re: Iran cuts 95% of Internet traffic
> Date: Sun, 29 Dec 2019 09:11:23 -0500
> 
> 
> And this is why, despite all the disdainful remarks labeling such
> things as "antiquated", mailing lists and Usenet newsgroups are vastly
> superior to web sites/message boards/et.al. when it comes to facilitating
> many-to-many communications between people.  Why?  Well, there are many
> reasons, but one of the applicable ones in this use case is that their
> queues can be written to media, physically transported in/out, and then
> injected either into an internal or external network seamlessly modulo the
> time delay.  And because the computing resources required to handle this
> are in any laptop or desktop made in the last decade, probably earlier.
> 
> If you're trying to get information in/out of a society that is raising
> network barriers to realtime communication, then you need methods that
> don't rely on a network and aren't realtime.
> 
> ---rsk
> 
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: "Using Cloud Resources to Dramatically Improve Internet Routing"

[J. Hellenthal via NANOG]

See RFC 1149 & 2549 

;-)

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 7, 2019, at 11:29, Keith Medcalf  wrote:
> 
> 
>> On Monday, 7 October, 2019 08:55, Rich Kulawiec  wrote:
>> 
>> On Mon, Oct 07, 2019 at 04:42:11PM +0200, Stephane Bortzmeyer wrote:
> 
>>> Otherwise, an impressive amount of WTF. My favorite: "while
>>> communication by servers ___on the ground___ might take hundreds of
>>> milliseconds, in the cloud the same operation may take only one
>>> millisecond from one machine to another"
> 
>> My favorite: "The researchers expect their cloud-based system will be
>> more secure than the Internet is today [...]"  Apparently they're
> blissfully
>> unaware that there is no such thing as "cloud security".
> 
> I would be interested to know how one connects to their "cloud"?  Do I
> need an "Evaporation Adapter" for my computer to send to their cloud?
> And do I need a "Rain Collector" to receive from it?  I suppose I also
> need the computer to be outside exposed to the elements -- putting it
> under a brolly would interfere with incoming rain from the cloud ...
> Plus I suppose it would not work very well at all in the desert, but
> downloading would be very high bandwidth in the rainforest (or during
> monsoon season).
> 
> :)
> 
> -- 
> The fact that there's a Highway to Hell but only a Stairway to Heaven
> says a lot about anticipated traffic volume.
> 
> 
> 

Re: IPv6 Pain Experiment

[J. Hellenthal via NANOG]

And in which part of the header is this to be added ?

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 6, 2019, at 15:58, b...@theworld.com wrote:
> 
> 
>> On October 6, 2019 at 15:18 mpal...@hezmatt.org (Matt Palmer) wrote:
>>> On Sat, Oct 05, 2019 at 04:36:50PM -0400, b...@theworld.com wrote:
>>> 
>>> On October 4, 2019 at 15:26 o...@delong.com (Owen DeLong) wrote:
>>>> 
>>>> OK… Let’s talk about how?
>>>> 
>>>> How would you have made it possible for a host that only understands 
>>>> 32-bit addresses to exchange traffic with a host that only has a 128-bit 
>>>> address?
>>> 
>>> A bit in the header or similar (version field) indicating extending
>>> addressing (what we call IPv6, or similar) is in use for this packet.
>> 
>> How does that allow the host that only understands 32-bit addresses to
>> exchange traffic with a host which sets this header bit?
> 
> As I said, it doesn't, but it lets each host decide that rather than
> the router tho if the host just knows enough to copy out the entire
> src/dst address (imagine the bits beyond the first 32 were in
> something like an extended ICMP options field w/in the IP header) then
> the rest could operate identically to ipv4.
> 
> So all you'd need added to a host IPv4 stack would be if you see this
> extended addressing flag/bit/whatever then there's more that needs to
> be copied out to each outgoing IP packet.
> 
> It would be the routers' job to interpret those extra bits for routing.
> 
> -- 
>-Barry Shein
> 
> Software Tool & Die| b...@theworld.com | 
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*