[core] Proxies and observations: "All options MUST be identical"

[Christian Amsüss]

Hello CoRE and LWIG groups,

when discussing re-registration of observations in the context of
OSCORE with Jim and the OSCORE authors, we stumbled upon the sentence
"All options MUST be identical to those in the original request except
for the set of ETag Options." about this in RFC7641.

This is something that servers, especially proxies, should not try to
enforce, because every case of a request with differing options (or
FETCH payload) could just as well be a new observation from the client
on the token whose observation cancellation got lost, or the client
simply rebooted.

I'd like to take that recommendation down somewhere (or have it
challenged before it's relied on by OSCORE). Where would that fit?
RFC7641 errata? draft-ietf-lwig-coap?

Best regards
Christian


PS. if you're interested in the context: ETag is an encrypted option in
OSCORE. Changing the ETag means re-encrypting the message, which
requires a new nonce and thus also changes the Content-Security option
-- and thus we'll allow that there. I think it's OK to do that because
the underlying rule is unenforcable anyway.

[Klaus Hartke]

The client SHOULD generate tokens in such a way that tokens currently
in use for a given source/destination endpoint pair are unique.

My hypothetical client was using the "but I already cancelled, it's not
in use any more, didn't you get the NON?" defense -- but fair point.

It's not the client alone who decides when a token is no longer in use.

Hmpf, that would mean that a correct proxy would treat an OSCORE
re-registration with new (encrypted) ETag set as a new observation. It
would determine that the old observation is over, cancel its observation
to the origin server and start a new one, presumably (under the
abovementioned) using a new token. Should work, but it's a new
observation at the origin.

Right.

A very smart proxy might even notice that rather than cancelling the
observation, it can start the new one on the same token and thus do both
cancellation and new registration in a single packet (making things
magically smoother), but that might be considered smart to the extent of
specification abusal.

If the proxy finds that the new observation request from the client is
(almost) identical to the previous observation request from the
client, then this behavior is exactly the one intended.

The proxy could also try to do it when the requests are not identical,
but this would violate the "MUST be identical" client requirement,
although it might technically work due to the "MUST replace or update
the existing" server requirement. I wouldn't assume that any proxy
does it in this case.

Do you think there is a practical way around this that is not "OSCORE
observations can never be renewed (can never have a bit different, thus
no new nonce, no new freshness and no new ETags), and to renew an OSCORE
observation you have to cancel the old one and register a new one"?

At first glance, I don't see any.

Klaus

[Carsten Bormann]

Post by Christian Amsüss
Hello CoRE and LWIG groups,
when discussing re-registration of observations in the context of
OSCORE with Jim and the OSCORE authors, we stumbled upon the sentence
"All options MUST be identical to those in the original request except
for the set of ETag Options." about this in RFC7641.

This is a requirement on the client in order to effect a re-registration of interest.

Post by Christian Amsüss
This is something that servers, especially proxies, should not try to
enforce, because every case of a request with differing options (or
FETCH payload) could just as well be a new observation from the client
on the token whose observation cancellation got lost, or the client
simply rebooted.

Right. I don’t think enforcing that all requests are re-registration requests is in the server requirements for 7641?

Grüße, Carsten