On Feb 16, 2021, at 9:03 AM, Gert Doering <[email protected]> wrote: > So, where would that IoT network get their addresses from?
To reach out to the cloud, it can use NAT64. To reach in, it needs IPv6, because there is no practical way to do NAT64 in the other direction. So the IoT router advertises an on-link autoconf prefix on the infrastructure link if there is no prefix on the link, and it advertises a non-default route to the prefix it’s advertising on the IoT network. Both prefixes are ULA prefixes, so it gets them by making them up with a random number generator. :) > How would the router in my house know that it should listen to this > RA, so other routed segments will be able to reach the IOT segment? > (Routers do usually do not listen to RAs) If you have a multi-subnet home network, you will get the same behavior you get now for IoT devices connected to different links: they won’t be useable other than on the link to which they are attached. In the case of an IoT stub network, you will be able to use devices on the stub network on the link to which it is attached. If you want more than that, you can set up prefix delegation. In principle the stub router could do HNCP where it’s available, but since that’s nowhere, and since HNCP doesn’t solve the naming problem, there’s not much point. > Because hosts do not send their outgoing packets to the "right" router, > depending on source address, even if they should - and because routers do > not honour RAs, so if the hosts sends a packet to the "wrong" router, > it will not be forwarded by "router A" to "router B", so it can be sent > to the correct ISP. Assuming BCP38 filtering on the ISP side, of course. > HNCP had/has the potential to make that work in a very nice way. Actually that would be Babel. HNCP doesn’t solve this problem. > Coming back to the original question: I think permitting some random > device to inject RAs into arbitrary networks to connect IoT stub networks > fully conforms to the mantra "the 'S' in IoT stands for 'Security’" What distinguishes a “random device” from a “not random device”? That’s the problem. If you are really concerned, you could have your “not a random device" filter out default RAs, but that would still cause operational problems—just fewer of them. And BTW HNCP is no more secure than RA. And on an HNCP network RAs are vital for informing hosts of which router to communicate with, because default routes won’t work in a self-configuring mesh topology. You might want to read the document I pointed you to.
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
