[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Even less strict request response matching
|
Hi Daniel,
On Mo, 2016-08-22 at 13:48 +0000, Maier Daniel (INST/ECS4) wrote:
> Hi all,
>
> in Californium there exists the option
> "USE_STRICT_RESPONSE_MATCHING". Setting this to false, Californium
> does not consider the DTLS epoch to match responses/notifies to
> requests. This is not strictly conform to the specification. But I
> understand why this is useful. What do you think about to go even one
> step further: Some kind of “LAX_RESPONSE_MAPPING” that only checks
> that the DTLS identity is the same as the DTSL identity the request
> was sent to?
>
I assume you are referring to the authenticated identity of the DTLS
client, right? This could work if Scandium is configured to make client
authentication mandatory (this is optional for non PSK based cipher
suites). However, in PSK based scenarios the "identity" of a client is
simply an arbitrary string that might be shared by multiple (even
unrelated) clients either by coincidence or on purpose, i.e. a client
using the same identity as another client (but different key) could be
mistaken for the "other" client if there is no match based on the
session ID.
> Does anyone know why these strict restrictions were made in the CoAP
> specification? In LWM2M for example it is allowed to receive
> registration updates and de-registrations after a new handshake, but
> because of this CoAP restriction it is not possible to receive
> notifications.
>
> This “LAX_RESPONSE_MAPPING” would make it possible to receive
> notifies when there was a new DTLS handshake.
>
See above for why I think this is problematic ...
> Thanks
> Daniel
> _______________________________________________
> 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
