Live data from Hacker News

NAT Is the Enemy of Low Power Devices

blog.golioth.io

31–40 of 180 posts

Re: NAT Is the Enemy of Low Power Devices

#31
post #20

The problem(-s) described in the blog post are really acute for IoT in general, especially if you want your device to run on batteries or you have a limited data budget. > Therefore, when you try to continue talking to the server over a previously established session, it will not recognize you. This means you’ll have to re-establish the session, which typically involves expensive cryptographic operations and sending…

Is DTLS a workaround for the session issue? Haven't had much experience with it myself but it does cut down some of the statefulness.

Re: NAT Is the Enemy of Low Power Devices

#32

Earlier quoted context omitted.

[flagged]

Could you elaborate for someone who is unfamiliar?

Zephyr RTOS[1] is an RTOS supported by the Linux foundation. It has similar structures to Linux for device configuration like a device tree and tries to emulate POSIXish APIs. I think some embedded people are put off by this configuration structure.

Notably, Zephyr RTOS is the basis of Nordic Semiconductor's SDK[2]. Nordic is a major manufacturer of cellular and wireless MCUs.

[1]:https://www.zephyrproject.org/ [2]:https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/index...

Edit: GP seems to have a history of posting 1 line hot takes with no elaboration

Re: NAT Is the Enemy of Low Power Devices

#33
What you can do is port forwarding. You have a bunch of devices behind a 1:N NAT, so they share one IP address. For specific services on those devices, you can pair dedicated ports with this IP address, binding them to internal IP:port pairs.

It's not a perfect solution for every scenario, and requires configuration, but there it is.

This is how people on residential lines run web servers, mail servers, ... they map TCP ports like 443, 80, 22 and 25 on their router to go to specific internal hosts.

Doh!

Re: NAT Is the Enemy of Low Power Devices

#34

That NAT is a problem presumes that we actually want our IoT devices reaching out to the out-of-intranet zone. NAT gets the blame, and the intranet as a concept is generally a big corp term. But I prefer my IoT devices not to need to reach out of my network. For me, NAT is an unwitting ally in the fight against such nonsense.

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.

Re: NAT Is the Enemy of Low Power Devices

#35
post #20

The problem(-s) described in the blog post are really acute for IoT in general, especially if you want your device to run on batteries or you have a limited data budget. > Therefore, when you try to continue talking to the server over a previously established session, it will not recognize you. This means you’ll have to re-establish the session, which typically involves expensive cryptographic operations and sending…

What makes a separate cellular modem better than an internal cellular modem? Is it because software updates are available for the separate modems?

I am evaluating some Nordic semiconductor parts for a project. They seem to have an internal modem but Nordic uses zephyr. Any thoughts?

Re: NAT Is the Enemy of Low Power Devices

#36

That NAT is a problem presumes that we actually want our IoT devices reaching out to the out-of-intranet zone. NAT gets the blame, and the intranet as a concept is generally a big corp term. But I prefer my IoT devices not to need to reach out of my network. For me, NAT is an unwitting ally in the fight against such nonsense.

Especially if the data is unencrypted and only authenticated by source ip and a long lived token-like thing

Re: NAT Is the Enemy of Low Power Devices

#37
Isn't this the whole point of Thread? You have a low power mesh network for inside a deployment (house, office, factory, whatever) and it's the border router which does the "communicate with the internet/lan/wider network" piece. These are typically plugged in (so no worries about having to be low power) have plenty of memory (so no worries about having to drop established routes like a router).

Re: NAT Is the Enemy of Low Power Devices

#38

That NAT is a problem presumes that we actually want our IoT devices reaching out to the out-of-intranet zone. NAT gets the blame, and the intranet as a concept is generally a big corp term. But I prefer my IoT devices not to need to reach out of my network. For me, NAT is an unwitting ally in the fight against such nonsense.

If you don't want that, then complain about a lacking a configuration as such and configure your firewall so that that they can't. But don't cheer on something that's breaking functionality that others might want (especially if it doesn't actually achieve your own goals reliably).

Re: NAT Is the Enemy of Low Power Devices

#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 devices beyond to that controller, and definitely not to the wider internet.

If they're closed source, assume they're already compromised from the factory

Post reply on HN