Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cf-dev] Even less strict request response matching

Hi Kai,

but don't we need also a similar approach in TcpMatcher? Otherwise one can send notifications for another device with a new connection if he guesses the token. Or did I miss something here in the stack?

Regards,
Daniel

> -----Ursprüngliche Nachricht-----
> Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im
> Auftrag von Hudalla Kai (INST/ESY1)
> Gesendet: Montag, 22. August 2016 16:25
> An: cf-dev@xxxxxxxxxxx
> Betreff: 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
> _______________________________________________
> 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

Back to the top