Plans for DTLS 1.2 Connection ID

[glerchundi]

Hi everyone, first of all congrats for the job you all are doing here. You got to a point where the product is really strong and reliable. 👏

Summary

• Support DTLS 1.2 Connection ID proposal: https://github.com/tlswg/dtls-conn-id
• RFC tracker: https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id

Motivation

As we use DTLS 1.2 for our IoT fleet this would help using it on NATed environments.

It seems that DTLS 1.3 includes the CID also as @daenney pointed in #188.

[Sean-Der]

@glerchundi I would love to do this!

I wasn't aware of the Connection ID work. This sounds really amazing, this could allow people to load balance WebRTC traffic finally.

[beriberikix]

FWIW, here's an example of using CID for load balancing with an IoT protocol: https://github.com/eclipse/californium/tree/wip_dtls_cid_cluster/demo-apps/cf-extplugtest-server#built-in-dtls-connection-id-load-balancer-cluster /by @boaks

[boaks]

You may check WIP - CID.
AFAIK, that's based on pion-dtls.

[boaks]

That extension is now the upcoming RFC9146.

Sure, it's more relevant for IoT than for other use-cases.

My experience with it is really great. My devices are now running over a week, using deep sleeping modes, and exchanging mainly one UDP-message pair (CoAP request/response) on wakeup. Very efficient, very reliable (with CoAP retransmissions on timeout in very rare cases). I developed end of last year a zephyr dtls-cid preview (based on tinydtls feature/connection_id and a thingy 91). It's now up for a week.

[beriberikix]

Awesome! Is that preview available somewhere?

[boaks]

I plan to make it available. But I have to do some tasks ahead.
It's mainly tinydtls / feature/cid branch with the other bugfixes PRs pending.
Therefore I would like to have some of them merged before, that makes it easier to maintain the preview.
The second part is very small, it's the nRF9160 udp sample together with the zephyr coap-lient merged into the tinydtls dtls-client sample.
So, maybe next month or at least at Q2/2022.
End of last week, also the pending mbedtls PR 5061 was fixed. Let's see, how long that takes.

[glerchundi]

Thanks for the heads up! Great to see community is moving!

[machineroom]

Hi, are there any updates on this?

[boaks]

For mbedtls, yes. It's merged in the meantime.

[machineroom]

For mbedtls, yes. It's merged in the meantime.

thanks. I haven't seen anything in pion/dtls (though I'm new to it so maybe missed it)

[hasheddan]

Hey folks! I’m planning to work on adding support for Connection IDs in pion/dtls imminently — @Sean-Der any tips or requests?

[Sean-Der]

That is great news @hasheddan!

I believe it will be pretty straight forward. On State you will have a ConnectionId *int

When generating data in writePackets you can add it as needed. I will add you to the github org and you should start a branch ASAP.

I would love to work together on this also. Would a short audio/video call be helpful to get started?

[hasheddan]

@Sean-Der sounds great! I'll join the Slack and give you a ping 👍🏻

[niondir]

Hi, we are also looking into this. I'm very interested in Updates about the state of the implementation. Let me know when I can help somehow.

[boaks]

Just to mention:
If there is some interest in interoperability tests with Eclipse/Californium and Eclipse/tinydtls, just notify me here in this issue, when your work reaches a state, where some tests makes sense.
Recently the first cellular device starts to support DTLS CID (Nordic nRF9160 mfw 1.3.5) so it may get more and more interesting.

[hasheddan]

@niondir I should have an initial implementation ready soon 👍🏻

@boaks definitely interested in the interoperability tests! Will make sure to ping when ready.

[boaks]

Also, if you have any question about RFC9146, just ask, I will try my best to answer it.

[hasheddan]

@boaks #558 has DTLS CIDs working e2e and I would love to get some interoperability tests going! I was checking out the current tests here -- would that be a good place to add similar tests for pion/dtls? I am also interested in expanding the e2e tests in this repository as currently only openssl is tested against.

[boaks]

would that be a good place to add similar tests for pion/dtls?

Yes, but I'm not common with "go" ;-).
So, if you like to help, the first step is usually a simple manual test.
Maybe you can point me to a tutorial, how to checkout your work and to start the server and client?

[hasheddan]

@boaks I added some comments about how to run the e2e tests using the Docker image in #558, but I'll setup a manual test with scandium and report back!

[boaks]

The docker stuff is fine. I already had a first check of my wireshark captures.
If it would be possible to have a dtls server running in docker for tests with clients using other implementations, that would be great for first tests.

[hasheddan]

@boaks I can build and push one to Dockerhub for now, then I'll see about adding the machinery to this repo 👍🏻 In the meantime, I was able to get some initial testing running with the DTLS client demo app in californium and this slightly modified example PSK listener:

package main

import (
	"context"
	"fmt"
	"net"
	"time"

	"github.com/pion/dtls/v2"
)

func main() {
	addr := &net.UDPAddr{IP: net.ParseIP("127.0.0.1"), Port: 5684}

	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()
	config := &dtls.Config{
		PSK: func(hint []byte) ([]byte, error) {
			fmt.Printf("Client's hint: %s \n", hint)
			return []byte("secretPSK"), nil
		},
		PSKIdentityHint: []byte("Pion DTLS Client"),
		CipherSuites:    []dtls.CipherSuiteID{dtls.TLS_PSK_WITH_AES_128_CCM_8},
		ConnectContextMaker: func() (context.Context, func()) {
			return context.WithTimeout(ctx, 30*time.Second)
		},
		ConnectionIDGenerator: dtls.RandomCIDGenerator(8),
	}

	listener, err := dtls.Listen("udp", addr, config)
	if err != nil {
		panic(err)
	}
	defer func() {
		if err := listener.Close(); err != nil {
			panic(err)
		}
	}()

	fmt.Println("Listening")

	conn, err := listener.Accept()
	if err != nil {
		panic(err)
	}

	b := make([]byte, 8192)
	for {
		n, err := conn.Read(b)
		if err != nil {
			panic(err)
		}
		fmt.Printf("Echoing received message: %s\n", string(b[:n]))
		if _, err := conn.Write(b[:n]); err != nil {
			panic(err)
		}
	}
}

[boaks]

I was able to build and run the container. No need to push a container in a registry.
But please add something, that I can start the container as server.

[boaks]

It's pretty easy to provide a capture instead of a picture. For now, as no GO user, I'm not able to start a test server or client. But If you provide captures, I will have a look at them.

[hasheddan]

@boaks see #558 (comment) for information about build and running a test server with connection ID support, as well as a link to a packet capture of testing with californium 👍🏻