Subject: [6tisch] Review of draft-ietf-6tisch-minimal-security-06

From: Klaus Hartke <[email-masked]>
Date: Fri, 29 Jun 2018 20:21:01 +0000

I've reviewed draft-ietf-6tisch-minimal-security-06, focusing on the parts that involve CoAP.

The Stateless-Proxy option is interesting. When a CoAP client (or proxy in the role of a client) makes a request, it usually has some state information at that point in time and requires that information to continue where it left off when receiving the response. CoAP facilitates this by the Token: an opaque value that is sent along the request and echoed back verbatim in the response.

When the Token was designed in the CoRE working group, we had a discussion if the token value should just serve as an identifier for the state information stored at the client, or if the client should be enabled to encode information directly in the token, protected by an authentication tag, which would allow the client to continue where it left off without keeping any state information in the meantime. Since we didn't have a specific use case at that time, the (non-reversible) decision was made to not allow it and to limit the token value to a maximum size of 8 bytes.

The Stateless-Proxy option overturns that decision. While I think that the original decision was not the best, this is really unfortunate. Not only are there are now two tokens in a message, which doesn't help with keeping the protocol simple and easy to understand; the new token is also not even always echoed back.

I don't see why a protocol extension is needed in the first place. It seems the current functionality could be achieved equally as well by passing the state information in the payload [1].

Seeing that Tero also has some comments on statelessness, I think that this part needs more work.

The other parts involving CoAP look good to me. (The prescribed URI path "j" is a bit suspicious since it conflicts with BCP 190, but might be fine because of the "6tisch.arpa" authority.)

Klaus

[1] E.g.: JP receives request from pledge, wraps that request and state information in a new payload, makes request with that payload to JRC, receives a response from JRC, unwraps response to pledge and state information from response from JRC, sends response to pledge.