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.<p>> 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 a handful of messages back and forth before actually delivering the data you were interested in sending originally.<p>The blog post mentions Session IDs as a solution, but these require servers to be stateful, which can be challenging in most deployments. An alternative is Session Tickets (<a href="https://datatracker.ietf.org/doc/html/rfc5077" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc5077</a>), but these may cause issues when offloading networking to another device, such as a cellular modem, as their implementation may be non-standard or faulty.<p><i>incoming rant</i><p>These issues could be mitigated—or even solved—by using mature software platforms like Zephyr RTOS and their native networking stacks, which receive more frequent updates than traditional “all-in-one-package” SoCs. However, many corporations choose to save a few dollars on hardware at the expense of incurring thousands in software engineering costs and bug-hunting. It is often seen as more cost-effective to purchase a cellular modem with an internal MCU rather than a separate cellular modem and a host MCU to run the networking stack. It is one of the many reasons why many IoT devices are utter garbage.
That NAT is a problem presumes that we actually want our IoT devices reaching out to the out-of-intranet zone.<p>NAT gets the blame, and the intranet as a concept is generally a big corp term.<p>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 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.<p>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.
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 to completely shut down the modem and start from scratch each time [1] - which means you're paying to start a new session every time anyway. Now I'll agree it's still inefficient to start up a full TLS session, a protocol like in the post will have it's uses, but I wouldn't blame it on NAT.<p>[1] Doing this of course kills any chance at server-to-device comms, you can only ever apply changes when the device next checks in. This does cause us complaints from time to time, especially for those with longer intervals.
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.<p>The example diagrams also incorrectly show port numbers exceeding 65535. The port fields in TCP and UDP headers are 16 bits [2].<p>[0]: <a href="https://www.rfc-editor.org/rfc/rfc5382" rel="nofollow">https://www.rfc-editor.org/rfc/rfc5382</a>
[1]: <a href="https://www.rfc-editor.org/rfc/rfc4787" rel="nofollow">https://www.rfc-editor.org/rfc/rfc4787</a>
[2]: <a href="https://textbook.cs161.org/network/transport.html" rel="nofollow">https://textbook.cs161.org/network/transport.html</a>
On modern firewalls/routers, NAT is only one cooks in the network kitchen raining on this author's parade. Stateful Packet Inspection has timeouts too!
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.<p>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.<p>If they're closed source, assume they're already compromised from the factory
NAT breaks the central idea of IP (i.e. packet switching with stateless intermediary nodes). All of its problems are essentially downstream from there.
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.<p>It's not a perfect solution for every scenario, and requires configuration, but there it is.<p>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.<p>Doh!
Wasn't IPv6 suppose to solve all this?<p>I don't understand why that stalled.<p>Also considering the state of iot security its probably not a great idea to have everything accessible anyway. But that's a slightly different problem to solve.
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).
> This doesn’t solve the issue of cloud to device traffic being dropped after NAT timeout (check back for another post on that topic), but for many low power use cases, being able to sleep for an extended period of time is <i>less important</i> than being able to immediately push data to devices.<p>Is "less important" a typo?
> This doesn’t solve the issue of cloud to device traffic being dropped after NAT timeout (check back for another post on that topic),<p>This is the key problem. I think it would be best solved by NAT devices having some way of probing their timeout policy, and then notifying the endpoints when they expire a mapping.<p>One way to do that might be for a client to deliberately send a packet to the server with an insufficient TTL.<p>The reply (via ICMP) could then contain fields specifying the timeout in minutes of the mapping, together with some generation number specifying if the mapping table has been cleared due to reboot or overflowed since last queried.<p>There might even be a way to request a specific mapping become long lived - perhaps for months or years.<p>The benefit of all this is that client devices can do push notifications from servers or P2P notifications, all with no polling - allowing for example coin cell devices to last for months or years (with appropriate WiFi protocol improvements too)
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.<p>If you don't like NAT you could go IPv6.<p>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 can even do that on startup, so you can tell the customer to power cycle the device. It's unlikely that any IoT device needs instant updates, so long periodic updates are probably fine.