Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
WIP: first implementation of draft-ietf-tls-dtls-connection-id-03 #824
Just for those who are interested, I prepared a WIP branch for the draft-ietf-tls-dtls-connection-id-03 implementation. Currently the house keeping need a lot more work. Depending on the answer to my issue tlswg/dtls-conn-id#28 it may get hard, if mixed usage is intended. That would require to update the peers ip-address after the record could be decrypted successfully.
This was referenced
Jan 10, 2019
Anyway, this unittest error seems to be irrelevant for testing cid.
And: currently it's still mostly used with java 1.8 .Newer ones may not work :-).
referenced this issue
Jan 17, 2019
I prepared a "interop workaround" for a go wip.
Starting the go server and using the sc-dtls-example-client "works on my machine" :-).
Start the go-server as described in the link above (please adjust the port to listen to 5684) .
The go-server should display the "HELLO WORLD" message and typing something into the go-server console sends something back.
The go-client and scandium server still requires some work.
@boaks thanks very much for the update.
I can confirm that the Scandium client interops OK with the go server.
I also fixed the signature verification bug that you spotted in the go client and tried it out with your example server. It works as well, which is cool :-)
Yes, apparently my home ISP (TalkTalk UK) was intercepting NXDOMAIN answers and remap them to pristine A records to an external service (http://barefruit.com/).
I have to thank Californium/Scandium tests for spotting that out :-)
After I changed my recursive to Cloudflare's everything works fine.
One issue is still confusing to me:
If I use the go-server, it seems that "exactly 1 byte more" must be used,
The 33 is the last real payload byte I sent, If add one more byte, it works.
But using the go-client, it works without that extra byte.
I am very interested in a support of the DTLS connection ID in Californium/Leshan.
(1) Do you have an idea of when it may be available in an official Californium/Leshan release ?
(2) Besides I am interested by using the connection ID in Leshan as well to identify a device.
From LwM2M 1.0.2 specifications: "Upon receiving a “Register” operation from the LwM2M Client, the LwM2M Server records the connection information of the registration message (e.g., source IP address and port or MSISDN) and uses this information for all future interactions with that LwM2M Client."
If the IP adress of my device changes, I'll have to perform a new registration of my device on the platform and I do not want to do that. The connection ID seems a good fit for me as "connection information"
What do you think of such an approach in Leshan ?
Thank you very much and have a good day.
(1) Milestone - depending on @sbernard31 opinion - californium 2.0.0-M14 may be released Friday next week.
(2) That's a difficult question. Let's hope, that it already works "magically" with the proper "EndpointContextMatcher". Wait for M14 and then I'm sure @sbernard31 and I will do our best to make it working.
@Philago, let's open a ticket at https://github.com/eclipse/leshan to discus about that. I didn't think too much about that but this is something we should address (and possible this will works out of the box).
This is not the case with Leshan : as long as you are using the "good identity" we accept client request, but the client MUST use an Registration Update to let know to the server its new IP address as specify in the specification. Here you can find some explanation about how this works for observations but I should write a more generic documentation about connection / session / registration life time.
and thank you for you answers.
@boaks : yes I am still interested in disabling the anti replay mechanism or at least to have the possibility to configure the size of the receive window
@sbernard31 : I think that there is someting I do not understand.
I understand that my notifications are going to be accepted as long as I use the same DTLS identity as established during my registration.
So the connection ID may be a good fit indeed (replacing the current DTLS identity ?), enabling to receive notifications (non confirmable) from a device whatever its source IP address/port. The update of the IP address of the device being performed during a register update, as long as the connection ID received is the same. But let's talk about that in a new ticket.
Some quick answer, but if this is sill not clear please open a ticket at https://github.com/eclipse/leshan. because we are a bit out of topic here...
For PSK, the PSK Identity
Session is identified by SessionID. DTLS connection is identify by source/dest/port (or CID).
We only take care of "DTLS identity" in Leshan. Imagine your device identifies itself using PSK. As long as the device is using the same identity (PSK ID), we consider we face the same peer. This means it can do a full handshake, an abbreviated one, or nothing (CID), we don't care as we only check "DTLS identity".