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

[Klaus Hartke <[e-mail]>]

Christian Amsüss wrote:
>>    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