Subject: [Ace] Energy-efficient review of draft-seitz-ace-authz.txt :)

From: Mališa Vučinić <[email-masked]>
Date: Mon, 14 Dec 2015 19:31:11 +0100

Dear authors, ACE list, 

Here are some comments on the latest version of draft-seitz-ace-authz.txt. My domain expertise is in what the draft calls ‘severely energy-constrained scenario’ and I have worked with Wireless Sensor and Actuator Networks with solar-powered 6lowpan devices that are autonomous on <150 lux (illuminance typically found under an office desk). In that context, I implemented over CoAP a variant of the token-less authorization scheme described in Section 6.5 of the draft and worked on security (bootstrapping, hardware-accelerated crypto, link layer, end-to-end) and network-wise energy efficiency. My definition of an IoT device is a duty cycled Class 1 or Class 2 sensor or actuator with average current consumption well bellow 100 microamps, and so with lifetime comparable to the battery life (5-10 years).

On the presentation side, I think that the draft does a good job of introducing OAuth 2.0 and PoP tokens to non experts and gives interesting examples how it can be incorporated with the deployment scenarios. I also like that object security is considered a foundational building block, for both communication and data+token security. Still, there seem to be many variables on the table (CoAP/HTTP, DTLS/TLS/OSCOAP/OSCON, JSON/CBOR) so I suppose that more specific profiles with normative language and clear guidance for the implementers will be defined down the road. 

My main remark relates to the implicit assumption of bidirectional communication with the constrained RS (While ‘offline’ scenarios are clearly distinguished in the draft, this relates to the reachability of AS.) Because sensors sleep most of the time to preserve energy, they can often be reachable for traditional requests only at specific instants, for example once they have woken up and self-initiated an exchange (polling for data after a several-minute-sleep in beacon-enabled 802.15.4, receive window following uplink transmission with LoRa or any always-on router, 802.15.4E TSCH or wHart schedule optimized for upwards communication). In practice, this means that the communication directed downwards to the RS can be quite unreliable, prone to high latencies and energy-wise expensive for the RS and the rest of the multihop network due to the need to 1) listen on the idle radio channel to guarantee downwards reachability, even in the absence of traffic; 2) forward additional traffic. I think it would be important to make this clear in the draft and stress that although bidirectional communication is indeed feasible, there are often system-wide consequences on energy consumption and network performance such that application developers should rely on it only for the necessary application scenarios (e.g. actuation).

Another remark relates to the transmission of certificates and raw public keys in the constrained part. With limited bandwidth and multihop networks, this opens up DoS concerns because routers can also be energy-constrained. I would find useful if the document gave some recommendations on the usage of fingerprints as discussed in Section 5.1 and on how they can be used with OSCOAP or DTLS to optimize the exchanges and so lower the transmission burden on the network. 

It is very useful for energy-constrained RS that the AS can take over the cipher negotiation task with the different clients. I think this deserves a bit more discussion in the text because it adds implementation complexity (where it should be) at AS, while removing the need of RS to do additional exchanges in case OSCOAP/OSCON are used. This particularly makes sense because RS will in many cases be flashed with a firmware image containing a single cipher, due to the memory constraints.

It could be interesting to extend Appendix A to stress that the energy for symmetric encryption of one byte of data is typically orders of magnitude lower than for transmitting one byte over a low-power radio. Hardware acceleration is widely available in which case execution times of symmetric-key primitives are literally negligible (microseconds) and the *dominant* latency component comes from the radio communications. Public-key crypto is very feasible with commercial IoT hardware (milliseconds to seconds) and particularly when it is done at the application layer using object security, many optimizations are possible so we should not scare the developers away from using it :-).

Regards,
Mališa

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 16 Dec 2015 10:02:59 +0100

On 2015-12-14 19:31, Mališa Vučinić wrote:
> Dear authors, ACE list,
>
> Here are some comments on the latest version of
> draft-seitz-ace-authz.txt.
~snip~
> Still, there seem to be many variables on the table
> (CoAP/HTTP, DTLS/TLS/OSCOAP/OSCON, JSON/CBOR) so I suppose that more
> specific profiles with normative language and clear guidance for the
> implementers will be defined down the road.
>
That was our plan indeed.

> My main remark relates to the implicit assumption of bidirectional
> communication with the constrained RS (While ‘offline’ scenarios are
> clearly distinguished in the draft, this relates to the reachability
> of AS.) Because sensors sleep most of the time to preserve energy,
> they can often be reachable for traditional requests only at specific
> instants, for example once they have woken up and self-initiated an
> exchange (polling for data after a several-minute-sleep in
> beacon-enabled 802.15.4, receive window following uplink transmission
> with LoRa or any always-on router, 802.15.4E TSCH or wHart schedule
> optimized for upwards communication). In practice, this means that
> the communication directed downwards to the RS can be quite
> unreliable, prone to high latencies and energy-wise expensive for the
> RS and the rest of the multihop network due to the need to 1) listen
> on the idle radio channel to guarantee downwards reachability, even
> in the absence of traffic; 2) forward additional traffic. I think it
> would be important to make this clear in the draft and stress that
> although bidirectional communication is indeed feasible, there are
> often system-wide consequences on energy consumption and network
> performance such that application developers should rely on it only
> for the necessary application scenarios (e.g. actuation).
>

This is a very interesting remark, and I would like to ask for more 
details here to guide our work.

Since in the setup you describe it is desirable that the RS initiates 
the exchange, I assume this would be implemented as a sort of 
publish-subscribe solutions or as something similar to CoAP observe.

I think our proposal in section 6.5 covers the publish-subscribe case 
(which is not surprising since it is based on your work).

For the observe case, how would the initial observe typically reach the 
RS? Would the client just have to try until it succeeds or are there any 
possibilities to look up the sleep schedule of the RS in some external 
resource (like an RD for example)?

> Another remark relates to the transmission of certificates and raw
> public keys in the constrained part. With limited bandwidth and
> multihop networks, this opens up DoS concerns because routers can
> also be energy-constrained. I would find useful if the document gave
> some recommendations on the usage of fingerprints as discussed in
> Section 5.1 and on how they can be used with OSCOAP or DTLS to
> optimize the exchanges and so lower the transmission burden on the
> network.

We are planning to specify these parts in more details and will keep 
this comment in mind.

>
> It is very useful for energy-constrained RS that the AS can take over
> the cipher negotiation task with the different clients. I think this
> deserves a bit more discussion in the text because it adds
> implementation complexity (where it should be) at AS, while removing
> the need of RS to do additional exchanges in case OSCOAP/OSCON are
> used. This particularly makes sense because RS will in many cases be
> flashed with a firmware image containing a single cipher, due to the
> memory constraints.
>

I think a discussion of the design decisions could fit well in Appendix 
A. We also plan to provide more specific normative text on how to 
perform this negotiation in future versions of the draft.

> It could be interesting to extend Appendix A to stress that the
> energy for symmetric encryption of one byte of data is typically
> orders of magnitude lower than for transmitting one byte over a
> low-power radio.

I think it would be helpful to add your remarks to Appendix A, do you 
happen to have some paper or technical report we could reference as an 
example?

> Hardware acceleration is widely available in which
> case execution times of symmetric-key primitives are literally
> negligible (microseconds) and the *dominant* latency component comes
> from the radio communications. Public-key crypto is very feasible
> with commercial IoT hardware (milliseconds to seconds) and
> particularly when it is done at the application layer using object
> security, many optimizations are possible so we should not scare the
> developers away from using it :-).
>

We are certainly not trying to scare away people form public-key crypto, 
where it is feasible and the draft should absolutely specify this 
option. However I think it is important that the draft should also 
provide a symmetric key only option, in case some use case requires this 
(e.g. due to lack of hardware accelerators in the specific hardware).

Regards,

Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 18 Dec 2015 00:15:39 +0100

> On 16 Dec 2015, at 10:02, Ludwig Seitz <[email-masked]> wrote:
> 
> For the observe case, how would the initial observe typically reach the RS?
> Would the client just have to try until it succeeds or are there any possibilities to look up the sleep schedule of the RS in some external resource (like an RD for example)?

RS’ level of duty cycling can be dynamic, it depends on local constraints or simply the deployment phase (registration/reporting). Obviously, that will affect how reachable to requests RS is at a given moment. I am not aware of sleep schedule sort of discovery with RD, did you have some specific scheme in mind?

> I think it would be helpful to add your remarks to Appendix A, do you happen to have some paper or technical report we could reference as an example?

Here is a recent example with boards that are commercially available since 2012: http://www.simonduquennoy.net/papers/shafagh15talos.pdf <http://www.simonduquennoy.net/papers/shafagh15talos.pdf>. Relevant are Figures 7 and 8a (byte-time metric), Tables 5 and 6, taking into account that a transmission of 127 bytes burns ~205uJ with that board.

Mališa