Re: [TF-AP]: Using CoAP for bi-directional communication

> On 14 Sep 2015, at 22:19, Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com> wrote:
> 
> Thanks a lot for all this information Dave!
>  
> Interesting to hear about your experiments with lightweight libraries for networking chips.

I started down this path after learning about the limitations of existing libraries for the Arduino.

>  In the ideal world we would like to be able to, on cheap constrained devices, expose REST APIs to the resources of the device. We would like these APIs be accessible “anytime”. To make this possible with CoAP over UDP it seems as we need some kind of keep-alive messaging, which is not good for battery operated devices.

I understand that the NAT/Firewall connection state timeout is product dependent and typically 30 to 180 seconds for UDP, and something like 5 minutes for TCP.  For UDP keep-alive packets every 30 seconds is reported as working well. Coincidently, this is also a common default for the WebSocket keep alive interval. See:

https://msdn.microsoft.com/en-us/library/system.net.websockets.websocket.defaultkeepaliveinterval(v=vs.110).aspx

One detail, I am unfamiliar with is whether the firewall timeout depends on UDP packets being sent from the device within the firewall or whether it is sufficient for the server outside of the firewall to periodically send UDP packets to the device inside the firewall.  It may not matter that the device in the firewall is asleep and the packet sent to it is lost.  In this case, the connection could be maintained even though the IoT device only wakes up every few minutes.  In the absence of hard data, this may be something interesting to test on popular firewalls devices designed for home use, e.g. DSL modems/WiFi access points.

> I don’t think we can solve all use cases by server queuing messages until the IoT device wakes up by itself. Alternatively we might come up with some clever network initiated wake-up system. 

For battery operated devices, a timer interrupt or a hardware interrupt can be used to wake up the device. You may be able to design the electronics to wake the device up, but to save power, the MCU and network hardware would need to be in a sleep mode. Can you describe the use cases where you think that waiting until the next periodic wakeup to receive new messages would be a serious problem?

> It seems as, if the HW permits it, Web Sockets is the best choice for “bi-directional” use cases.

Given the above info on WebSocket keep-alive, there may not be a significant advantage over a UDP based protocol. In addition, MQTT is based upon TCP and provides an alternative to Web Sockets in that respect. 

> However, I would like to better understand the security issues you mentioning.

A commercial grade solution should support strong authentication, end to end encryption and security updates. This is quite complicated to implement.  Embedding a fixed symmetric key in the device firmware is a recipe for problems!  RSA based public keys are too expensive to implement on low end devices. ECC based public keys are better, and given hardware support, run 10,000 times faster than pure software implementations (according to Atmel). Hardware support is also important for good quality random numbers and secure storage of keys, certificates, and other settings.

Best regards,
—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>