LWM2M + DTLS + NBIoT proper implementation

[fastfox]

Hi,

I am trying to implement energy efficient(batt powered) application for nrf9160, using UDP/DTLS/LWM2M as comm stack. Got "hello world" working, but now I am really confused about many details. Hope you can help me.

Question 1: Operator NAT/firewall rules and NRF9160 DTLS implementation

It looks like operator networks loose UDP port rules about after 1 minute of silence. This essentially means that UDP port number changes between consecutive packets sent from device to server if communications happens for example in every 10 minutes. This again means that DTLS connection would need to be resumed for it to work. It looks like resumption does not work in NRF or is not implemented at all? Effect is dramatic, you have to either ping server in <60s intervals or go through connection failure+re-register cycle every time you send anything.

Am I missing something here or how do people in general make things work? This ruins the whole idea of power save modes and LWM2M benefits. Is the only workaround to use MBED TLS stack instead?

Question 2: It looks like DTLS connection(to LWM2M bootstrap server) always ends to TLS ALERT sent by nrf91. Any idea why? Is this a feature? Other clients do not do that.

Question 3: Zephyr does not support QUEUE mode. If I understood the LWM2M spec correctly, QUEUE mode is exactly what low power NB-IoT application needs, but zephyr LWM2M stack does not support it. Do you have any idea how Nordic users tend to solve this? Implement queues as server side application on top of LWM2M? Use different LWM2M client?

Probably not the easiest questions and not all directly in Nordics domain, but I hope that you have some ideas how to make actual production quality app using NRF91. Thanks.

[Didrik Rokhaug]

Hi.

 

Question 1: Operator NAT/firewall rules and NRF9160 DTLS implementation

 In the DTLS header, there will be a session token indicating which DTLS session the packet belongs to.

It is up to the server to decide if the session has timed out or not. So as long as all communication is initiated by the device, the NAT/firewall rules should not be a huge problem.

 

It looks like resumption does not work in NRF or is not implemented at all?

 It is, but at the moment, there is a bug that can casue the modem to crash when (D)TLS session caching is enabled. The bug will be fixed in the next modem release.

 

Question 2: It looks like DTLS connection(to LWM2M bootstrap server) always ends to TLS ALERT sent by nrf91. Any idea why? Is this a feature? Other clients do not do that.

 While I can not say for certain without more information (a modem trace is the most helpfull), I have two hyptohesis:

1. The server's certificates are too large. The nRF9160 only supports TLS frames up to 2048 bytes.

2. The nRF9160 does not support SNI at the moment. This will be added in the next modem release.

 

Question 3: Zephyr does not support QUEUE mode. If I understood the LWM2M spec correctly, QUEUE mode is exactly what low power NB-IoT application needs, but zephyr LWM2M stack does not support it. Do you have any idea how Nordic users tend to solve this? Implement queues as server side application on top of LWM2M? Use different LWM2M client?

 Please take a look at https://github.com/NordicPlayground/fw-nrfconnect-nrf/pull/2252

Best regards,

Didrik

[fastfox]

Thanks for clarifications. Just to make sure that I understood this correctly

Didrik Rokhaug said:

            It is, but at the moment, there is a bug that can casue the modem to crash when (D)TLS session caching is enabled. The bug will be fixed in the next modem release.

As I am not seeing session resumption, it means that I have to explicitly enable the session caching somehow, right? What is the API? I found this post where it says that you have to use nrf_setsock_opt https://devzone.nordicsemi.com/f/nordic-q-a/55335/dtls-session-resumption-on-nrf9160-modem-fw-v1-1-0

And the ?random? crashes caused by activating the cache will be fixed in 1.3.0, which will be release at unknown date?

And to make this work right now, the only option is to not use offloaded NRF sockets at all, but something else instead, right?

[Didrik Rokhaug]

fastfox said:

And the ?random? crashes caused by activating the cache will be fixed in 1.3.0, which will be release at unknown date?

 I am sorry, but my memory failed me a little. The bug was fixed in mwf v1.2.0, so the fix is already out.

If you are using NCS v1.2.0, TLS session caching is enabled by default.

 

fastfox said:

What is the API?

 Here is you would disable session caching:

#include <nrf_socket.h>

nrf_sec_session_cache_t session_cache = 0;

nrf_setsockopt(socket, NRF_SOL_SECURE,

        NRF_SO_SEC_SESSION_CACHE, &session_cache,

        sizeof(session_cache));

[fastfox]

Hi,

This is just not sinking into my brains now 

I am using 1.2.0 modem firmware and tag v1.2.0 from nrf-connect SDK

If I connect to my server using, e.g. leshan client, session resumption works and I see that the client is sending client hello when making registration update

If I connect to my server using NRF91, I can only see application data(no client hello and thus no session resumption) when it is making registration update

And I can't find any code that would set any session caches in nrf-connect SDK(or any of the sub repositories).

So you say that session cache is enabled by default, but it does not look like that from what I see.

Edit: While staring at the pcaps, I also realized that modem is sending session ID in the very first client hello to the server. I really mean the first message to the server after device power-cycle. That is strange...

Edit2: Ok that was probably TCP+TLS connection to the same domain name that caused the session ID to exist. Unfortunately, removing another connection does not make it work any better.

[Didrik Rokhaug]

If you take a modem trace, we can see what is happening from the device side as well.

However, if the modem provides a session ID in the client hello message, that is the session cache in action. If the server still recognizes the ID, then a full TSL negotiation is not needed.

 

fastfox said:

If I connect to my server using NRF91, I can only see application data(no client hello and thus no session resumption) when it is making registration update

 Are you sure that you have configured the client and the server to use TLS?

Where the data encrypted?

Or, could it be that you simply missed the client hello?

[fastfox]

Hi, I already tried to take modem traces, but failed to figure out exactly how to do that in my custom PCB. I'll give it another try or rewrite the SW to evaluation board.

Didrik Rokhaug said:

Are you sure that you have configured the client and the server to use TLS?

Where the data encrypted?

Or, could it be that you simply missed the client hello?

Yes, I  am sure. But it is DTSL to be exact.

Yes, data is encrypted

Possible of course, but very unlikely since I have tested this tens of times. I'll attach two pcaps here. From there(90s) you can see that packet #37 at time 102 is application data. This is the registration update. With a working client(leshan_client) the same registration update starts with client hello + resumptionip_port_changes_90s.pcapngip_port_changes_leshan_client.pcapng

[Didrik Rokhaug]

Do you know what the DTLS timeout on the server is?

The modem assumes that the connection is valid, and will not initiate a new DTLS session unless the server rejects the old one.

So what might have happened is that the modem tries to use the "old" session, which is still valid. That means that a new DTLS handshake is unnecessary, hence no client hello.

[fastfox]

That is a good question, I need to investigate that.

I thought that it is up to the client to decide that, but it might very well be that it is somehow negotiated in initial handshake. Is there any default values for this timeout in modem or can it be adjusted somehow?

I am not even sure what is the term to look for here. I think RFCs are talking about "idle timeout" and "session timeout" both meaning that session is no longer valid. But what we need is "do resumption timeout", which is network depended and always smaller than "idle timeout"

[jp]

Hi Didrik, how can the server reject the DTLS session when the communication is coming from a different IP address, and it doesn't recognise the packet?

Is there some way for the nRF9160 to invalidate the DTLS session?

Thanks,
John