For example, an IoT lightswitch in your home should only talk to what looks like an MQTT broker in the AP. It doesn't need to have any concept what that topic it publishes to does. Similarly, the receiving light doesn't need to know what caused it. This way those devices literally never need any external network access at all.
I started working on this idea by playing with OpenWrt hosted video relays, and learned that it works, and am now extending it: https://github.com/atomirex/umbrella
Right now I am on HN procrastinating when I should be producing a video of ingesting from a TP Link security camera (really) into a webrtc SFU on the AP, sending it to another SFU, and watching the result.
In practice, this will work very poorly. Your whitelist will end up looking like "All of Azure, GCP, AWS, and CloudFlare, plus some one-offs"... which doesn't really stop anything.
I work at a BigCo that tries to do what you're proposing and it works so, so badly. Thankfully, we can turn off the "security" software that does this on our workstations. Unfortunately, cannot do the same for our software that runs on datacenter-hosted hardware that IT manages.
> Clients shouldn't connect to the Internet by default...
I have a couple of VLANs on my LAN that don't provide Internet access just for this reason.
Why?
* A huge-ass slice of the things hosted on The Internet are hosted in or behind one or more of Azure, GCP, AWS, and CloudFlare.
* Recording the set of "cloud provider"-provided IP addresses spoken to by a piece of client software is a bit of a fool's errand. The nature of those services is that one can change the IP address assigned to one's deployed software at a whim... and it's often cheaper to set things up so that one doesn't have an IP address for one's services that survives a VM reboot.
Malicious software is malicious regardless of whether it's running as a VM on Someone Else's Server, or a Linux process on personally-owned bare metal.
> Saying we "need" APs to segment VLANs is missing the point.
> What we "need" is for IoT devices to communicate through purely local networks and have no Internet access. [They will do this via a mechanism using MQTT where they're required to declare if they're bad.]
a) Who said anything about APs? While I do have WiFi Access Points (that I did not mention), I also have hard-wired VLAN segmentation. [0]
b) From a network design perspective, it's a lot easier and more efficient to provide a VLAN that doesn't have Internet egress than to attempt to sort out which of a mess of hosts are permitted to talk to the Internet from which aren't, and ALSO prevent MAC- and/or IP-address spoofing to evade any such filtering.
c) I have no idea why you're invoking MQTT (specifically), but any scheme that requires a potentially-untrusted host running potentially-untrusted hardware and software to declare whether or not it's to be trusted is doomed to failure right off the bat.
[0] Sure, I'm a power user. But, a "VLAN-isolated network for untrusted machines" feature shouldn't be something that only power users get. This SHOULD be a baseline feature in consumer-grade WiFi APs and switches. (The race-to-the-bottom feature of the "market" for consumer gear is very sad.)
The point is isolating devices from each other isn't what people need. They need their devices to accept commands from each other or their computer/phone. What they don't need is their devices to talk to half the Internet.
My htpc talks to exactly one machine, for example (my NAS). It's trivial to audit and would work fine if I blocked Internet access or gave it a whitelist. For people that use home assistant, again their devices should need to talk to a broker and that's it.
A reasonable device only talks to a handful of locations because you didn't ask it to do anything else. The world where Android and Windows and IoT devices chat all day to thousands of servers is what's the problem. Restricting such devices to only talk to the Internet is exactly the wrong solution. You could lock things down once there's an ecosystem in place for local control, but doing it now just ossifies the existing dumpster fire.
If one were to suggest regulation is needed for security (and governments are starting to do so), then what's needed is to ban cloud devices.
When talking about these things in a tech-savvy forum, you'd do well to separate the components (switch, WiFi AP, router) out, rather than thinking them as one indivisible unit. It helps for clarity of conversation and thinking. You have some misconceptions that might arise from this muddling you're doing.
> The point is isolating devices from each other isn't what people need. They need their devices to accept commands from each other or their computer/phone. What they don't need is their devices to talk to half the Internet.
When did I suggest isolating these devices from anything other than the Internet?
The whole point of having a router tied into the various VLANs on your network is so that you can program the router to decide what off-subnet traffic goes where. If you want to have a fully-isolated VLAN, you can... but I never mentioned any isolation other than from Internet egress.
> A reasonable device only talks to a handful of locations because you didn't ask it to do anything else.
If you purchase devices that are hard-coded to talk to machines hosted on someone else's servers, and you don't want to reverse-engineer and take ongoing maintenance responsibility for the software running in those devices, then your only choice in the matter if the manufacturer chooses to "host" those servers in GCP, AWS, or similar is to prevent the devices from talking to the Internet at all.
You might also review this conversation I had regarding the infeasibility of making a whitelist for typical devices and clients that demand Internet access: <https://news.ycombinator.com/item?id=42455401>
In that case I suppose the point is that what's desirable as an end-state from a security perspective is that none of these devices access the Internet (ideally with a firewall rule enforcing that). In the usual home scenario where there is only 1 networking device, VLANs and subnets both seem to me like their main purpose would be to isolate clients from each other, which for mass-market purposes is currently counterproductive (as it basically makes cloud servers a requirement for non-experts). You could use them to make your firewall rules simpler, but then you need routing an multicast forwarding rules. What you really want is to get to a place where your firewall says that your PC/phone can access the Internet and nothing else can.
Basically the infeasibility of making a whitelist for typical devices is exactly the problem to solve/issue to regulate.
No, that was in all of my replies. I've been consistent about this.
> You could use [VLANs] to make your firewall rules simpler, but then you need routing an multicast forwarding rules.
If you're not going to be running your multicast software on a machine that is wired in to all relevant VLANs (like your edge router), then yeah, if you need cross-VLAN multicast you would need to have multicast forwarding set up on such a machine. You'd need to do the same for broadcast, which is "just" all-nodes multicast.
> In the usual home scenario where there is only 1 networking device, VLANs and subnets both seem to me like their main purpose would be to isolate clients from each other...
Then you're confused about how VLANs and subnetting are typically used.
I can think of three ways to do what I think you're envisioning.
1) Use the "client isolation" feature of WiFi APs. I think this uses something OTHER than VLANs, given that clients get allocated IP addresses from the same subnet as each other.
2) Create a subnet and VLAN per client and program your router to not permit traffic originating from these special subnets to go anywhere other than direct to the router or out to the Internet.
3) Have one or more fairly fancy switches that are programmed to only permit packets to flow from each client port to the router port. (I'm pretty sure that this is conceptually what the often-present WiFi "client isolation" feature is.)
I know that you cannot prevent clients in the same subnet and VLAN from talking to one another unless you have direct intervention by a wireless or wired switch. This is because clients in the same subnet trying to talk to each other don't bother talking to the router and just use ARP (or ND) to find their conversation partners.
I'm not CERTAIN, but I think that if you try to have clients in the same subnet, but on different VLANs, it will work poorly (or not at all) because the router will have a hard time with route selection for incoming traffic, as well as traffic originating on the router to the client subnet.
Ideally Apple will resurrect the Airport and make it easy to have privacy and security in the home. An Airport-HomePod combo could do a lot of neat AI things in-house / on-prem.
That having been said, I don't know for sure that most generally available consumer devices would actually work under this arrangement.
I think throwing those features out is a tough sell for the home consumer market, but makes sense in the SMB and above area.
Multicast is widely exploited for fingerprinting by smart TVs, unfortunately, much as I think mdns is a beautifully elegant idea.