-
Notifications
You must be signed in to change notification settings - Fork 365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test epoch after session resumption. #137
Test epoch after session resumption. #137
Conversation
The test shows, its still 1 after resumption. So, is this a bug? If not, I'm wondering, why we need the two variants of isResponse???RelatedToDtlsRequest. Do we want/require to support a reshandshake? Signed-off-by: Achim Kraus <achim.kraus@bosch-si.com>
As I understand the DTLS spec, after a resumption the epoch is alway equals to 1. I don't know if scandium support reshanshake. I never test it. I see we only check the epoch but from my point of view if we want to strickly respect the RFC 7641 [1] (and so make it unusable in IPv4 world 😁 ) we should check same epoch and same connection too. [1] "All notifications resulting from a GET request with an Observe Option MUST be returned within the same epoch of the same connection as the request." |
UdpMatcher:
So the difference is to check the epoch, but this seems to be only relevant for rehandshake. And so, if noone uses the rehandshake, I don't know why we use 2 methods. |
We do not know if anybody wants to use re-handshake or not. There is no clear decision yet whether we want to support it at all. If we decide to remove support for it then I agree with @boaks that we can get rid of strict checking. This would also mean that a session can only be used for 2^16 messages max which is probably not such a big problem ... |
According RFC6347, section 4.3.1, the record layer defines the sequence_number as
So, why is it then |
Sorry, then it's 2^48. The point being: once epoch 1 is exhausted, the connection needs to be either terminated and newly established or an abbreviated handshake needs to be done in order to replace the existing connection and start over with a fresh epoch 1. |
Just to be clear the CoAP spec say :
We currently have 2 mode :
Personnally, I think the right check should be "same DTLS identity or same session (if there is no authentication)" As it seems there is no clear consensus on this, maybe we should make this customizable using a kind of CorrelationStrategy as you proposed @boaks in #104. And let users chose what they want. About removing rehandshake, I have no strong opinion. If you want to remove it, I will not disagree as I'm not sure to see use case for rehandshake. |
Exactly! I was just trying to find out, what "flavors" are right now supported. |
Thanks for the discussion. I close this. |
NOT INTENDED TO BE REALLY MERGED!!!
The test shows, the epoch is still 1 after resumption. So, is this a bug?
If not, I'm wondering, why we need the two variants of
isResponse???RelatedToDtlsRequest (UdpMatcher).
Do we want/require to support a reshandshake?
Signed-off-by: Achim Kraus achim.kraus@bosch-si.com