Add support for DTLS 1.2 Connection IDs #473

hasheddan · 2023-08-24T16:54:29Z

Updates pion/dtls dependency to bring in support for DTLS 1.2 Connection IDs.

Fixes #467

Wireshark capture of provided example:

I also ran with pion/dtls trace logging enabled, which demonstrates the continuation of the connection.

server

🥽 (go-coap) go run ./examples/dtls/cid/server/main.go 
dtls TRACE: 10:04:23.285196 handshaker.go:177: [handshake:server] Flight 0: Preparing
dtls TRACE: 10:04:23.285239 handshaker.go:177: [handshake:server] Flight 0: Sending
dtls TRACE: 10:04:23.285241 handshaker.go:177: [handshake:server] Flight 0: Waiting
dtls TRACE: 10:04:23.285308 handshaker.go:291: [handshake:server] Flight 0 -> Flight 2
dtls TRACE: 10:04:23.285311 handshaker.go:177: [handshake:server] Flight 2: Preparing
dtls TRACE: 10:04:23.285314 handshaker.go:177: [handshake:server] Flight 2: Sending
dtls TRACE: 10:04:23.285317 conn.go:420: [handshake:server] -> HelloVerifyRequest (epoch: 0, seq: 0)
dtls TRACE: 10:04:23.285342 handshaker.go:177: [handshake:server] Flight 2: Waiting
dtls TRACE: 10:04:23.285458 handshaker.go:291: [handshake:server] Flight 2 -> Flight 4
dtls TRACE: 10:04:23.285466 handshaker.go:177: [handshake:server] Flight 4: Preparing
dtls TRACE: 10:04:23.285472 handshaker.go:177: [handshake:server] Flight 4: Sending
dtls TRACE: 10:04:23.285477 conn.go:420: [handshake:server] -> ServerHello (epoch: 0, seq: 1)
dtls TRACE: 10:04:23.285481 conn.go:420: [handshake:server] -> ServerKeyExchange (epoch: 0, seq: 2)
dtls TRACE: 10:04:23.285484 conn.go:420: [handshake:server] -> ServerHelloDone (epoch: 0, seq: 3)
dtls TRACE: 10:04:23.285505 handshaker.go:177: [handshake:server] Flight 4: Waiting
dtls DEBUG: 10:04:23.285738 conn.go:886: CipherSuite not initialized, queuing packet
dtls DEBUG: 10:04:23.285751 conn.go:764: received packet of next epoch, queuing packet
Client's hint: Pion DTLS Client 
dtls TRACE: 10:04:23.285783 conn.go:892: server: <- ChangeCipherSpec (epoch: 1)
dtls TRACE: 10:04:23.285795 handshaker.go:291: [handshake:server] Flight 4 -> Flight 6
dtls TRACE: 10:04:23.285797 handshaker.go:177: [handshake:server] Flight 6: Preparing
dtls TRACE: 10:04:23.285804 handshaker.go:245: [handshake:server] -> changeCipherSpec (epoch: 1)
dtls TRACE: 10:04:23.285807 handshaker.go:177: [handshake:server] Flight 6: Sending
dtls TRACE: 10:04:23.285809 conn.go:420: [handshake:server] -> Finished (epoch: 1, seq: 4)
dtls TRACE: 10:04:23.285829 handshaker.go:177: [handshake:server] Flight 6: Finished
dtls TRACE: 10:04:23.285833 conn.go:243: Handshake Completed
2023/08/28 10:04:23 got message in handleA:  Code: GET, Token: f272b2d832504b59, Path: /a, Type: Confirmable, MessageID: 49963 from 127.0.0.1:34105
2023/08/28 10:04:23 got message in handleB:  Code: GET, Token: fa7147ece5362a99, Path: /b, Type: Confirmable, MessageID: 49964 from 127.0.0.1:34105
2023/08/28 10:04:23 got message in handleA:  Code: GET, Token: 6954967287626bc8, Path: /a, Type: Confirmable, MessageID: 49967 from 127.0.0.1:43229
2023/08/28 10:04:23 got message in handleB:  Code: GET, Token: e14c0144a32444dc, Path: /b, Type: Confirmable, MessageID: 49968 from 127.0.0.1:43229

client

🥽 (go-coap) go run ./examples/dtls/cid/client/main.go
dtls TRACE: 10:04:23.284858 handshaker.go:177: [handshake:client] Flight 1: Preparing
dtls TRACE: 10:04:23.284887 handshaker.go:177: [handshake:client] Flight 1: Sending
dtls TRACE: 10:04:23.284893 conn.go:420: [handshake:client] -> ClientHello (epoch: 0, seq: 0)
dtls TRACE: 10:04:23.284945 handshaker.go:177: [handshake:client] Flight 1: Waiting
dtls TRACE: 10:04:23.285360 handshaker.go:291: [handshake:client] Flight 1 -> Flight 3
dtls TRACE: 10:04:23.285366 handshaker.go:177: [handshake:client] Flight 3: Preparing
dtls TRACE: 10:04:23.285370 handshaker.go:177: [handshake:client] Flight 3: Sending
dtls TRACE: 10:04:23.285378 conn.go:420: [handshake:client] -> ClientHello (epoch: 0, seq: 1)
dtls TRACE: 10:04:23.285393 handshaker.go:177: [handshake:client] Flight 3: Waiting
dtls TRACE: 10:04:23.285585 flight3handler.go:102: [handshake] use cipher suite: TLS_PSK_WITH_AES_128_CCM_8
Server's hint: Pion DTLS Server 
dtls TRACE: 10:04:23.285595 handshaker.go:291: [handshake:client] Flight 3 -> Flight 5
dtls TRACE: 10:04:23.285598 handshaker.go:177: [handshake:client] Flight 5: Preparing
dtls TRACE: 10:04:23.285625 handshaker.go:245: [handshake:client] -> changeCipherSpec (epoch: 1)
dtls TRACE: 10:04:23.285627 handshaker.go:177: [handshake:client] Flight 5: Sending
dtls TRACE: 10:04:23.285630 conn.go:420: [handshake:client] -> ClientKeyExchange (epoch: 0, seq: 2)
dtls TRACE: 10:04:23.285633 conn.go:420: [handshake:client] -> Finished (epoch: 1, seq: 3)
dtls TRACE: 10:04:23.285654 handshaker.go:177: [handshake:client] Flight 5: Waiting
dtls TRACE: 10:04:23.285903 conn.go:892: client: <- ChangeCipherSpec (epoch: 1)
dtls TRACE: 10:04:23.285937 handshaker.go:291: [handshake:client] Flight 5 -> Flight 5
dtls TRACE: 10:04:23.285940 handshaker.go:177: [handshake:client] Flight 5: Finished
dtls TRACE: 10:04:23.285944 conn.go:243: Handshake Completed
2023/08/28 10:04:23 Response payload: Code: GET, Token: f272b2d832504b59, ContentFormat: text/plain;charset=utf-8, Type: Acknowledgement, MessageID: 49963, PayloadLen: 13
2023/08/28 10:04:23 Response payload: Code: Content, Token: fa7147ece5362a99, ContentFormat: text/plain;charset=utf-8, Type: Confirmable, MessageID: 55126, PayloadLen: 13
dtls TRACE: 10:04:23.286554 handshaker.go:177: [handshake:client] Flight 5: Finished
dtls TRACE: 10:04:23.286563 conn.go:243: Handshake Completed
2023/08/28 10:04:23 Response payload: Code: GET, Token: 6954967287626bc8, ContentFormat: text/plain;charset=utf-8, Type: Acknowledgement, MessageID: 49967, PayloadLen: 13
2023/08/28 10:04:23 Response payload: Code: Content, Token: e14c0144a32444dc, ContentFormat: text/plain;charset=utf-8, Type: Confirmable, MessageID: 55130, PayloadLen: 13

jkralik · 2023-08-25T06:09:14Z

Nice. Is it possible to extend the example by resuming the connection?

hasheddan

@jkralik absolutely 👍🏻 will get this updated once the referenced PR in the replace statement is merged!

hasheddan

@jkralik updated with examples, as well as logs and a capture of the behavior 👍🏻

hasheddan · 2023-08-28T14:18:13Z

examples/dtls/cid/server/main.go

+// wrappedListener wraps a net.Listener and implements a go-coap DTLS
+// server.Listener.
+// NOTE: this utility is for example purposes only. Context should be handled
+// properly in meaningful scenarios.
+type wrappedListener struct {
+	l      net.Listener
+	closed atomic.Bool
+}


@jkralik I'm not sure if there is appetite to do so, but I would be interested in go-coap defining a common ContextListener and utility wrappers to allow for the passing of net.Listener. For now, consumers of this functionality will need to use a custom listener as demonstrated in this example.

Yes, I see the point. But one thing - Has handshaking been moved to Conn.Read/Write from listener.Accept? If not, we need to incorporate it with https://github.com/plgd-dev/go-coap/blob/master/net/dtlslistener.go#L37.

But one thing - Has handshaking been moved to Conn.Read/Write from listener.Accept? If not, we need to incorporate it with https://github.com/plgd-dev/go-coap/blob/master/net/dtlslistener.go#L37.

@jkralik I'm not sure I'm following your suggestion here. Handshaking has not moved -- from the perspective of the existing DTLSListener nothing has changed. In fact, setting the connectionIDGenerator on the pion/dtls config passed to NewDTLSListener would enable connection ID support. The issue is that the underlying pion/transport/udp package being used does not support routing based on Connection ID. A replacement has been introduced in https://github.com/pion/dtls/tree/master/internal/net/udp, which is in internal for now so that it can be iterated upon prior to folks taking a direct dependency on its API. It can be consumed by using the pion/dtls.Listen function.

I do think it would be good for the functionality to become the default in go-coap, but right now the DTLSListener is restrictive about the behavior it allows (anecdotally, we use a different implementation of the DTLSListener internally so introduce additional functionality). This PR maintains the existing go-coap functionality, while also demonstrating how a consumer can provide their own listener for custom functionality (including connection IDs).

It seems like previously the pion/dtls.Listener was used, but then was moved away from in order to introduce parallel handshakes. My understanding of this functionality is that the DTLSListener essentially just continuously accepts connections so that the handshake can begin and complete, perhaps before the DTLS Server calls AcceptWithContext(). It seems the major blocker from using the pion/dtls.Listener is the [starting of the pion/dtls.Server in a go pool. My question is whether this could be functionality introduced in pion/dtls instead (i.e. stop blocking Accept() on completion of the handshake), which would allow go-coap to treat the DTLS listener as just a net.Listener (with the generic wrapping to support context handling).

(Note: this is what I would like to do long term, but the changes in this PR enable folks to implement custom behavior to enable connection ID support, while keeping the previous behavior of go-coap unchanged when using the provided DTLSListener implementation. This feels like a good intermediate step to me as it does not introduce any breaking changes in go-coap, but I am open to discussion and happy to explore other avenues as well!)

It seems like previously the pion/dtls.Listener was used, but then was moved away from in order to introduce parallel handshakes. My understanding of this functionality is that the DTLSListener essentially just continuously accepts connections so that the handshake can begin and complete, perhaps before the DTLS Server calls AcceptWithContext(). It seems the major blocker from using the pion/dtls.Listener is the [starting of the pion/dtls.Server in a go pool. My question is whether this could be functionality introduced in pion/dtls instead (i.e. stop blocking Accept() on completion of the handshake), which would allow go-coap to treat the DTLS listener as just a net.Listener (with the generic wrapping to support context handling).

There is a discussion (pion/dtls#279) about moving the handshake, as it is in the golang/crypto package, to the Read/Write functions.

I agree with you; we can proceed step by step.

hasheddan · 2023-08-28T17:30:15Z

go.mod

@@ -5,8 +5,8 @@ go 1.18
 require (


Looks like linter is stuck on replace statement, but it has been removed and required functionality has been merged upstream 👍🏻

Updates pion/dtls dependency to bring in support for DTLS 1.2 Connection IDs. Signed-off-by: Daniel Mangum <georgedanielmangum@gmail.com>

Adds a server example for DTLS Connection IDs. Random 8 byte CIDs are used. Note that the built-in go-coap DTLS listener does not support this functionality presently as it uses a UDP listener from pion/transport that does not support routing datagrams based on attributes other than remote address. Signed-off-by: Daniel Mangum <georgedanielmangum@gmail.com>

Adds a DTLS Connection ID client example. Two different "connections" are used with the second resuming using the state from the first, allowing it to bypass performing a second DTLS handshake. Signed-off-by: Daniel Mangum <georgedanielmangum@gmail.com>

pion/dtls uses net.ListenUDP under the hood to allow for changing remote addresses. Therefore, if there is a mismatch between IPv4 and IPv6 between the client and server then they are unable to communicate. Additionally, writing to 0.0.0.0 fails on Windows, so 127.0.0.1 is specified explicitly. Signed-off-by: Daniel Mangum <georgedanielmangum@gmail.com>

jkralik · 2023-08-29T19:21:20Z

Thx for contribution :).

hasheddan · 2023-08-29T19:22:43Z

Thank you for all the time and effort you have invested in this library @jkralik! We are always willing to contribute where we can :)

jkralik · 2023-08-29T20:08:36Z

resolves #472

nicgirault · 2024-04-11T10:47:28Z

@jkralik your last comment mark #472 as resolved but the issue is still opened. Is serializing and deserializing a UDP DTLS connection functional?

jkralik self-requested a review August 25, 2023 06:09

hasheddan commented Aug 25, 2023

View reviewed changes

hasheddan force-pushed the tmp/just-cid branch from 995e122 to 8e43def Compare August 28, 2023 14:16

hasheddan commented Aug 28, 2023

View reviewed changes

hasheddan force-pushed the tmp/just-cid branch from 8e43def to dc1228e Compare August 28, 2023 14:27

hasheddan mentioned this pull request Aug 28, 2023

Include connection IDs in serialized state pion/dtls#573

Merged

hasheddan force-pushed the tmp/just-cid branch from dc1228e to 30d59ce Compare August 28, 2023 16:10

hasheddan marked this pull request as ready for review August 28, 2023 16:11

hasheddan force-pushed the tmp/just-cid branch from 4d62dd3 to e86c1a0 Compare August 28, 2023 17:26

hasheddan commented Aug 28, 2023

View reviewed changes

hasheddan added 4 commits August 29, 2023 21:10

Add support for DTLS 1.2 Connection IDs

def3b57

Updates pion/dtls dependency to bring in support for DTLS 1.2 Connection IDs. Signed-off-by: Daniel Mangum <georgedanielmangum@gmail.com>

Add DTLS CID client example

6ecbb1e

Adds a DTLS Connection ID client example. Two different "connections" are used with the second resuming using the state from the first, allowing it to bypass performing a second DTLS handshake. Signed-off-by: Daniel Mangum <georgedanielmangum@gmail.com>

jkralik force-pushed the tmp/just-cid branch from e86c1a0 to 4f8f9da Compare August 29, 2023 19:10

jkralik approved these changes Aug 29, 2023

View reviewed changes

jkralik merged commit 2f8ee9c into plgd-dev:master Aug 29, 2023

Danielius1922 mentioned this pull request Sep 5, 2023

Upgrade dependencies #481

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for DTLS 1.2 Connection IDs #473

Add support for DTLS 1.2 Connection IDs #473

hasheddan commented Aug 24, 2023 •

edited

Loading

jkralik commented Aug 25, 2023

hasheddan left a comment

hasheddan left a comment

hasheddan Aug 28, 2023

jkralik Aug 28, 2023 •

edited

Loading

hasheddan Aug 28, 2023

hasheddan Aug 28, 2023

jkralik Aug 29, 2023

hasheddan Aug 28, 2023

jkralik commented Aug 29, 2023

hasheddan commented Aug 29, 2023

jkralik commented Aug 29, 2023

nicgirault commented Apr 11, 2024

Add support for DTLS 1.2 Connection IDs #473

Add support for DTLS 1.2 Connection IDs #473

Conversation

hasheddan commented Aug 24, 2023 • edited Loading

jkralik commented Aug 25, 2023

hasheddan left a comment

Choose a reason for hiding this comment

hasheddan left a comment

Choose a reason for hiding this comment

hasheddan Aug 28, 2023

Choose a reason for hiding this comment

jkralik Aug 28, 2023 • edited Loading

Choose a reason for hiding this comment

hasheddan Aug 28, 2023

Choose a reason for hiding this comment

hasheddan Aug 28, 2023

Choose a reason for hiding this comment

jkralik Aug 29, 2023

Choose a reason for hiding this comment

hasheddan Aug 28, 2023

Choose a reason for hiding this comment

jkralik commented Aug 29, 2023

hasheddan commented Aug 29, 2023

jkralik commented Aug 29, 2023

nicgirault commented Apr 11, 2024

hasheddan commented Aug 24, 2023 •

edited

Loading

jkralik Aug 28, 2023 •

edited

Loading