Hi Simon
Great! I agree with your assumptions and also would like to focus on a solution that supports matching based on the security
context (i.e., it works even when the endpoint address changed). There should, however, be some kind of “strict mode” that people could activate…
For the implementation, I imagine a more flexible way for the exchangesBy* hashmap keys that uses a context provided by
the messages: for CoAP it is the endpoint address, for CoAPS the security context.
Currently, only the Request provides a principle through getSenderIdentity(). Is it enough to have it there and then rely
on secure matching? Or should there maybe be something similar for responses and more importantly for notifications?
Ciao
Matthias
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Simon Bernard
Sent: Donnerstag, 10. September 2015 14:42
To: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
Subject: [cf-dev] Request/Response matching for DTLS-Secured exchange
Hi,
I would like to implement the request/response matching on DTLS-Secured CoAP.
If I well understand the code : Currently californium does not manage it at all. It only do the matching on peer address and token, As it was describe in the spec for non secured exchange :
5.3.2. Request/Response Matching Rules
".... The source endpoint of the response MUST be the same as the destination endpoint of the original request. ...
... In a piggybacked response, the Message ID of the Confirmable request and the Acknowledgement MUST match, and the tokens of the response and original request MUST match. In a separate response, just the tokens of the response and original request MUST match
..."
For DTLS-Secured exchange the spec say :
9.1.1. Messaging Layer
"... The following rules are added for matching an Acknowledgement message or Reset message to a Confirmable message, or a Reset message to a Non-confirmable message: The DTLS session MUST be the same, and the epoch MUST be the same. ... "
9.1.2. Request/Response Layer
"... The following rules are added for matching a response to a request: The DTLS session MUST be the same, and the epoch MUST be the same. ..."
I know there have been some discussions about the epoch constraint which could be too strict. And something like the
"same session and the same cipher suite" could be acceptable. The "source/destination endpoint matching" constraints should not be needed too in secured exchange.
Does it sounds good for you ?
Simon
