On Friday 24 April 2015 13:32:13 Light, John J wrote: > > Firewalling is not in any IoTivity spec that I know. Let's keep it > > simple until we understand the need. We can always add RECVPKTINFO in > > if we need it since the effect is localized. > > Firewalling is required because it's implied. The moment we decided to have > an API to enable only a subset of all interfaces, we need to ignore any > packets that are received outside of that set. > > The only other alternative is to not have any API at all for selecting > interfaces and make IoTivity always run on all interfaces. If the user does > not want them all, it will be up to them to set up firewalling rules in the > OS. > > This includes mobile phones. > > **John** When we talked about this in the past it was about selecting the > subnets we want to multicast on. That made sense to me as it allows an > application to designate a domain. If a firewall is needed, somebody > screwed up the networking system definition, and I don't see why we would > devote our scarce resources to mitigating it. As I said, feel free to > propose a firewall policy: without it, we don't RECVPKTINFO.
Let's break it down again. Are we going to allow the user of the IoTivity API to decide which interfaces to send multicast on? Or are we going to simply make IoTivity send on all of them, period? If the latter, then a device that is connected to the Internet (like a gateway) will need to have firewalling rules to prevent the multicasts from being sent or received on the Internet. That would be out of scope for IoTivity. If it's the former and we go for the solution we're discussing on IOT-497, then we need to discard packets that came in via the wrong interface. Think about it this way: in the gateway case above, the socket will receive UDP packets coming in from the Internet, but it should not act on them. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
