Network information in protected responses through proxies

[marco-tiloca-sics]

Migrated from https://gitlab.com/crimson84/draft-tiloca-core-observe-responses-multicast/-/issues/33

Original content and comments below

================================================

How does the client (when doing OSCORE through a proxy) know that it shouldn't just join the group? After all, it might manage to.

Simple answer is that it is configured to use a proxy, and because of that does not join the group. (Or, even simpler, because it's using a different protocol).

But what if it is using a reverse proxy (of whose existence it is unaware)? Then the server could render assistance (mind you, reverse proxies do in general need explicit setup somewhere) like this:

• It sends an empty (or absent) tp_info. This prompts the client to send the observation the same way it would always (because there's no better guidance, but hey, there's now a known-good request).
• The proxy receives the phantom request as a regular unicast request, sends it by unicast, and now we're in a situation as with the deterministic client that the server can act in "Huh, OSCORE? Never heard of it" mode and respond with an unprotected 5.03 with tp_info.
• The proxy joins the group as it would in the unprotected or the deterministic case.

This has one message exchange more (two unicasts from the proxy), but allows the server to hide its network addresses / topology from clients.

This is now possible that we have a good separation between tp_info and ph_req/last_notif, and by the way this is exactly what (if deterministic-oscore still talked about how to get a ticket request) would be used for unicast ticket requests :-)