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

[Simon Bernard <contact@xxxxxxxxxxxxxxx>]

I rethought about that, I did not found any perfect solution :/ :

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)
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.
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.


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)
The Security Context will be null on unsecure connection and could contains any necessary properties for any secure connection. (not only DTLS)
The choice of what we need to do the Request/Response matching will be done in californium.core (e.g. the Matcher), we will search for sessionID, epoch, ciphersuite properties depending of the mode used. (Maybe we could use the Network config to choose between strict and flexible mode)
This time this is the CoAP implementation which will be semantically dependent to DTLS. (But we do not introduce code dependency from Californium.core to Scandium)
This may seem wierd but as the Security part of the CoAP specification explicitly depends of DTLS, maybe this make sense if we retrieve this dependency in the implementation.

What did you think about that ? Which is the more acceptable for you ? any better ideas ?

Simon

Le 10/09/2015 19:03, Simon Bernard a écrit :

I suppose we could add Security Contex at message level in a same way we add the principle but this is done only at request reception and we need it when we send a message too. (to fill the exchangeBy* maps).
Maybe we could had a getSecurityContext(InetSocketAddress) on Connector, we can call it to fill the exchangeBy* maps before we send a message ? But this solution seems to have a "transactional" issue. (I mean If an handshake is done between the "getSecurityContext" and the "Connector.send" :(

Yes. Also this implies security for the normal CoapEndpoint, and hence also a dependency on Scandium, even when it is not used.

[Hudalla Kai (INST/ESY)] Using the approach above, this can easily prevented by means of having UdpConnector return an instance based on the peer’s address and Scandium return an instance based on peer’s address and session ID. Both MessageContext implementations would then need to override hash() and equals() accordingly so that Californium can simply use sentCtx.equals(receivedCtx) to do the check …

[Simon] I thought about that too, but after reflexion I'm not sure this kind of abstraction was really relevant, I mean the choice of what we will set in the MessageContext will be done in function of our needs in CoAP request/response matching.
This looks a bit strange ? I mean for example, if we are in flexible mode we don't want the epoch field, but if I don't use CoAP why should I can have access to epoch field ?

[Matthias] (Just in case: Indeed I meant to do the strategy pattern thing instead of this J) It would actually be the hashmaps in the Matcher that do this comparison when trying to retrieve an existing Exchange based on the key. Since we still need MID, Token, and URI keys, the corresponding key classes would be fed this MessageContext.

Probably, the key classes should be moved from Exchange to the Matcher.

Also note that KeyToken currently relies on the Token alone, enabling such endpoint address changes for Observe!

Simon, do you actually plan to this for the Release or is it more a long-term thing? Because we also need to consider other transports for this context…

[Simon] If the release date is the 16th september I think this is clearly too short, but we would like to have usable version as soon as possible. (a milestone version next the release will be ok for us)

Ciao
Matthias

_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev