Thiago, I agree there's been a breakdown. :-) The plan to this point is to allow the application control over which interfaces are involved in a multicast, and the IOC OSWG is considering a proposal for doing just that, as you know. So it's your "former case".
"then we need to discard packets that came in via the wrong interface". When client A performs a findResource on a specific set of subnets, the expectation is that every server on those subnets is an intended recipient and is expected to respond if it matches the query in the findResource call. (Calling without a query should be discouraged, though we do it a lot for testing.) So in a real IoT environment, client A will ask for "rt=/zabu/light", and server B will ignore the request if it don't have that resource type. findResource multicasts don't happen that often, and they are filtered trivially. Your statement implies that server C has a "/zabu/light" but wants to keep quiet about it under some circumstances. While I can imagine a weird boundary condition where that is necessary, I can't believe we want to spend any more mentons on it. As I said, if you feel firewalls are necessary, make a proposal, and people above my grade level will decide. Until then we don't need to know what interface we're using in the socket layer. John -----Original Message----- From: Macieira, Thiago Sent: Friday, April 24, 2015 1:46 PM To: Light, John J Cc: ashok.channa at samsung.com; iotivity-dev at lists.iotivity.org; MyeongGi Jeong; Keany, Bernie Subject: Re: Change in iotivity[master]: Integrated WIFI/ETHERNET adapters to single IPAdapter. 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
