Hi, I've made some progress regarding the connection ID support. Now the communication works with both AEAD and Block Ciphers, on both server and client, and in both directions.
I’m a bit stuck now on Section 6 of the RFC 9146 (Peer Address Update): The issue is that I don’t really know how to signal to the application if a record was valid or invalid. This is also connected with another thing about the DTLS API that has been bothering me for a while now: Creating a DTLS Server that can handle multiple connections simultaneously is kind of complicated, because you’ll have to - create and bind a UDP socket - keep a list of sessions - for each packet, decide (by IP/port) if it belongs to an existing session or start a new session - use a queue-based DatagramTransport for each session so we can forward the incoming packets to the respective session - handle abandoned sessions - … Now, with Connection IDs you have to do some additional things: - Save the connection ID once it has been determined - Split each packet (or at least, each packet from a new IP/port) into its records and parse them to determine the connection ID (which there doesn’t seem to be a way to easily do using BouncyCastle, as the record parsing is part of the DtlsRecordLayer and thus can’t be used separately) - Find sessions by connection ID if available - If a packet for a session has an updated IP/port, determine if it is cryptographically valid and newer than previous packets before updating the address Especially the address update / packet verification is an issue, because (from the application side) the part where you pass the packets to BouncyCastle (DatagramTransport.Receive()) and the part where the packets are verified (DtlsTransport.Receive()) are separate. As in, there is no “OfferDatagram”-Method or anything similar that could give immediate feedback if the packet offered was valid and could be processed. If you (or anyone else) wants to have a look at what I’ve done so far, you can do that here: https://github.com/bcgit/bc-csharp/pull/380 There are also a few “//TODO[cid]” comments with questions/issues that need answering/fixing. Regards, Patrick PS: @Peter Dettman I sent a few mails to you directly over the last weeks. I don't want to come off as impatient, but I was worried your lack of response may be due to mails not arriving.
