Hi John, Yes. If we say that Iotivity does not support zero-length tokens, then I assume address change may not have a impact on Request-Response matching in general? But, with DTLS security, we would have to find a mechanism to allow successful decryption of packets when sender changes its address.
Thanks Sachin -----Original Message----- From: Light, John J Sent: Wednesday, September 09, 2015 1:25 PM To: Agrawal, Sachin; Macieira, Thiago; iotivity-dev at lists.iotivity.org Subject: RE: [dev] Dealing with IP address changes Sachin, I believe what Thiago is saying is that the IP addresses "will" change over longer periods of time, independent of any desires by IoTivity or IoT application designers. So the issue is whether the stack can deal with it. Outside of security, it can, I think. So the question now is whether security can deal with such changes in the IP addresses. Thanks for mentioning the zero length tokens; I didn't know about them. I don't think the IoTivity code handles that case, and they would certainly break IoTivity if the IP addresses changed. (I don't really understand how they work, since a primary purpose of tokens is to match multicast discovery requests to responses, and IP addresses can't be used for that.) John -----Original Message----- From: Agrawal, Sachin Sent: Wednesday, September 09, 2015 1:03 PM To: Light, John J; Macieira, Thiago; iotivity-dev at lists.iotivity.org Subject: RE: [dev] Dealing with IP address changes Hi, As per Section 5.3 from CoAP RFC, request/response matching should take into account the address information. I think the reason for this is to allow tokens with 'zero' length. Irrespective of above, the scenario which Thiago is suggesting will cause some issues for decryption of packets. Currently, each endpoint manages a 'secure channel' based on endpoint address info...i.e. when a device will receive a encrypted packet from address A2, DTLS sub-system will try to retrieve TLS keys(for decryption of packet) associated with that end-point address and will fail in doing so. Thanks Sachin -----Original Message----- From: [email protected] [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of Light, John J Sent: Wednesday, September 09, 2015 8:32 AM To: Macieira, Thiago; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Dealing with IP address changes Thiago, The matching of replies to requests is based on the token sent in the request and returned in the reply. The address is not used for matching, AFAIK. I don't know how DTLS uses addresses, so someone else will have to comment. John -----Original Message----- From: Macieira, Thiago Sent: Wednesday, September 09, 2015 8:11 AM To: iotivity-dev at lists.iotivity.org Cc: Light, John J Subject: Re: [dev] Dealing with IP address changes Hi John The problem is matching a reply that came from address A2 to a request that was sent to address A1. Does this matching need to happen before the DTLS layer kicks in? On Tuesday 08 September 2015 08:48:08 Light, John J wrote: > Thiago, > > I don't fully understand how the situation you describe unfolds, so I > don't have a complete answer, but I have a piece of the puzzle. > > Every time IoTivity receives a response concerning a resource, it > returns the latest address in the C API and updates the address in > OCResource for the C++ API. So if a server changes its IP address, a > C++ client will use the new IP address, and a C client will be able to. > > John > > > > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org > [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of Thiago > Macieira Sent: Monday, September 07, 2015 8:36 AM > To: iotivity-dev at lists.iotivity.org > Subject: [dev] Dealing with IP address changes > > On IPv6 networks with non-link local addresses, it's very common (and > recommended) that devices use a randomly-generated IP address that > expires after a pre-determined time. After that happens, the device > will generate another device and start using it. > > There's also a grace period in which the old address is still > available, but is not preferred. That is to say, it's no longer > selected by default as the outgoing address of any packet. A device > can still be reached with this address, though. > > Question: how does IoTivity deal with this? And how does the OIC > protocol do it? > > Scenario: DeviceA and DeviceB are happily communicating with each > other, over a DTLS-encrypted channel. The type of communication is not > relevant, as it can be: > * regular unicast request-responses > * OBSERVE replies > * UDP-based block transfer > > What happens if the device sending a packet suddenly changes its address? > > Let's say that DeviceA is about to send a reply to DeviceB. DeviceA > had address A1 that it used in the last packet. For the next packet, > A1 lost freshness and A2 is now the preferred address. > > Should > 1) DeviceA send still with A1? If so, how will DeviceB be told that > the address has changed? How long is DeviceB allowed to cache the IP > address for DeviceA for the resource it had discovered? How about the > case of a > long- standing OBSERVE reply, how will DeviceB be told that the > address is changing? > > 2) DeviceA send now with A2? In this case, we need to assume that the > DTLS layer will continue to authenticate the sender regardless of IP > sender address. There is no problem here. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev -------------- 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/20150909/ff8308c8/attachment.p7s>
