Phil Let me Cc: iotops because it seems that might be where this topic could be best suited for, at least i'd prefer not to be guilty of starting a followup thread on ietf@xxxxxxxx for something of maybe a lot more limited interest. If you want to make a lot of IoT devices at home directly accessible from the Internet, you should explain how your mesh approach could or could not solve the security issue: IMHO if you make 50 IoT devices with unknown vendor software in the home directly accessible from the Internet you have a significant problem with the attack surface. You can try to minimize this by the typical reverse proxy for those type of devices, but i am not sure that there are not sufficiently many attacks that can as well go over HTTPs payload as over IP when there is weak application code on insecure built constrained IoT software in devices. Buffer overflow is AFAIK alive and kicking for example. One classical response to exposing such devices to attacks from the Internet is to then ensure the attack can't be propagate in the home. This is difficult with todays home network equipment, but easy with better "enterprise" equipment. Limiting connectivity between devices in the home. Especially for IoT equipment i hate that idea, because i like the p2p communication of such devices in the home. Light push-button device that directly communicates with the light devices, no "IoT controller" needed (yes, i like Home Assistant, but not that much). Instead, there needs to be a better security model from the Internet. Rregularily changing IPv6 addresses for example, which is difficult when your service provider does not offer it (but may work well enough once every 24 hours for example). But much more so, you want authenticated and authorized name resolution. Which AFAIK is not available in any DNS solution today. I know how i could build it into STUN for use with SIP, and i imagine this could be done with your mesh solutions too, so that would be an interesting topic. In any case, i think one needs to be prepared not to only be victim to randon pervasive attacks, but also to targeted attacks once some group is especially interested in you, and you don't want to change the names through which your IP addresses are resolvable, because thats just a big pain. Like changing your credit card. Or social security number. Cheers Toerless P.S.: wrt to bad IoT firmware, have you checked tasmota ? On Tue, Jul 01, 2025 at 12:03:05PM -0400, Phillip Hallam-Baker wrote: > When I first used the Internet in the late 80s, the only way to reach it > was through a University with a connection. There was something of a two > tier effect in place because the machines of the era were regulated by a > priesthood of system administrators. > > Part of the reason the Web won and competing network hypertext systems lost > was that anyone with access to a machine could run the HTTP service, albeit > maybe not on port 80. > > Fast forward to 1995 and we start to see a split between the ultra-fast > (T1!) connection at the university and dialup access. Dialup isn't just > slower, it is temporary. Nobody is going to want to be running a service > that matters over dialup (some did of course but nobody wanted to). > > Since then, broadband has replaced dialup. But that is all broadband has > done. I have 1Gb/s into the house but I don't have a full Internet > connection I can run services until Verizon's truck rolls to upgrade me to > a full business line with static IP addresses in the fall. > > Where we have ended up is with a two speed Internet in which residential > users have a greatly curtailed Internet experience over what someone with a > static IP address, a DNS name registration and (most important) some > serious network administration skills can achieve. > > In a few months time, roughly $750 worth of IoT gear I have installed in > the house will become unusable as network connected infrastructure because > the provider can't be bothered to support it. Guess what? I am never buying > an IoT device from that provider again, not ever and I suspect that will be > true of most of the customers they are trying to upsell with forced > obsolescence. The cloud based IoT model isn't just working any more. > > [Oh and please, stop your marketing droids lying about the necessity of the > money grabbing scheme. You are not fooling anyone but yourselves and you > are making people even angrier.] > > When I replace the thermostats it will be with Genuinely Internet Things > (GITs). That is: > > * They will have a DNS name > * They will have a WebPKI certificate > * They will support open authentication to a universal account (OAUTH or > TLS Client auth) > > Point is, if an IoT device is a GIT, I can reach it from a Web browser and > log in using an Internet account I control. The device I bought and paid a > fair price for will work without paying a monthly rent or suffering forced > obsolescence. > > If US manufacturers won't make these devices, we will have to do a > kickstarter for devices that meet our needs, that is a proven method of > gaining the attention of Chinese knockoff manufacturers. > > So what would it take to turn an ordinary residential broadband Internet > connection into something that a full featured Internet connection is > capable of? > > One of the principles of the Mesh is that any set of instructions you can > write down and give to a user can be turned into code. Same goes for system > administration. > > So what I am proposing is a package of services which in combination give > the user a full featured Internet experience without the need to have > particular network admin skills and can be deployed as either a cloud > service or a cheap $50 ish appliance. > > These are all essentially glue services and all essentially things we > already have but without the nth degree of automation required to make this > hang together. For example a service in the cloud reachable from network > devices behind a NAT that: > > * Provides bidirectional DNS resolution and authoritative publication. > * Provides ACME relay functionality > * Provides an OAUTH IdP to an account identified by a DNS Handle > * Operates a mini private CA for TLS Client auth > * Provides a presence service for connecting up MOQ calls. > * Relays inbound HTTP requests to devices authorized for external network > connections. > > None of these systems is complicated, most already exist individually but > putting them together requires serious systems expertise. Doesn't make > sense as a one off but a single capable person could easily provide a > service supporting thousands of users and companies already providing > Anti-Virus, VPN or Password management services could easily add these > services to their lineup. > > I will be in Madrid to talk about this with anyone interested. I already > have quite a bit of code. -- --- tte@xxxxxxxxx