On Monday 22 June 2015 23:11:10 Lankswert, Patrick wrote: > When a query for "lights" is preformed, both instances respond from their > resources > Instance #1 reports: > coap:\\192.168.0.1\light > coaps:\\192.168.0.1\light > Instance #2 reports: > coap:\\192.168.0.1: 15683\light > coaps:\\192.168.0.1:15684\light > > This assumes that the light resources can be accessed "in the clear" and > securely. If they cannot be accessed "in the clear", the first entry of > each response should be removed. Note that the missing port number means > "use the default port".
That is true, but I'd advise against doing that. If instance #1 uses the shared port for unicast, then Instance #2 gets unnecessarily woken up by all unicast traffic. Unless we can prove that this is a single-application device, we should not use the shared port for unicast. > I am not sure how secure discovery works in this world. I am aware of secure > multicast, but as I recall the group changes keys each time a member is > added or removed from the group. This implies that they are already aware > of each other, so I am not sure that secured discovery is necessary since > membership is already known. > > I might otherwise assume that secure discovery is a combination of multicast > "in-the-clear" to discover devices and 1-to-1 unicast discovery to the > secure port for resource discovery. Indeed. The security team should figure out a way so that discovery can be secured against eavesdropping. If that is not possible, then at least the reply should be secure. Either way, the client sending the discovery needs to list which port number it's listening for DTLS unicast replies on. It should NOT send its IP address in the payload. That would be redundant. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
