Duplicate requests not handled during OSCORE context rederivation

[burrrrrr]

With the plugtest server app, during OSCORE context rederivation (Appendix B.2), the server doesn't appear to handle duplicate requests from the client (same token and MID). This is an issue in low availability areas where context rederivation will need to be restarted if a response is lost. If I'm not wrong, it is expected the server can handle multiple context rederivations from replayed requests in parallel.

[boaks]

I'm not common with OSCORE.

Duplicate requests (same peer, same MID within EXCHANGE_LIFETIME) are handled according RFC 7252 4.5 Message Deduplication. With that I don't see, that there is something special to do.

@rikard-sics

Does OSCORE change that RFC 7252 4.5?

[boaks]

I got aware, that the OSCoreUdpStack puts the ObjectSecurityLayer below the ReliabilityLayer, which then prevents that from deduplicating requests in ReliabilityLayer.receiveRequest.
Not sure, what is the intended behavior or best to fix that. It may be possible, to change the order of the layer. Or to add a if (request.isDuplicate()) check to the ObjectSecurityLayer.receiveRequest.

[boaks]

I very first test showed, that exchanging the layers may work.

new BlockwiseLayer(tag, false, config, matchingStrategy),
new ObjectSecurityLayer(ctxDb),
CongestionControlLayer.newImplementation(tag, config)};

@burrrrrr

would it be possible for you to test with that approach until we get a feedback from Rikard?

[rikard-sics]

would it be possible for you to test with that approach until we get a feedback from Rikard?

Yes my spontaneous comment without checking deeper is that swapping the orders of the layers makes sense

[burrrrrr]

I very first test showed, that exchanging the layers may work.

new BlockwiseLayer(tag, false, config, matchingStrategy),
new ObjectSecurityLayer(ctxDb),
CongestionControlLayer.newImplementation(tag, config)};

@burrrrrr

would it be possible for you to test with that approach until we get a feedback from Rikard?

@rikard-sics @boaks

Great, that fixes the retransmission issue for me.

However, there is another issue in the context rederivation where the server can only handle one ongoing rederivation per sender id. This potentially may be a problem if an attacker initiates context rederivation simultaneously with a different kid context.

On line 285 of ContextRederivation, the context is only retrieved by recipient id.

        // Try to retrieve the context based on the RID only if no context was
        // found. Since the ID Context in the initial request will be a new one
        // and not match existing contexts.
        if (ctx == null) {
            ctx = db.getContext(rid);
        }

I guess this should change to query by rid and context id, which means all ongoing context rederivations need to be tracked. I could give it try. Thoughts?

[rikard-sics]

I guess this should change to query by rid and context id, which means all ongoing context rederivations need to be tracked. I could give it try. Thoughts?

Let me have a look at this and the initial issue you reported. Unfortunately I am quite busy with meetings today but tomorrow I should have some time to put on this.

[rikard-sics]

However, there is another issue in the context rederivation where the server can only handle one ongoing rederivation per sender id. This potentially may be a problem if an attacker initiates context rederivation simultaneously with a different kid context.

I had a look at the PR for swapping the layers (#2296 ) and that looks good to me. When that is merged I will next take a look at this issue with multiple simultaneous executions of OSCORE context rederivation.