My point is very simple: if you create a socket and bind it to INADDR_ANY / in6addr_any and do not specifically bind it to an interface, then it will receive packets in all interfaces. This may include packets from interfaces that we are not sending multicast on.
In the case of a gateway, it would mean receiving packets from the Internet too, which could be malicious, intended to poison the OIC server with superfluous data (DoS attack) or even break into it. Secure coding procedures require us to do early detection, authentication and authorisation of those packets, so that they cannot pose further harm into the application and the network. Maybe the DTLS layer is enough: without knowing the DTLS session keys, an outside attacker would not be able to craft the correct packet and it would be discarded on decryption as invalid. But someone has to prove that this is enough. In fact, we may need to be enough, since we could receive routed packets via the network, even on devices with a single interface. On Friday 24 April 2015 14:33:42 Light, John J wrote: > 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 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
