Hi John, See below for my responses.
Sachin From: Light, John J Sent: Thursday, June 18, 2015 6:15 AM To: Agrawal, Sachin; iotivity-dev at lists.iotivity.org Subject: RE: Proposal for IP Adapter and request for feedback Sachin, Thank you for describing so completely how secure communication works. I have some questions for you. 1. If IoTivity stack communicates all secure traffic on 5684, which is not set with REUSEADDR, how does a second instance (or a non-IoTivity CoAP app) work on the same device? With the described usage, the second instance (and other secure CoAP applications) will fail. I don?t believe we have the right to gain exclusive use of the secure CoAP port. <<SA: Second instance picks up another un-used port for secure communication. Although, I do tend to agree with your opinion that ?it maybe wrong behavior to use ?5684? exclusively.>> 2. You say ?if another Iotivity stack is started on the same platform, it?s secure port will be different?. I don?t see how this works in the code. If I have missed something, it still raises the question of why you use 5684 on the first instance of IoTivity, when you can?t use it for the second and third? If we can securely communicate without exclusive use of 5684 on the second and third instances, why can?t that also work on the first? <<SA: Answered above>> I assumed (incorrectly, possibly) that the two CoAP ports were both used for discovery and initial connection, 5683 for non-secure, 5684 for secure. By always unicasting to dynamic port assignments (secure and non-secure), all CoAP-based applications can share the same two ports simultaneously. <<SA: I agree with you here, but as always 'devils are in the details'. So I would suggest that let's discuss all use-case scenarios (including 'collections') and then move ahead, if we see this is the best path forward>> I assumed (incorrectly, possibly) that a CoAP application that wishes to communicate securely would discover using 5684 instead of 5683, allowing the receiving device to understand the desire for security at the earliest possible moment. <<SA: Yes. But this is not current Iotivity behavior.>> I assumed (incorrectly, possibly) that a multicast message will be sent from the port the multicast receiver should respond to, allowing simple use of dynamic unicast ports for all purposes other than discovery. <<SA: If we work with this assumption, it entails that a secure port 'WILL' receive encrypted and plaintext data. I do not believe this is the way 'https' works.>> After you provide answers to the two questions above, I will abandon my incorrect assumptions. John Light Intel OTC OIC Development -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7768 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150618/a01dd583/attachment.p7s>
