Clarify consequences of new DTLS Session

[boaks]

OMA-TS-LightweightM2M-V1_0-20161123-D, 8.2.4

When a new DTLS Session is started, or in NoSec mode when the LWM2M Client IP address changes, the Client MUST register again to the LWM2M Server.

Please describe the behaviour, when a DTLS session is established and the client doesn't send a registration. Should othe messages be ignored? Denied?

[sbernard31]

IMHO, this sentence should be removed from the spec.
We should not linked registration lifetime to DTLS session lifetime (see discussion here)

[dnav]

@boaks: which other messages ? If a client is not registered, the LWM2M messages it sends are ignored.

@sbernard31 : I agree the LWM2M registration should be independant of the DTLS session. However, the CoAP specification expects all operations (especially observation) to be contained in the same DTLS session.

[sbernard31]

@dnav even more, the spec say same connection and same epoch. (which means no session resumption, no renegotiation)
In theory, this means that CoAP observe just doesn't work in IP changing environment (like IPv4+NAT).
In practice, I'm not sure there is so much CoAP implementation we really do this check.
In Californium we add it recently and we will change it to be less strict than the spec or at least make it configurable.

[boaks]

@dnav: which other messages ? If a client is not registered, the LWM2M messages it sends are ignored.

Yes, your right, if a client is not registered, it is not that difficult.
But to be precise, “the LWM2M messages it sends are ignored.” is from my experience not true. Sending an “update” registration is usually answered by “4.04 Not found” instead of being ignored.

And unfortunately the reality (at least in my experience) offers some more surprise.
E.g. :

• Device establish DTLS session
• Devise registers (successful)
• Device establish a new DTLS session (caused by errors)
• Device violates the spec and doesn’t register instead it update the registration.

So, with your premise “client is not registered”, a new DTLS session must “deregister” the client (I hope, the used DTLS libraries will offer such callbacks). But that should then be specified in the TS (at least in my opinion).

And if too many find out, that their DTLS library doesn't support that callback, then the "check" for "update" should be defined also.

[hannestschofenig]

When you guys write that the "lifetime of the LWM2M registration should be independent of the DTLS session" what aspects are you specifically concerned about?

It might also be useful to clarify what you mean by DTLS session lifetime?

[sbernard31]

My concerns explained here:
"We should not couple this concept. For security purpose the TLS spec advice to define session lifetime to 24h. With this constraint, thats means that most of the time a registration will live only for 24h ... or Users will extend TLS session lifetime for a bad reason ...."

About DTLS session lifetime : https://tools.ietf.org/html/rfc5246#appendix-F.1.4

[hannestschofenig]

In LwM2M v1.1 we will have to re-evaluate the relationship between the transport and the communication security mechanism. In general, I agree that the lifetime of the LwM2M registration should be independent of the lifetime of various TLS/DTLS security credentials. As pointed out in the discussion I believe there is an item that needs to be brought to the attention to the CORE working group as well (since the CoAP specification seems to be incorrect).