jjjjmoney

While there is some merit in having a secure LAN, I see where you’re coming from.

I assume anything leaving the LAN is insecure, and why I prefer secure protocols. However, this is often impractical for many devices and projects on the LAN side.

Our Charter Spectrum “cable” connection goes over a microwave link like this.

How do I know? Well, we had a pretty big wildfire a couple years ago that burned a microwave tower a couple hours away. The official response was that they couldn’t get internet back in town until they rebuilt the tower. Our internet was down for a couple weeks until it was safe enough for them to get back to the tower site.

I knew families like this growing up. To me it’s less about how long they have been here vs if they are first or second+ generation immigrants. It has always seemed like the second generation onward picks up English.

* I’m obviously a small sample size dealing with a single immigrant population in one state, but that’s my experience.

Personally, I’d like to see a slower addition of features in something as critical as OpenSSL.

LibreSSL (part of the OpenBSD project) has been aggressively pruning and hardening the codebase and is not immune to bugs. Security in crypto libraries is very hard.

> I reached out to their engineering management on LinkedIn, and got put in touch with the local NOC director.

I hate that this is a thing. I'm dealing with a similar potential issue on Charter Spectrum right now. Specifically it's an issue that's called out here https://blog.cloudflare.com/ip-fragmentation-is-broken/ (failing the IPv4 fragmentation test http://icmpcheck.popcount.org/ ).

How on earth is one supposed to get past the front-line tech support in 2023?

I wonder if when these things leak and become ever-more damaging, biometrics will basically become worthless and we will pivot to hardware tokens or something else.

There seems to be little resistance to this in the USA, and we’re also okay with abysmally bad forms of identification (SSN, birth certificates).

I’m trying to dig up the M17 messages on the chipsets, but until then - WiFi is incredibly popular and operates on ISM bands. Same with LoraWan, and I have seen some proprietary 900Mhz mesh devices (I think called Milo(?)).

The M17 project found some low cost transceivers that operate on a pretty low level, and I think those would be relevant for future development on ISM for people wanting to use encryption.

I’m just coming back to this thread to answer some of the other comments over the next few days, but WiFi does count here. It operates on ISM bands, AFAIK there are OSS chips, and it allows encryption.

What’s more interesting to me is that the M17 project has found some chips on aliexpress that are lower level and work on a multitude of bands. I’m trying to find this and will update when I do.

The problem with encryption is that it discourages interaction between hams (which is already pretty bad, tbh). Yes, you’re supposed to announce your callsign, but my bet is that unsavory characters would take advantage of that. I think it’s pretty cool to listen in on different protocols and see what people are trying out (M17 is an excellent example).

FHSS is pretty trivial to “decrypt” these days with an SDR.

While you’re not wrong about experimentation, I feel like ham radio should be focused more on the radio side of things rather than encryption implementations. Implementing the hardware and software encoding/decoding is the hard/fun part (at least to me). Encryption should come as a piece of cake after than if you can achieve a given bitrate.

And again - there already are bands that allow encryption. A couple hundred bucks and a few applications, and you’re free to go nuts.

And I completely forgot, but ISM bands do allow encryption, are free, and there is plenty of hardware out there readily available.

There are ways to transmit encryption legally if you really want to. It just take a bunch of time and a little money to get the right licenses.

Encryption really isn’t in the spirit of ham radio, and the other licenses are honestly probably easier to get anyway.

I think the OC was speaking more figuratively.

Another more recent example might be the US throwing its weight around in the South China Sea - thus trying to protect it interests (and the dollar).

How is it any worse than IPv4?

This isn't entirely about static port-forwarding. As others have pointed out, STUN, VoIP, PASV, etc rely on deterministic NAT behavior to work. That is not always guaranteed, and often out of your control.

> Just tossing IPv6 as a replacement for ipv4 with out factoring that in while simply screaming into the void "NAT IS NOT A FIREWALL" will be of little comfort to the elderly retiree that has their home computer ransomwared, or the small business that is put under due to a cyber attack because the ipv6 address was strait on the public internet

This is definitely what I'm seeing. IPv4 is really engrained in us - I actually had a really hard time conceptualizing how things worked until I forced myself to learn by deploying dual-stack and ipv6-only networks.

The major downside I see right now is that "addresses are harder to memorize," but there are solutions to that as well.

Not even your ISP - it could be university, business, shared internet for apartments, etc.

Yes this is absolutely possible, but I do like that IPv6 doesn't mandate NAT.

You might not but NAT has many different flavors, and many people don't get to choose which is used on their network.

https://serverfault.com/questions/208522/what-is-strict-mode...

This can particularly play havoc with sensitive protocols like STUN. I believe many game consoles make use of this when in multiplayer matches. I have personally run into this using OpenBSD's pf, but I'm fortunate enough to have access and the known-how to fix it for my consoles.

It's one of those things that's fine until you run into "edge cases," and unfortunately NAT configurations can introduce a lot of undefined behavior from the user perspective.

> ok, but why?

Because NAT breaks a lot of services.

> Is that going to change with ipv6?

Yes. You no longer need NAT, so port negotiation is much easier (even when inbound is blocked)

> Are you _really_ just going to allow random traffic into your network?

Common misconception! Even without NAT, the router can have port/traffic policies. There's just no address translation happening.

There's a lot of good stuff about IPv6, and I would encourage more people to learn about it and try it out.

- ULAs can act like static internal LAN addresses

- A "strong" NAT is easier to avoid and no longer breaks connections to things that are sensitive like gaming consoles

- Randomized, temporary IPv6 public addresses are a nice feature, and mostly turned on by default

- The biggest one is people seem to equate NAT = router/firewall. This is absolutely not the case, and they are distinctly different. You can absolutely have a router/firewall without NAT!

- CG-NAT is becoming more popular due to the lack of IPv4 addresses, and I hate everything about that.

- You can even run a NAT64 to provide IPv4 access to your IPv6-only devices

I don't think Apple is the pinnacle of repairability by any means, but they have been making slow improvements in this area (like replaceable back glass in the new model phones, the entire mainboard doesn't need to be replaced for common repairs as often now, etc).