Re: [cf-dev] Request/Response matching for DTLS-Secured exchange

["Kovatsch Matthias" <kovatsch@xxxxxxxxxxx>]

Hi all, hi Simon

Some more thoughts from my side:

1) Message Context.
A first solution could be to create MessageContext at element-connector level which will contain :
- peer address for UDP.
- peer address + session ID + epoch for DTLS strict mode.
- session ID + cipher Suite for DTLS flexible mode.

This context would be used to build Keys in Matcher. (as Kai explains MessageContext.equals() is used for matching)

I would not return detailed fields like epoch for the context, but an instance that can serve as key directly. For this, it must implement equals() to be used as a key in a hashmap, which does the actual matching.

This is clearly elegant and make the Californium CoAP stack totally independant of security layer.
But the real meaning of MessageContext is "Elements needed by CoAP to do Request/Response Matching", in other word we introduce a semantic dependency in Element-connector and Scandium to CoAP.
This is acceptable if element-connector and scandium aim only/mainly CoAP protocol.

I don’t see it. Most protocols match per endpoint, which is either socket address or the strict mode key. If there pop up any other special cases for other reasonable protocols (like the DTLS flexible mode), we can add it.

An example which shows this dependency is a bit weird is that the choice between strict or flexible mode, which is a CoAP choice, will be done in Scandium (When we will create the MessageContext object)
This could also be error prone is someone adds a field in MessageContext without knowing this will impact the Request/Response Matching of CoAP.

At the application layer (usually CoAP), the developer decides whether to include only element-connector or also Scandium and also the mode. The application layer only gets an instance (from the connector probably) of something that implements MessageContext and uses it as key for the hashmap. It does not require specific fields. When Scandium is used, the secure MessageContext class from Sc will now how to compare itself to other contexts. The mode could go into the network config for Scandium.

2) DTLS Security Context.
We could add the Security Context at Element-connector level which is just a map of properties (String->Object) and maybe a protocol name (String)

As I said, there shouldn’t be access to specific fields. This should solve this.

 

The main headache is how to put a message into the hashmap on send. For UDP, the remote address is known and could be passed to the connector to get the MessageContext instance. For DTLS, as mentioned, the DtlsConnector would need to perform a handshake to return a MessageContext. Maybe this is a good way? (BTW: I think we need to adjust the ReliabiltyLayer timeouts for DTLS messages.) Do we want to support multiple security contexts in parallel?

Ciao
Matthias