Subject: [lp-wan] Problem areas?

From: Bill Gage <[email-masked]>
Date: Tue, 17 Nov 2015 14:34:25 +0000

So far, most of the discussions seems to be related to transporting IP packets (with some number of upper layer protocol PDUs) across LP-WAN links. But are there other areas that need to be addressed?

Authentication, for example. Arguably, authentication is more important that privacy (encryption). If a device is only sending a couple of bits of payload (e.g. temperature) or even a single bit (on/off) then privacy may not be an issue. But ensuring that the report comes from a legitimate device will always be an issue to prevent pollution of databases. Similarly, on the downlink, a command to a device needs to be authenticated to prevent malicious operation of devices (e.g. turning a valve on or off) or to prevent malicious mis-configuration.

The current solutions are based on compute intensive operations. A CRC for error detection requires order(1) operations per byte but an HMAC for authentication requires order(1000) operations per byte. In addition, the handshake for deriving authentication keys requires multiple rounds of message exchange and may involve compute intensive computations for key derivation. None of this is good for power conservation in a low cost device.

Cellular solutions will probably be SIM based. What are the alternative non-SIM solutions?

---

From: Mischa Dohler <[email-masked]>
Date: Tue, 17 Nov 2015 14:41:55 +0000

Good points, Bill.

Anything critical can likely only be authenticated if you go to L0 
(hardware, quantum signatures, you name it). If time is available, then 
you can play with that dimension and do authentication eg over a bulk of 
short packets.

Mischa.

On 17/11/2015 14:34, Bill Gage wrote:
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 17 Nov 2015 16:01:26 +0100

Dear Bill,

Indeed, security in general is a major question that has to be addressed 
for LP-WANs. AAA, multicast key management, etc.

Le 17/11/2015 15:34, Bill Gage a écrit :
> Authentication, for example. Arguably, authentication is more important that privacy (encryption).
Encryption can be used to provide you with confidentiality of the 
communications, and authentication is a prerequisite for this.

Using CoAP as signaling protocol for LP-WANs, we can leverage the 
existing work in EAP-over-CoAP ( draft-marin-ace-wg-coap-eap-02 ). In 
this case, you can trivially run EAP-AKA, (or if you wish EAP-SIM), 
which would enable you to use SIM-card based authentication in LP-WANs.

Best,
Alexander

> If a device is only sending a couple of bits of payload (e.g. temperature) or even a single bit (on/off) then privacy may not be an issue. But ensuring that the report comes from a legitimate device will always be an issue to prevent pollution of databases. Similarly, on the downlink, a command to a device needs to be authenticated to prevent malicious operation of devices (e.g. turning a valve on or off) or to prevent malicious mis-configuration.
>

---

From: Bill Gage <[email-masked]>
Date: Tue, 17 Nov 2015 15:14:20 +0000

Hello Alexander -

You are assuming that there are no issues with:

(a) transporting an IP/UDP/DTLS/CoAP protocol stack over the LPWAN radio link, and
(b) performing the computations required to run DTLS.

I am assuming that there are issues with both of these approaches:
(A) because of the potentially small payload in each radio frame, and
(B) because of the nature of the device (low cost, little or no hardware acceleration, battery power limitations).

If issues (A) and (B) don't exist, then existing solutions (a) and (b) can be applied and we are done here. However, I suggest that issues (A) and (B) may be real world issues that preclude use of (a) and (b).

If that is the case, what is the alternative? And, in particular, if privacy is not an issue, what is the alternative for authentication?

Cheers ...

> -----Original Message-----
> From: Alexander Pelov [mailto:[email-masked]]
> Sent: Tuesday, November 17, 2015 10:01 AM
> To: [email-masked]
> Subject: Re: [lp-wan] Problem areas?
> 
> Dear Bill,
> 
> > So far, most of the discussions seems to be related to transporting IP
> packets (with some number of upper layer protocol PDUs) across LP-WAN
> links. But are there other areas that need to be addressed?
> >
> > If a device is only sending a couple of bits of payload (e.g.
> temperature) or even a single bit (on/off) then privacy may not be an
> issue. But ensuring that the report comes from a legitimate device will
> always be an issue to prevent pollution of databases. Similarly, on the
> downlink, a command to a device needs to be authenticated to prevent
> malicious operation of devices (e.g. turning a valve on or off) or to
> prevent malicious mis-configuration.
> >
> > The current solutions are based on compute intensive operations. A CRC
> for error detection requires order(1) operations per byte but an HMAC for
> authentication requires order(1000) operations per byte. In addition, the
> handshake for deriving authentication keys requires multiple rounds of
> message exchange and may involve compute intensive computations for key
> derivation. None of this is good for power conservation in a low cost
> device.
> >

---

From: Laurent Toutain <[email-masked]>
Date: Tue, 17 Nov 2015 16:15:48 +0100

Hi Bill,

On Tue, Nov 17, 2015 at 4:01 PM, Alexander Pelov <[email-masked]> wrote:

> Using CoAP as signaling protocol for LP-WANs, we can leverage the existing
> work in EAP-over-CoAP ( draft-marin-ace-wg-coap-eap-02 ). In this case, you
> can trivially run EAP-AKA, (or if you wish EAP-SIM), which would enable you
> to use SIM-card based authentication in LP-WANs.
>

Even if protocols remain the same, we will have to define BCP. For instance
default timers will not be adapted to LPWA transmission delays.

Laurent

>
> Best,
> Alexander
>
>
> If a device is only sending a couple of bits of payload (e.g. temperature)
>> or even a single bit (on/off) then privacy may not be an issue. But
>> ensuring that the report comes from a legitimate device will always be an
>> issue to prevent pollution of databases. Similarly, on the downlink, a
>> command to a device needs to be authenticated to prevent malicious
>> operation of devices (e.g. turning a valve on or off) or to prevent
>> malicious mis-configuration.
>>

-- 
Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: +33 2 30 96 6312    | Tel: + 33 2 99 12 7026                 | Visit
:
| Mob: +33 6 800 75 900    |                                        |
| Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |
http://class.touta.in
| [email-masked]         | [email-masked]    |
+--------------------------+----------------------------------------+

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 17 Nov 2015 17:16:50 +0100

Hi Bill:

Security is an aspect I am interested in. I believe it should be considered due to its critic importance, as you mention. 

More comments below.

> El 17 nov 2015, a las 15:34, Bill Gage <[email-masked]> escribió:
> 

Agree.
> The current solutions are based on compute intensive operations. A CRC for error detection requires order(1) operations per byte but an HMAC for authentication requires order(1000) operations per b…

The internal operations are a general issue regardless whether we are talking about LP-WAN or not. As I see it, in the specific case of LP-WAN, the problems may come with the size of messages and the number of roundtrips.

> Cellular solutions will probably be SIM based. What are the alternative non-SIM solutions?

EAP may provide you a general framework to select a authentication mechanism : EAP-SIM, EAP-AKA, EAP-GPSK, EAP-TLS…

Best Regards.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 17 Nov 2015 17:22:28 +0100

Hi Alexander:

> El 17 nov 2015, a las 16:01, Alexander Pelov <[email-masked]> escribió:
> 
> Dear Bill,
> 
> Indeed, security in general is a major question that has to be addressed for LP-WANs. AAA, multicast key management, etc.
> 
> Encryption can be used to provide you with confidentiality of the communications, and authentication is a prerequisite for this.
> 
> Using CoAP as signaling protocol for LP-WANs, we can leverage the existing work in EAP-over-CoAP ( draft-marin-ace-wg-coap-eap-02 ). In this case, you can trivially run EAP-AKA, (or if you wish EAP-SIM), which would enable you to use SIM-card based authentication in LP-WANs.

+1. In fact, that was the main intention of our proposal (EAP over CoAP). In fact, we have running code in mbed platform and Contiki OS.

Best Regards.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 17 Nov 2015 17:24:20 +0100

Hi Laurent:

> El 17 nov 2015, a las 16:15, Laurent Toutain <[email-masked]> escribió:
> 
> Hi Bill,
> 
> Even if protocols remain the same, we will have to define BCP. For instance default timers will not be adapted to LPWA transmission delays.

True. For example, it would be good to see how CoAP default retransmission mechanism behaves in these types of networks.

Best Regards.

> | Tel: +33 2 30 96 6312    | Tel: + 33 2 99 12 7026                 | Visit :
> | Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |  http://class.touta.in

---

From: Bill Gage <[email-masked]>
Date: Tue, 17 Nov 2015 16:39:33 +0000

And EAP also suffers from problems (A) and (B) ...

> From: Bill Gage [mailto:[email-masked]]
> Sent: Tuesday, November 17, 2015 10:14 AM
> 
> Hello Alexander -
> 
> (B) because of the nature of the device (low cost, little or no hardware
> acceleration, battery power limitations).
> 
> If issues (A) and (B) don't exist, then existing solutions (a) and (b) can
> be applied and we are done here. However, I suggest that issues (A) and
> (B) may be real world issues that preclude use of (a) and (b).
> 
> If that is the case, what is the alternative? And, in particular, if
> privacy is not an issue, what is the alternative for authentication?
> 
> Cheers ...
> 
> > > Authentication, for example. Arguably, authentication is more
> important
> > that privacy (encryption).
> > > Cellular solutions will probably be SIM based. What are the
> alternative
> > non-SIM solutions?
> > >
>

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 17 Nov 2015 17:46:46 +0100

Hi Bill:

EAP adds 5 bytes to achieve flexibility. The key factor is not EAP, it is the key management protocol you transport there. We have already experimented and implemented in EAP st machine on those types of limited devices. Having said that, are we considering only Class 0 devices or do we want to cover other types?  (https://tools.ietf.org/html/rfc7228)

Best Regards.

> El 17 nov 2015, a las 17:39, Bill Gage <[email-masked]> escribió:
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 17 Nov 2015 17:52:42 +0100

Rafa Marin Lopez wrote:
> Having said that, are we considering only Class 0 devices or do we want to cover other types?  (https://tools.ietf.org/html/rfc7228)

Class-0 devices are unlikely to be able to play the role of a fully
secure Internet host, except in unsual cases.

If we are interested in minimizing the footprint, we should be focusing
on class-1 devices.   Having ~ 100 KiB of code space doesn't mean all of
that is available for EAP.  More generally, with a class-1 device, there
is a certain reluctance to take on another protocol just because it is
there.

Grüße, Carsten

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 17 Nov 2015 18:01:34 +0100

Hi Carsten:
> El 17 nov 2015, a las 17:52, Carsten Bormann <[email-masked]> escribió:
> 
> Rafa Marin Lopez wrote:

Agree.

> that is available for EAP.

Also agree. Unless the cost is affordable. As I mentioned, the problem I see is not in EAP itself but the authentication and key management protocol you use inside. In fact that is the problem no matter you use EAP or not.

On the other hand, EAP integrates very well with AAA infrastructures. In the backend (no constrained), I see them as a possibility of managing a big set of devices in this type of networks.

Best Regards.

>  More generally, with a class-1 device, there

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 17 Nov 2015 18:11:42 +0100

Hi Rafa, Laurent,

<SNIP>

>> Even if protocols remain the same, we will have to define BCP. For
>> instance default timers will not be adapted to LPWA transmission delays.
>
> True. For example, it would be good to see how CoAP default retransmission
> mechanism behaves in these types of networks.

For instance, at a data rate of 10 bit/s, default CoAP timeout (i.e. 2 s)
is well below a suitable value.

Assuming the default CoAP timeout, at a data rate of 1 kbit/s, a 250-byte
physical layer data unit will lead to a spurious CoAP timeout with a high
probability. Under the same conditions, a 375-byte data unit will always
lead to a spurious CoAP timeout.

Of course, an adaptive RTO mechanism such as CoCoA
(http://tools.ietf.org/html/draft-bormann-core-cocoa-03) can be used, but
the default RTO value should anyway be well chosen. Given the diversity of
LP-WAN technologies we are considering, it may not be possible to
recommend a single adequate default CoAP RTO value for all these
technologies.

(Even sometimes the variety of PHY options within a single technology is
huge, see e.g. LoRa.)

Best regards,

Carles

---

From: Bill Gage <[email-masked]>
Date: Tue, 17 Nov 2015 17:13:39 +0000

With regards to problem (A), EAP itself adds "a few" bytes over overhead (depending on the method) but there was a suggestion that EAP should be run on top of an IP protocol stack rather than directly on the link layer. And, of course, the parameters for the chosen EAP method will add additional overhead.

With regards to problem (B), EAP still requires derivation of a session key which may be a compute-intensive operation. But even here, one might choose to ignore this overhead if key refresh occurs only infrequently.

Since *device* authentication may happen infrequently, let's assume that the use of EAP is okay and put that one aside for now.
======

My real question is the overhead for authentication of *each message*. As I noted originally, HMAC adds a significant number of bytes to each message and requires significant computational overhead.

Regardless of the class of device, larger messages are an issue for an LPWAN with small radio frames and computational overhead is an issue for a device running on batteries with an expected lifetime of many years.

Cheers ...

> From: Rafa Marin Lopez [mailto:[email-masked]]
> Sent: Tuesday, November 17, 2015 11:47 AM
> To: Bill Gage
> Cc: Rafa Marin Lopez; [email-masked]
> EAP adds 5 bytes to achieve flexibility. The key factor is not EAP, it is
> the key management protocol you transport there. We have already
> experimented and implemented in EAP st machine on those types of limited
> devices. Having said that, are we considering only Class 0 devices or do
> we want to cover other types?  (https://tools.ietf.org/html/rfc7228)
> 
> Best Regards.
> 
> >> (a) transporting an IP/UDP/DTLS/CoAP protocol stack over the LPWAN
> radio
> >> link, and

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 18 Nov 2015 08:55:01 +0100

Hi Carles,

I agree, we also have to take into account AAA timers that may be unaware
that the node is on LPWA.

Laurent

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 18 Nov 2015 12:19:39 +0100

Hi Carles:

> El 17 nov 2015, a las 18:11, Carles Gomez Montenegro <[email-masked]> escribió:
> 
> Hi Rafa, Laurent,
> 
> <SNIP>
> 

Yes, that is what I suspected.

> recommend a single adequate default CoAP RTO value for all these

Good analysis. I agree.

Thanks!

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 18 Nov 2015 12:34:52 +0100

Hi Laurent
> El 18 nov 2015, a las 8:55, Laurent Toutain <[email-masked]> escribió:
> 
> Hi Carles,
> 
> I agree, we also have to take into account AAA timers that may be unaware that the node is on LPWA. 

I think the AAA client (if AAA infrastructures are used) would be place in the authenticator (e.g. base station). As such, the AAA client should know that a node is connected and when authentication happens the Called-Station-Id is set to the base station's. Moreover, the identity of the node should be recognized by the AAA server as a mote. But I agree with you that those AAA timers should be adapted to consider a likely slow authentication.

Best Regards.

> 
> Laurent
> 
> On Tue, Nov 17, 2015 at 6:11 PM, Carles Gomez Montenegro <[email-masked]> wrote:
> Hi Rafa, Laurent,
> 
> <SNIP>
>