[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Request/Response matching short term concern
|
I did not set a new date since there are still open issues and the review process will take another two weeks, once we have our RC ready. Since Leshan is the main client (of which I know) awaiting the release, but still has some "requests" for the release, I think we are fine.
Coming back to the tokens. Randomizing them is definitely on my list and we can include this for the 1.0.0 release. My way forward would be to actually remove the TokenLayer and put the generation into the Matcher. We can then create the tokens fully randomly and use the exchangesByToken map to check if a created token is currently in use.
> I see since commit a3c178952b426da5afe9949d7922ab2cb10db9cb we only
> use token when we do the request/response matching.
> if the token value generation is not easily predictable, I think this is
> acceptable at short term (we can even say this suits us) But it seems that is
> not the case. Currently we create it randomly one time then we just
> increment it each time we create a new request.
Using the exchangesByToken map also allows real per-endpoint tokens. Question is now, if we should be strict and add the remote address back into KeyToken or leave it to allow for changing IP addresses during observe (when using CoAP without DTLS). It is somewhat a security issue, but it actually starts with not using DTLS...
What do you think?
Ciao
Matthias
