Re: [secdir] EDHOC and Transports

[Hannes Tschofenig <[e-mail]>]

A minor follow-up: I mentioned that I am aware of a company using the energy scavenging devices and it turns out that this information is actually public and there is even a short video on YouTube. The company we worked with is called Alphatronics and here is the video: https://www.youtube.com/watch?v=JHpJV_CPYb4

As you can hear in the video we have been using our Mbed OS together with our device management solution (LwM2M with DTLS and CoAP) for these types of devices.

Ciao
Hannes

-----Original Message-----
From: secdir <[e-mail]> On Behalf Of Hannes Tschofenig
Sent: Freitag, 25. Januar 2019 13:52
To: Jim Schaad <[e-mail]>; [e-mail]
Subject: Re: [secdir] EDHOC and Transports

Hi Jim,

what we are doing here is making an optimization. For some (unknown reason) we have focused our attention to the over-the-wire transmission overhead (not code size, RAM utilization, or developer usability*). We are doing this optimization mostly based on information about what other people tell us rather than based on our experience. The problem is that we have too few people with hands-on knowledge and/or deployment experience and if they have that experience they may not like to talk about it. So, we are stepping around in the dark and mostly perceived problems.

Having said that I would like to provide a few remarks to your list below:

1.  Low-power devices that either are battery based or scavenge power, these devices pay a power penalty for every byte of data sent and thus have a desire for the smallest messages possible.

[Hannes] Low power is a very complex topic since it is a system issue and boiling it down to the transmission overhead of every byte is an oversimplification. You are making certain assumptions of how power consumption of radio technologies work, which will be hard to verify. I have been working on power measurements recently (but only focused on power measurements of crypto, see https://community.arm.com/arm-research/b/articles/posts/testing-crypto-performance-and-power-consumption). I doubt that many people on this list nor in the IETF have a lot of experience in this field to use this as a basic for an optimization.

My co-workers, who are active in this space, tell me that there is nothing like a "per byte" linear relationship (for small quantities of data) in terms of energy cost. Obviously if you trigger "an additional transmission", which requires you to ramp up a PLL, turn on radio amplifiers, send lengthy preambles etc then the incremental cost of sending 64 bytes in that packet vs 16 bytes might be immeasurable small.  The critical thing appears to be how long the RF amplifiers are powered on. Hence, you will often see publications that tell you that waiting for incoming packets is actually the most expensive task (in terms of power consumption).

When it comes to energy scavenging devices then it becomes even more challenging since this is a more rarely used case. I know about one company doing this and I have spoken with a researchers at last year's Arm research summit who show-cased one device. The device shown by the researcher was a prototype and didn't use any Internet protocol nor a security mechanism. I wouldn't call myself knowledgeable enough to optimize a system based on this experience but maybe you have more expertise in this field. I am happy to learn more.

2. CoAP over SMS:  SMS has a 140 byte packet size.  There are two approaches for dealing with packets of larger than 140 bytes:  1) There is a method of appending multiple packets together to form a single larger packet.  2) You can use CoAP blockwise transfer.  Using CoAP blockwise would result in 128 byte packets for the underlying transfer assuming that only 12 bytes are needed for the CoAP header itself.

[Hannes] It turns out that CoAP over SMS is rarely used for delivering data of IP-based devices since SMS is a pretty expensive transport. From my work in the OMA I know that people use SMS to trigger the wake-up of devices and then switch to regular data transmission over IP. IMHO optimizing for use cases that barely anyone  uses appears to be a waste of time.

3. 6LoPan over IEEE 802.15.4:  This has a packet size of 127 bytes.  The maximum frame overhead size is 25 bytes allowing for 102 bytes of message
space.   If one assumes 20 bytes of overhead for CoAP then this means a
protocol packet size of 82 bytes.  If one needs to break the message across multiple packets then the maximum data size is going to be 64 bytes using CoAP blockwise options.

[Hannes] For some reason there seems to be the worry that a small MTU size at the link layer will cause a lot of problems. There are some radios that have this small MTU size, IEEE 802.15.4 and Bluetooth Low Energy belong to them. It turns out, however, that higher layers then offer fragmentation and reassembly support so that higher layers just don't get to see any of this. In IEEE 802.15.4 this fragmentation & reassembly support is offered by 6lowpan and in case of Bluetooth Low Energy the link layer actually consists of various sub-protocols. One of them offers fragmentation & reassembly. As such, the problem you describe is actually not a problem. There is no reason why you always have to put a single application layer payload into a single link layer frame.

We have been using LwM2M (which uses DTLS and CoAP) over IEEE 802.15.4 networks successfully for big commercial deployments. We have not run into problems with the smaller MTU size at the lower layers. The handshake itself is just a very small part of the overall size of data that gets transmitted during the lifetime of the device since the handshake obviously happens extremely rarely. There are much better ways to optimize traffic and you obviously have to look at all the data you are transmitting for the device.

Ciao
Hannes

*: In my experience the ability for developers to easily use any of the performance optimization techniques is the biggest barrier for gaining performance. Of course, this does not fit nicely in any of the standardization efforts in the IETF so the focus has to be somewhere else.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
secdir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.