Does Bouncy Castle Support Connection ID ?

[sbernard31]

I would like to know if Bouncy Castle support RFC9146 - Connection Identifier for DTLS 1.2 (also known as CID) ?

I see nothing about that :

• on main page,
• or in issue tracker.

But there are some code about that ?

Especially:

   /*
    * RFC 9146
    */
   public static final int connection_id = 54;

Could you confirm if this is available or not ?

[sbernard31]

@peterdettman looking at the code there is maybe some support at client side but not really at server one ?

In you have any information about that I would appreciate 🙏

[peterdettman]

AbstractTlsClient and AbstractTlsServer both have a GetNewConnectionID method (default null disables connection IDs) which you can override to generate a new connection ID. The implementation will automatically perform extension negotiation, then set SecurityParameters properties ConnectionIDLocal and ConnectionIDPeer (or both will be null when connection ID not negotiated).

The DTLS record layer is connection ID aware in regard to reading/writing records, however I gather routing incoming packets to the correct DtlsTransport can be a bit tricky; DtlsTransport.Receive(Pending) methods taking a DtlsRecordCallback were added per the original customer's needs, so you might need them too. If you can see a way to make this part simpler, suggestions welcome too.

[sbernard31]

@peterdettman thx a lot for clarification. 🙏

I did some test about connection Id and at first sight it seems to work.

About :

The DTLS record layer is connection ID aware in regard to reading/writing records, however I gather routing incoming packets to the correct DtlsTransport can be a bit tricky; DtlsTransport.Receive(Pending) methods taking a DtlsRecordCallback were added per the original customer's needs, so you might need them too. If you can see a way to make this part simpler, suggestions welcome too.

That's not clear to me how I'm supposed to use the DtlsRecordCallback 🤔

Here I understand that either I do

1. Try all transports

For each UDP datagram that arrives…
Feed it to every active DTLSTransport.receive(buffer, off, len, waitMillis, callback)…
Inside each callback, check if the CID matches the one that session expects, drop if not.

but that's sounds not so efficient 🤔 , so I guess this is not the idea

2. CID probe
For each UDP datagram that arrives…
creates a throwaway DTLSRecordLayer just to parse the record header. (but I need a kind of fake transport)
The DTLSRecordCallback.notifyRecord(...) is invoked before any crypto or state changes — we grab the CID here.
With the CID, we do a map lookup to find the right DTLSTransport.

3. manual simple/partial parsing

Naively, I would have do a simple/partial record parsing before routing based on CID.

[peterdettman]

Definitely 3. for the routing. The tricky part is "dispatching" the newly-arrived packet to the DtlsTransport that wants to "receive" its records. Probably proper async support is very desirable at this point (being able to push the packet to the right DTLS connection), but at the moment you essentially need to put the packet in a queue of some kind so that the connection can "Receive" it from there, then also keep calling ReceivePending since packets can potentially contain multiple records.

Presumably the original submitter had their reasons for DtlsRecordCallback, perhaps you will stumble into them down the line!

[sbernard31]

@peterdettman To do the 3. way, we need to do simple/partial record parsing.

Is there good way to do that ? I mean is there an API in bc-java to parse the record just enough to be able to "dispatch" the packet to the right DtlsTransport ?

In my current code I do something like : https://github.com/eclipse-leshan/leshan/blob/07d2f3e00b0dfa4bfea61e07b6cf6bf886a6519d/leshan-tl-jc-server-coaps/src/main/java/org/eclipse/leshan/transport/javacoap/server/coaps/bc/endpoint/DtlsConnectionHandler.java#L224-L263

It would be better to reuse bc-java code.