121–130 of 180 posts
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!
UDP still needs state tracking, unfortunately.
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.
Security and privacy is of course critical to all this, but the concept of internet itself is not wrong.
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".
It sounds like you want an ISP-provided stateful firewall though, upstream of your (metered, slow) connection, which I'd agree would be a great feature to have!
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…
Earlier quoted context omitted.
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.
Either it would or it wouldn’t help in most cases, but the absence of consideration of it at all weakens the article’s arguments from a carrier perspective. IPv6 adoption was at 90% by US mobile carriers a couple years ago, and the US is not known for its telco infrastructure investment; so, while using IPv6 may not be a uniform cure for their issues, the article’s total focus on legacy IPv4 NAT issues is in stark co…
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?
The US 3G shutdown required some rather expensive and unexpected upgrades. Vendors signed long-term contracts with 3G providers, and then "someone" was on the hook, to replace something, when the 3G vendors terminated their contracts prematurely.
The deeper the modem was integrated into a product, the harder it was to change. The shallower the modem was integrated, the easier it was to change.
For example:
One of my cars just lost its internet connectivity, and the automaker never offered any way to fix it. (I didn't care, I only used Android Auto in that car.)
My employer (IOT) sent out free chips to our customers. They had to arrange someone to go do a site visit and swap a chip while on a phone call with us. We're small and early enough that it wasn't a big deal.
My solar panel vendor wanted me to $pend big buck$ on a new smart meter and refused to honor their warranty. I told them to run a cable to the ethernet port in my meter.
Earlier quoted context omitted.
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").
[1] https://lore.kernel.org/netdev/1258465585.3682.7.camel@johan...
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…
Doesn't this just move the 'state' into the operating system, or networking layer, in the form of an active TCP connection?
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.
I agree until I discover I'm doing something where I want to access/change that device. It is really nice when I'm returning home early that I can change my thermostat out of vacation mode. I've often wished I had a way to tell if I left a door unlocked. Security and privacy is of course critical to all this, but the concept of internet itself is not wrong.
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.