RFC7959 - PUT/POST - DTLS - rules to apply for follow-up requests.

[boaks]

For single message pairs, RFC7252 9.1.1, or single request/response pairs, RFC7252 9.1.2 describes, that the DTLS context must be considered.

What is about followup request for a blockwise PUT/POST? If I didn't over read it, there is nothing defined in RFC7959 to obey. Are there any considerations, to apply the same rules for the followup request that for responses?

[mrdeep1]

I think that this is covered in the Abstract, namely

Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs.

I appreciate that multipleis used instead of single, but the same RFC7252 principles still apply to each resquest/response

[boaks]

For me, that describes the relation of req. 1 with resp. 1 and req. 2 with resp. 2. Here, 9.1.1 and 9.1.2 applies.

But I'm missing something for req. 1 with req. 2, similar to 9.1.2.

[mrdeep1]

The req.1/n andreq.2/n do not need to be in same DTLS session and epoch, but resp.1/n DTLS needs to match req.1/n and (the possibly different) resp.2/n DTLS needs to match req.2/n. This may happen if there has to be a DTLS renegotiate of some sort.

[ektrah]

The general consideration for DTLS contexts is that different contexts can have different security properties (e.g., cipher suite used, client authenticated or not). If multiple CoAP messages are linked together in some way (e.g., a response to a request), all those messages should be in the same context (or a security analysis needs to be performed to determine potential vulnerabilities resulting from different security properties or the lack of the implicit binding between messages provided by a DTLS context in general).

In the case of blockwise transfers, I could, for example, easily imagine problems if a client makes 5 blockwise PUT requests without client authentication and then the final blockwise PUT request with client authentication, and the server proceeds to handle the PUT requests as an atomic unit under the (wrong) assumption that all requests are client authenticated.

[boaks]

Yes, that was my consideration. Therefore I think, some statement similar as RFC7252 9.1.2 makes also sense for RFC7959 PUT/POST.

[sbernard31]

I don't get which behavior you decide to finally implement.

[boaks]

I don't get which behavior, you decide to finally implement.

Not sure, what your expectations are. My intention to "ping" the leshan project was to check, if adding a check for blockwise (block1) followup requests works for lwm2m, or not.

[sbernard31]

Not sure, what your expectations are.

I have no expectations, I try to understand first.

And I don't get what kind of check :

• same epoch, same session (that I understand as same connection + no renegotiation)
• or something else
• or something flexible ?

[boaks]

And I don't get what kind of check :

I guess, this question in general is still open. For Californium it's about adding a call to the endpoint context matcher.

[sbernard31]

As the rfc7959 says :

Clients SHOULD strive to send all blocks of a request without undue delay.

So this probably limits case where using another DTLS connection could be useful (like dynamic IP environment). so most of the time same connection should be enough. (Unlike observe use case)

Using the endpoint context matcher is more flexible (as user can implements their own rules), so I think it makes sense to use it to do that check.

if adding a check for blockwise (block1) followup requests works for lwm2m, or not

AFIAK, It should no cause any troubles.