[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Californium/Scandium; Server side sending "ClientHello"
|
All,
I agree with Simon and you, Achim, already know my position on this. From my point of view, the application (in this case leshan server) should NOT explicitly close the connection to the LWM2M client when the LWM2M client de-registers (using the corresponding LWM2M resource).
We should therefore make sure that leshan does not do so and rely on Scandium's internal housekeeping for DTLS session management.
However, I agree with Achim that it would still be helpful to be more concise in Scandium's ordering of outbound records. I think we should make the ordering of outbound records fully deterministic.
Regards,
Kai
________________________________________
Von: cf-dev-bounces@xxxxxxxxxxx [cf-dev-bounces@xxxxxxxxxxx]" im Auftrag von "Simon Bernard [contact@xxxxxxxxxxxxxxx]
Gesendet: Donnerstag, 1. Oktober 2015 18:39
An: Californium (Cf) developer discussions
Betreff: Re: [cf-dev] Californium/Scandium; Server side sending "ClientHello"
Hi,
Since commit 7a1473683d544c41b7ab2374b21e9748c8d7d49f<https://github.com/eclipse/leshan/commit/7a1473683d544c41b7ab2374b21e9748c8d7d49f>, Leshan should not send CLOSE_NOTIFY on deregistration.
About the "HelloRequest", as I understand the spec this should be used by the server to ask for a new renegotiation(also called "rehandshake") in an existing connection.
(see https://tools.ietf.org/html/rfc5246#section-7.4.1.1 and https://tools.ietf.org/html/rfc5246#section-7.4.1.2)
In your case, the CLOSE_NOTIFY close the DTLS connection, then the Leshan server want to respond to the Leshan client, but as there is no connection, the Leshan Server will initiate a new handshake for a new connection. In this case the Leshan Server will be the Client at DTLS meaning and so send a ClientHello. (This is not a renegotiation)
Simon
Le 25/09/2015 17:12, Kraus Achim (INST/ESY4) a écrit :
Hi All,
I'm not sure, if my observation is a "feature" or "bug", so I just report it (and didn't use the "bug-report"):
Setup:
Leshan Client using DTLS/PSK
Leshan Server
Both using Californium/Scandium.
When the lwm2m-client deregisters (lwm2m operation), the lwm2m-server response with a message and then closes the dtls session.
Sometimes this is executed by scandium in reverse order, because the message is sent "async via a queue" but the close is executed "sync".
If the execution is reversed, the server tries to send the response message without a DTLSSession and therefore starts a new handshake
with a "ClientHello" (see log below). But in my opinion, this is wrong. The server should send a "HelloRequest".
RFC 6347, page 23, says
"When the server desires a rehandshake, it transitions from the
FINISHED state to the PREPARING state to transmit the HelloRequest.
When the client receives a HelloRequest, it transitions from FINISHED
to PREPARING to transmit the ClientHello."
May be this doesn't clearly cover the situation above, but when the server sends a "ClientHello", the roles in the PSK
Handshake are exchanged. Therefore the server (now the handshake client) have to guess the "PSK identity" using the ip-address.
Using the "HelloRequest" will preserve the roles and therefore the handshake would run as "usual".
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ESY4)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de<http://www.bosch-si.de>
www.blog.bosch-si.com<http://www.blog.bosch-si.com>
achim.kraus@xxxxxxxxxxxx<mailto:achim.kraus@xxxxxxxxxxxx>
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
######################################## wireshark log ###############################################################
(client sends deregister)
No. Time Source Destination Protocol Length Info
88 13.647679000 192.168.10.111 192.168.10.103 DTLSv1.2 93 Application Data
(server close)
No. Time Source Destination Protocol Length Info
89 13.692304000 192.168.10.103 192.168.10.111 DTLSv1.2 73 Encrypted Alert
(server send "Client Hello", PSK handshake roles exchanged!)
No. Time Source Destination Protocol Length Info
90 13.747024000 192.168.10.103 192.168.10.111 DTLSv1.2 147 Client Hello
No. Time Source Destination Protocol Length Info
91 13.758528000 192.168.10.111 192.168.10.103 DTLSv1.2 102 Hello Verify Request
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx<mailto:cf-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
