Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NAT Is the Enemy of Low Power Devices

blog.golioth.io

Post reply on HN
Print view View original

71–80 of 180 posts

Re: NAT Is the Enemy of Low Power Devices

#71

Post by hasheddan »

vv_ wrote: post #68
apple1417 wrote: post #46

I have worked on a device with this exact same "send a tiny sensor reading every 30 minutes" use case, and this has not been my experience at all. We can run an STM32 and a few sensors at single digit microamps, add an LCD display and a few other niceties and it's one or two dozen. Simply turning on a modem takes hundreds of microamps, if not milliamps. In my experience it's always been better for power consumption t…

Power Saving Mode (PSM), a power-saving mechanism in LTE, was specifically designed to address such issues. It allows the device to inform the eNB (base station) that it will be offline for a certain period while ensuring it periodically wakes up to perform a Tracking Area Update (TAU), preventing the loss of registration. This concept is similar to Session Tickets or Session IDs in (D)TLS—or at least, that’s how I l…

Great pointer! My sibling post in this thread references a few other blog entries where we have detailed using eDRX and similar low power modes alongside Connection IDs. I agree that many devices don't need to be immediately responsive to cloud to device communication, and checking in for firmware updates on the order of days is acceptable in many cases.

One way to get around this in cases where devices need to be fairly responsive to cloud to device communication (on the order of minutes) but in practice infrequently receive updates is using something like eDRX with long sleep periods alongside SMS. The cloud service will not be able to talk to the device directly after the NAT entry is evicted (typically a few minutes), but it can use SMS to notify the device that the server has new information for it. On the next eDRX check in, the SMS message will be present, then the device can ping the server, and if using Connection IDs, can pull down the new data without having to establish a new session.

Re: NAT Is the Enemy of Low Power Devices

#72

Post by vv_ »

procaryote wrote: post #39

It seems brave to let an IoT device talk to someone over an unencrypted wan though. They're often of pretty varying software quality and rarely updated. If you really want IoT wifi devices, put them on a separate wifi, and only let them talk to a local device that you can keep up to date. Assume they're vulnerable to local attacks over wifi and act accordingly, e.g. don't give the IoT wifi access to your other device…

The issue in IoT is that most people expect to be able to control their IoT (e.g. Smart Home) devices from outside of their network. This requires you to have a central server these devices communicate with or a similar deployment on-premises with a public IP address.

I've always wondered how it is economically feasible to run these central services without a monthly subscription. If you stop selling devices you'll go under fairly quickly.

Re: NAT Is the Enemy of Low Power Devices

#73

Post by vv_ »

justahuman74 wrote: post #2

Interestingly, IPv6 is not listed as the solution

Few cellular modems commonly used in IoT support IPv6, and not all mobile network operators provide an IPv6 address. Since cellular connectivity plays a major role in the industry, IPv6 cannot be used as a blanket solution to this problem.

Re: NAT Is the Enemy of Low Power Devices

#74

Post by kstrauser »

kazinator wrote: post #34
kstrauser wrote: post #24

Earlier quoted context omitted.

What NAT are you using that doesn’t have a firewall? I haven’t personally used one of those since the ‘90s.

The first NAT I used in the middle 90's was IP Masquerading in the Linux kernel, by Pauline Middelink. That had a firewall.

Same, but ISTR we had some Cisco gear where NAT (or PAT as they insisted; yes, I know difference; no, no one cared) had a different license or hardware requirement or something from firewall rules.

Re: NAT Is the Enemy of Low Power Devices

#75

Post by kstrauser »

PhilipRoman wrote: post #52
arcmechanica wrote: post #10

NAT was an good solution that the IETF came up with, we wouldn't be able to have the internet at our scale without it

The thing I like about NAT is that it is essentially an ISP side stateful firewall. I would migrate to the ipv6 globally addressed mode immediately if my ISP had a checkbox "disallow all incoming connections".

Your router almost certainly has that option.

Re: NAT Is the Enemy of Low Power Devices

#76

Post by PhilipRoman »

kstrauser wrote: post #75
PhilipRoman wrote: post #52

Earlier quoted context omitted.

The thing I like about NAT is that it is essentially an ISP side stateful firewall. I would migrate to the ipv6 globally addressed mode immediately if my ISP had a checkbox "disallow all incoming connections".

Your router almost certainly has that option.

Of course, it's probably the default everywhere, but with NAT the traffic never reaches me in the first place.

Re: NAT Is the Enemy of Low Power Devices

#77

Post by kstrauser »

PhilipRoman wrote: post #76
kstrauser wrote: post #75

Earlier quoted context omitted.

Your router almost certainly has that option.

Of course, it's probably the default everywhere, but with NAT the traffic never reaches me in the first place.

Interesting. My ISP passes both IPv4 and IPv6 inbound, expecting you to block them yourself.

Re: NAT Is the Enemy of Low Power Devices

#78

Post by yjftsjthsd-h »

PhilipRoman wrote: post #52
arcmechanica wrote: post #10

NAT was an good solution that the IETF came up with, we wouldn't be able to have the internet at our scale without it

The thing I like about NAT is that it is essentially an ISP side stateful firewall. I would migrate to the ipv6 globally addressed mode immediately if my ISP had a checkbox "disallow all incoming connections".

> I would migrate to the ipv6 globally addressed mode immediately if my ISP had a checkbox "disallow all incoming connections".

Does your router not already do that by default?

Re: NAT Is the Enemy of Low Power Devices

#79

Post by LegionMammal978 »

jeroenhd wrote: post #41
LegionMammal978 wrote: post #9

Earlier quoted context omitted.

Eliminating NAT makes virtual networking much hairier. E.g., my desktop is currently connected to a big enterprise network that keeps track of all devices and will only allocate one IP address per MAC address. That leaves no IPs for any VMs on my desktop to use, so they must go through NAT if they want to communicate with the outside world.

Based on your description, you're using NAT as a means to bypass network restrictions. It's a great hack that will do the trick wonderfully, but if that's the officially proposed solution then the network is not set up for what it's actually used for. Contrary to popular belief, IPv6 does have NAT, it's just stupid and unnecessary in most use cases. There are even different kinds of NAT; there's the "swap the public…

> Based on your description, you're using NAT as a means to bypass network restrictions.

The threat model on this big enterprise WAN isn't "an authorized user creates a VM on an existing machine", but rather "some rando plugs something in with an Ethernet cable and goes to town on the intranet services". It has a whole web portal where you can log in and register your devices. So it's not like anything's really being bypassed here.

Anyway, I still prefer NAT for VMs over most passthrough schemes, which I've found unreliable even on IPv4 networks. What the outside network doesn't know about can't hurt it.

Re: NAT Is the Enemy of Low Power Devices

#80

Post by LegionMammal978 »

namibj wrote: post #43
LegionMammal978 wrote: post #7

Earlier quoted context omitted.

An IPv6 router with a stateful firewall blocking incoming connections could have just the same issues with timeouts, I'd imagine. Switching to IPv6 doesn't just mean that anyone can make a P2P connection to anyone else (even STUN needs a third-party server to coordinate the two peers). (D)TLS session resumption (I'm not sure if their "Connection IDs" are that or something similar) seems like the most foolproof soluti…

But it'd be trivial to tell it to free the device from it, unlike with NAT, where you pretty much have to expire sessions to not run out of memory.

Not if the end user isn't in control of the firewall. (And if they were, then they could just forward dedicated ports for the devices they need.) It might not be as bad as the CGNAT situation, but there are plenty of big WANs that can't be reconfigured at will.
Post reply on HN