Test epoch after session resumption.

[boaks]

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

[sbernard31]

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."

[boaks]

UdpMatcher:

    private boolean isResponseRelatedToDtlsRequest(final CorrelationContext requestContext, final CorrelationContext responseContext) {
        if (responseContext == null) {
            return false;
        } else {
            return requestContext.get(DtlsCorrelationContext.KEY_SESSION_ID)
                    .equals(responseContext.get(DtlsCorrelationContext.KEY_SESSION_ID))
                    && requestContext.get(DtlsCorrelationContext.KEY_CIPHER)
                            .equals(responseContext.get(DtlsCorrelationContext.KEY_CIPHER));
        }
    }

    private boolean isResponseStrictlyRelatedToDtlsRequest(final CorrelationContext requestContext, final CorrelationContext responseContext) {
        if (responseContext == null) {
            return false;
        } else {
            return requestContext.get(DtlsCorrelationContext.KEY_SESSION_ID)
                    .equals(responseContext.get(DtlsCorrelationContext.KEY_SESSION_ID))
                    && requestContext.get(DtlsCorrelationContext.KEY_EPOCH)
                            .equals(responseContext.get(DtlsCorrelationContext.KEY_EPOCH))
                    && requestContext.get(DtlsCorrelationContext.KEY_CIPHER)
                            .equals(responseContext.get(DtlsCorrelationContext.KEY_CIPHER));
        }
    }

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.

[sophokles73]

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 ...

[boaks]

According RFC6347, section 4.3.1, the record layer defines the sequence_number as

uint48 sequence_number;

So, why is it then 2^16 instead of 2^48 ?

[sophokles73]

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.

[sbernard31]

Just to be clear the CoAP spec say :

• "same epoch" which means "no rehandshake".
• and "same connection" which means "no session resumption".

We currently have 2 mode :

• "strict" which doesn't allow rehandshake
• "relaxed" which allow rehanshake.
  both allow session resumption, so both is out of spec.

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.

[boaks]

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.

Exactly! I was just trying to find out, what "flavors" are right now supported.

[boaks]

Thanks for the discussion. I close this.