DTLS causes re-registration on LwM2M using mobile network

[motters]

Hello Everyone,

Summary

Chip:

nRF52840

OS:

nRF Connect / Zephyr

Problem:

Mobile network connections cause LwM2M (with DTLS) to perform re-registration if the update interval is longer than ~3 minutes. 

Details

We're using LwM2M (with DTLS) to monitor / control our nRF52840 uC (connected via an openthread network [OT]).

Working Condition

When the OT boarder router is connected via a fixed connection (within a building) we can set an LwM2M update interval of 5 minutes with no problems. Registration occurs once and updates occur after that point.

Error Condition:

When the OT boarder router is connected via a mobile connection (aka sim) we can't set an LwM2M update interval to more than ~2-3 minutes. If we do set a longer interval for LwM2M all update requests timeout.

This causes the device to perform re-registrations, which has the following effects:

• Increase data usage
• Dropping in and out of the LwM2M server as the connection interval is longer than the expected life time.

Additionally if i disable DTLS encryption then LwM2M may have longer update intervals. 

Assumption of the issue

I'm assuming the issue is that the mobile operators network is closing / deleting the NAT entry after 2-3 minutes of no use. Which means the LwM2M server cannot identify the client via the IP+port, forcing the device to re-register / negotiate the DTLS encryption.

From what i've read the following solutions are plausible:

• Replace DTLS encryption in for OSCORE.
  • Zephyr doesn't seem to have support for OSCORE yet, there is a module for it but its not in the LwM2M stack at-least.
• Using DTLS 1.2 on the device and server. This allows the connection to be identified by the connection id CID.
  • I'm not sure what version of DTLS Zephyr uses.
• Sending empty requests every 2 minutes to keep the port open.

Any help or advise on this issue would be great.

Thanks for your time!

[motters]

I will ask them.

Can i ask what you mean by the "dtls-principal"? I cant find reference for that term in the RFCs/online.

When using PSK encryption/mode for DTLS is the PSK-Identity sent in every request? In which case if the identity is unique to the device, that's another sure way of identifying devices?

[Achim Kraus]

> the "dtls-principal"

That's the representation of the identity of the other peer. "Principal" is the used term for that in java. e.g. the "PSK identity" would be a candidate for the "principal". Or the "subject" in x509. Assuming, that both are unique per client (I think to remember, that at least for the PSK identity this is required for LwM2M).

> is the PSK-Identity sent in every request? 

No. It's only send in the "ClientKeyExchange" during a full-handshake.

The DTLS records are defined in RFC 6347 - Section 4.3.1 .  An application data record contains the "DTLSCiphertext" with the encrypted application data (that is mostly a nonce + encrypted application data + mac) in the "fragment".

[motters]

So without DTLS CIDs there's no way of identifying the connection/device other than ip/port.

[Achim Kraus]

That's how I understand it.

With 8 years CoAP/DTLS 1.2 experience and being a co-author of that RFC 9146.

[motters]

I'll take your word for it then haha. Seems to me that CIDs should be included in the DTLS spec!

I suppose the question is why nRF/Zephyr isn't using a version of mbedTLS which support CIDs. A lot of devices using DTLS are going to experience the same issue.

Especially as the overhead of performing full-handshakes on cellular IoT devices is rather large.