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!

[Achim Kraus]

DTLS 1.2 is RFC6347, that is not generally including DTLS 1.2 CID (RFC 9146).

Currently I know three DTLS 1.2 CID implementations Eclipse/Californium (Java, server/client), Eclipse/tinydtls (C, feature branch, client only), and mbedTLS (release begin of this year, C, client/server). AFAIK, zephyr uses mbedTLS, but I'm not sure, which version and if CID is enabled. I setup a demo with tinydtls  zephyr-coaps-client (nRF9160, coap only, not lwm2m), that works pretty well.

Unfortunately it requires more then just using DTLS 1.2 CID, because some upper layer stuff uses the ip-address to identify the other peer as well and that must be adapted also.

[motters]

Cheers for the above. NRF v2.3.0 seems to use mbedtls v3.1.0, which was released in Dec 17, 2021. However the release notes do state:

The identifier of the CID TLS extension can be configured by defining MBEDTLS_TLS_EXT_CID at compile time.

But it doesn't seem like Zephyr has enabled it yet:

• https://github.com/zephyrproject-rtos/zephyr/issues/23424
• https://github.com/zephyrproject-rtos/zephyr/pull/36738

--

Reading what you said does this mean CID may improve the situation but doesn't guarantee to fix it? 

If this is true, then using OSCORE instead of DTLS would be the only real fix? 

[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.

[Achim Kraus]

> Seems to me that CIDs should be included in the DTLS spec!

For DTLS 1.3 that's the case. For DTLS 1.2 it's a extension.

DTLS is not only intended for device communication. For video streaming or stuff like that it works without CID.

> why nRF/Zephyr isn't using a version of mbedTLS which support CIDs

That was requested 2020, see Zephyr / DTLS connection ID . One point was the last minute change in the RFC. And then it tokes a little longer until the final RFC9146 made it into mbedtls. Today someone announced, that he wants to implement DTLS 1.2 CID in pion/dtls - go . So hope, it gets more and more common.

[motters]

Yes my personal project for DTLS uses a rust library which is Pion re-written in Rust. But i'm not sure it supports CIDs yet, i might take a look.

I'll give the git ticket a nudge. Maybe one of the nordic lwm2m engineers will take a look as it's really crippling to that protocol.

Thanks for all your help I've learnt a fair bit. 

[Achim Kraus]

You're welcome.

[Achim Kraus]

Just to mention:

DTLS 1.2 CID comes now with mfw 1.3.5 and NCS 2.4.0.

It's easy to enable with something similar to:

int cid = NRF_SO_SEC_DTLS_CID_SUPPORTED;
err = setsockopt(sock, SOL_TLS, TLS_DTLS_CID, &cid, sizeof(cid));

If your LwM2M provider also supports it, you may either ask, or test it with the new "Cellular Monitor". Enable it and check with WireShark for Connection ID records.