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

Thanks Dave,

See below

Claes



Claes Nilsson
Master Engineer - Web Research
Research&Incubation

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nilsson@sonymobile.com<mailto:Firstname.Lastname@sonymobile.com>

sonymobile.com<http://sonymobile.com/>

[cid:image003.png@01D0F097.C741F1A0]

From: Dave Raggett [mailto:dsr@w3.org]
Sent: den 15 september 2015 11:18
To: Nilsson, Claes1
Cc: public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>
Subject: Re: [TF-AP]: Using CoAP for bi-directional communication


On 14 Sep 2015, at 22:19, Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com<mailto: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.

[Claes]: I am not sure that I understand your idea. I assume that you consider a “keep-alive” system that is more battery-friendly than when the IoT-device sends keep-alive messages. You say that it may not matter that the device in the firewall is asleep and the packet sent to it is lost. However, if the device should be able to accept REST calls “anytime” the device must be awake. So if it receives a UDP “keep-alive” message it drops it (or replies with an ACK) and if it received a message with a REST call it acts on it. Wouldn’t this cause basically the same battery drain issue as if the IoT device instead sends wake-up messages? Or am I misunderstanding you?.

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?

[Claes]: Use cases are when a server or another IoT device sends an alarm or notification that must be acted on immediately.

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.

[Claes]: You have learned me that Web Sockets keep-alive messaging may be as frequent as what is needed for CoAP over UDP. However, there are other advantages with Web Sockets compared to CoAP, e.g.

-        Could probably better pass “troublesome firewalls”

-        TCP supports reliable transmission

-        TCP is more secure than UDP. In TCP it is difficult to inject an arbitrary packet as each packet has a sequence number. In UDP it is simple. A malicious packet could easier pass an open UDP port in the firewall than an open TCP port. By that it is possible to have a TCP port open longer than a UDP port.

Here is an example of a Web Socket server for IoT devices (ARM mbed): https://developer.mbed.org/cookbook/Websockets-Server


I agree that MQTT is an alternative for certain types of applications.


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.

[Claes]: As far as I understand the main security issue with Web Sockets is that the Same Origin Policy is not applied for Web Sockets. Maybe I am naïve but the HW related security solutions you are discussing are they not applicable for use of CoAP, HTTP and MQTT as well? Could the specific security issue of Web Sockets, no Same Origin Policy, be addressable by CSP and CORS? Sorry for my limited knowledge here.

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