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

111–120 of 180 posts

Re: NAT Is the Enemy of Low Power Devices

#111

Post by leptons »

vv_ wrote: post #72
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 g…

I have all my "Tuya" IoT devices on a separate network, isolated from my personal intranet, and the cloud servers these devices talk to are in China. I pay nothing to "Tuya" for their cloud service, never have. If the "Tuya" service ever goes down, my home automation is also down, and that sucks. I'm trying to replace it all with "Tasmota" devices now, but it's not quite as easy or as cheap to do.

Re: NAT Is the Enemy of Low Power Devices

#112

Post by raggi »

What I want from platforms, and I fought for at one time in Google with no success: a platform API that provides applications a way to schedule packets when the radio turns on.

The mobile platforms in particular continue to assume that you can live with their high level HTTP stuff, and it's just not good enough. The non-mobile platforms largely don't even approach the problem at all.

Re: NAT Is the Enemy of Low Power Devices

#113

Post by raggi »

dave78 wrote: post #108
mannyv wrote: post #107

People have been complaining about NAT for decades. It's time to STFU. It's a well-known problem with a bunch of well-known solutions. If you don't like NAT you could go IPv6. But really, why do you need to talk to your device? If it's just reporting in NAT is irrelevant. If you want to do device management just write something into your protocol to check for updates/commands and deal with it on a periodic basis. You…

There are plenty of IoT devices that people want to execute commands on (anything remotely controlled, basically). Polling for commands on a periodic basis introduces lag into that process which is irritating. Furthermore, polling at a frequent interval can end up using a lot of power as well versus waiting in a receive-only mode for an incoming command.

The alternative to polling is unfortunately polling, which is what the article is about.

You can avoid polling for messages, but you have to send packets outbound regularly in order to maintain a NAT mapping & connection, so that the external side can send messages inward.

The latency is overcome this way, so latency is a solvable problem, but this need to constantly wake up a radio every In theory you might be able to avoid this with NAT-PMP / UPnP however their deployments are inconsistent and their server side implementations are extremely buggy.

Re: NAT Is the Enemy of Low Power Devices

#114

Post by lxgr »

username332211 wrote: post #101
immibis wrote: post #56

Earlier quoted context omitted.

What people really want is a firewall, and since NAT acts as a firewall, they confuse it with that. My university has a public IP for every computer, but you could still only connect to the servers, not random computers, from the outside. Because they had a firewall.

What ordinary people (as opposed to IT departments) really want is firewall that can't be accidentally disabled by pushing an overly permissive firewall rule. NAT/port forwarding, for all their faults make it rather difficult to write rules allowing traffic to a machine you didn't intend to expose to the world.

Then... make the firewall UI so that you can't accidentally push an overly permissive firewall rule?

Just because NAT accidentally achieves some good outcomes doesn't in any way imply that said good outcomes are somehow exclusive to NAT.

Re: NAT Is the Enemy of Low Power Devices

#115

Post by bluGill »

shipp02 wrote: post #35
vv_ wrote: 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?

cellular modems go nonfunctional/obsolete much faster than other systems. 3g is almost entirely gone worldwide. 4g is still around, but providers are already reducing how much their towers dedicate to it. The standards body is working on 6g, who knows when that will come and push out older stuff.

If the case of my car I don't care - I have never found a use for the cellular connectivity it has (if any). However there are lots of other devices where the cellular connectivity is important and users will want to upgrade the modem to keep it working. If cellular connectivity is just a marketing bullet point nobody cares about then integrated is good enough, but if your device really isn't useful without the modem make that modem replaceable for somewhat cheap.

Re: NAT Is the Enemy of Low Power Devices

#116

Post by lxgr »

lupusreal wrote: post #96
immibis wrote: post #56

Earlier quoted context omitted.

What people really want is a firewall, and since NAT acts as a firewall, they confuse it with that. My university has a public IP for every computer, but you could still only connect to the servers, not random computers, from the outside. Because they had a firewall.

Yeah but the average person wouldn't know to set up a firewall (and can't count on their ISP to have their best interests at heart.) Therefore the general public benefits from the degree of protection that NAT provides.

Then just enable the firewall by default, or don't even provide a way to disable it unless the user enters "developer/advanced/Pro (tm)" mode. None of these are valid excuses for NAT.

Re: NAT Is the Enemy of Low Power Devices

#117

Post by LegionMammal978 »

Dylan16807 wrote: post #93
LegionMammal978 wrote: post #79

Earlier quoted context omitted.

> 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…

> 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. Isn't that what the MAC filtering is for? I don't see the point of stop…

I might be misremembering some of the details (in fact, given that the web portal works, I think it might allow new devices to have local IPs, but bounce all outbound packets until they're registered), but however it works exactly, it does not like passthrough networking on VMs in practice.

(If I had to guess, just letting any machine have a million new IPs for the firewall to track has its own issues, so you'd end up with policies upon policies.)

In any case, sometimes middleboxes just don't behave precisely how we want them to, and that's why I'm skeptical of the typical IPv6 position of "a flat /64 network (or something emulating one) is all you'll ever need".

Re: NAT Is the Enemy of Low Power Devices

#118

Post by lxgr »

dent9876543 wrote: post #48
rcxdude wrote: post #38

Earlier quoted context omitted.

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).

Oh, I do that too. But to your point about not cheering on NAT, well I will because I see NAT as useful tool. It is not an opinion well aligned with the preferences of the IETF. But the purist model of transparent end-to-end networking has never sat well with me. It’s just not a thing we want.

So because you don't want it means that nobody can get it?

Because that's what happens if you advocate for NAT by default. Conversely, with "IPv6 + inbound-blocking-firewall on CPEs by default", everybody gets the same behavior by default, and people that want something else can get that instead.

Re: NAT Is the Enemy of Low Power Devices

#119

Post by clearint »

This article should clarify at the start whether TCP or UDP is under consideration. NAT idle timeouts for both are typically very different. RFC 5382 [0] specifies no less than 2 hours and 4 minutes for TCP. RFC 4787 [1] specifies no less than 2 minutes for UDP. Towards the end of the article it becomes clear that it's UDP.

The example diagrams also incorrectly show port numbers exceeding 65535. The port fields in TCP and UDP headers are 16 bits [2].

[0]: https://www.rfc-editor.org/rfc/rfc5382 [1]: https://www.rfc-editor.org/rfc/rfc4787 [2]: https://textbook.cs161.org/network/transport.html

Re: NAT Is the Enemy of Low Power Devices

#120

Post by lxgr »

nolist_policy wrote: post #50
jeroenhd wrote: post #42

Earlier quoted context omitted.

If they're not routed directly through the network card but use a virtual switch instead, the network upstream only sees the server MAC. If they're directly hooked into the network card they can have their own MACs, but that approach can make it hard to communicate between host and VM.

Also, multiple MACs does not work with wlan.

Why would it not? There's even a third MAC address field in the 802.11 headers for just that scenario, as far as I remember (i.e. to distinguish between "802.11 source/destination" and "Ethernet-level actual source/destination").
Post reply on HN