4 ms·
As someone with a background in electronics who doesn't manage any internet-connected equipment but has multiple embedded devices connected to a WAN, I'm glad t
by dlcarrier 10mo ago
As someone with a background in electronics who doesn't manage any internet-connected equipment but has multiple embedded devices connected to a WAN, I'm glad that IPv4 still seems to have a bit of life left in it.
When IPv6 was developed, over 30 years ago, connecting everything to the internet seemed like a great idea. I know that IPv6 can be made secure, but I don't have the background or research time to learn how to do so, and the NAT-by-default of IPv4 effectively means that I get the benefit of a default-deny security strategy that makes it impossible to accidentally directly connect anything to the internet.
I'm hoping I can keep using IPv4 until IPv8 or IPv4.5 or whatever comes next is developed with the modern proliferation of cheap insecure IoT in mind.
For some background on why IoT products are so insecure:
Hardware manufacturers don't really comprehend the idea of updates, let alone timely of security patches. Hardware has to work on the day of release, so everything is documented and tested to verify it will work. I have hardware with a TCP/IP stack that was released 20 years, (https://docs.wiznet.io/Product/Chip/Ethernet/W5500 https://docs.wiznet.io/Product/Chip/Ethernet/W5500) and doesn't have a single errata published, despite widespread use. This is expected for every single component, for even the smallest 1-cent transistor, which has dozens of guaranteed performance characteristics laid out over several pages of documentation (https://en.mot-mos.com/vancheerfile/files/pdf/MOT2302B2.pdf https://en.mot-mos.com/vancheerfile/files/pdf/MOT2302B2.pdf).
When manufacturers venture into a product that runs software, they don't realize that for a given complexity, working through undocumented or, worse yet, incorrectly documented APIs takes more time than the equivalent hardware development and documentation. I've worked on multiple projects where software bugs were fixed with hardware workarounds, because it's faster, cheaper, and easier to develop, test, document, retool, and add a few cents of bill-of-materials cost per product, than to get reliable output from the already-written library that's supposed to provide the functionality.
The hardware TCP/IP stack that I linked to was developed at a time when it was the cheapest way to connect a low-power embedded system to a network. Modern low-power embedded systems have multiple cores running at hundreds to thousands of MIPS making the resources to run a softtware TCP/IP stack trivial, but the product still sells well, because when security is an absolute must, the hardware development and maintenance cost for the functionality is still cheaper than through software, even when there's no marginal cost to run the software.
- radlad 10mo ago> the NAT-by-default of IPv4 IPv4 is not NAT-by-default. The reality of the world we live in today is that most home networks have a NAT, because you need multiple devices behind a single IP. That said, I agree: it's quite unknowable how many services I've turned on on local machines with the expectation that a router firewall sat between me and potential clients. But that doesn't go away with IPv6 - the NAT does, the router doesn't, and the firewall shouldn't either. For example, the default UniFi firewall rules for IPv6 are: 1. Allow Established/Related Traffic (outbound return traffic), 2. Block Invalid Traffic, 3. Block All Other Traffic You must explicitly open a firewall rule for inbound IPv6 traffic. NAT is not the firewall.
- cyberax 10mo ago> NAT is not the firewall. NAT _is_ a firewall. And a much safer one than IPv6 firewalls, because NAT will fail safe if misconfigured.
- radlad 10mo agoNAT is not a firewall: all it does is rewrite packets, it does not drop them.
- jonathanlydall 10mo agoThe article actually remarks on this kind of argument. While you are technically correct about NAT not being a firewall, it is in practice a widely used front-line defense which even if not “perfect”, it has indisputably proven to be quite effective against a lot of malicious activity. Against highly determined malicious actors you will of course want a proper firewall, but for 99% of people, NAT is enough to keep from being bothered by run of the mill malicious actors. Kind of like physical home security, a lot of it is very easy to bypass, but it’s good enough for the common threats.
- radlad 10mo ago> Against highly determined malicious actors you will of course want a proper firewall, but for 99% of people, NAT is enough to keep from being bothered by run of the mill malicious actors. Maybe, maybe not, but regardless 99% of people are not protected by a NAT. They are protected by a "proper firewall," which happens to support NAT (and typically, is enabled for IPv4 networks.) That is to say, while most home routers support NATs, they also ship with a default-deny firewall turned on. Typically, enabling NAT mappings also configures the firewall for users. But they are not the same thing and we need to stop conflating them because it causes a lot of confusion when people think that IPv6 is "open by default" and that IPv4 is "protected by NAT." It's not. They are both protected by your router using the same default-deny firewall.