Subject: [core] No-Response option and OSCORE

From: Francesca Palombini <[email-masked]>
Date: Thu, 11 Jan 2018 14:59:08 +0000

Hi all,

In order to add the processing of the No-Response in the OSCORE document, as requested by a few people, I was reading RFC7967 and previous conversations [1] in the mailing list, regarding proxies behavior when using No-Response.

RFC7967 specifies No-Response as an Unsafe-to-forward option (and therefore not part of the cache key). Because of that, proxies are allowed to legitimately discard this option. Moreover, even when the server receives this option, it might legitimately decide to respond to the request anyway.

We have three choices as of OSCORE processing: we can treat the No-Response as an unprotected only option (outer), as an encrypted only (inner), or as a both encrypted/inner (to the server) and unprotected/outer (for any intermediaries) option.

This is a question for No-Response users, such as the authors of RFC7967 and Esko:
We assume having an inner No-Response is convenient, since we are guaranteed that it reaches the server unchanged. Is this assumption correct, does your use case profits from a protected client-to-server No-Response option?

To anybody, particularly the authors of RFC7967:
We think it is necessary to send the option as an outer option too, to keep the functionality of No-Response-aware proxies. This means that we should allow inner and outer No-Response at the same time (where we recommend the outer value to be the same as the inner value). The only problem is, since No-Response is Unsafe to forward, No-Responses-unaware proxies might be waiting on the responses while the server, having received the inner No-Response might not respond. Is this a reasonable tradeoff?

Finally, I have a question non concerning OSCORE but [1] and the document in general, for the authors and for Klaus, on anyone that has an opinion. My question concerns the decision to make this option Unsafe-to-forward. In my opinion, to deal with cacheability, it would have been enough to make the option Safe-to-forward, and part of the cache-key.

In [1] Klaus said:
If a server returns a 4.04 response (or any other cacheable error
response) with Max-Age != 0, then a cache will return that response as long as Max-Age has not elapsed instead of making a request towards the origin server. So the caching of error responses protects a server a bit from clients repeatedly triggering the same error. The No-Response option destroys this protection. To limit the damage, I would say that intermediaries MUST NOT include the No-Response option in their requests.

Question: Having No-Response safe-to-forward and part of the cache key would work, since the requests would hit the cache in that case, right? Why was the option specifically defined to unsafe-to-forward? I'd like to know because if I have missed something in the proxy processing I could get the OSCORE processing wrong.

Thanks,
Francesca

[1] http://mailarchive.ietf.org/arch/msg/core/X00OZOjL8mcnyzZy6dSqlGO2LuQ

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 11 Jan 2018 16:48:00 +0100

Hi Francesca!

Francesca Palombini wrote:
> Finally, I have a question non concerning OSCORE but [1] and the document in
> general, for the authors and for Klaus, on anyone that has an opinion. My
> question concerns the decision to make this option Unsafe-to-forward. In my
> opinion, to deal with cacheability, it would have been enough to make the
> option Safe-to-forward, and part of the cache-key.
>
> [...]
>
> Question: Having No-Response safe-to-forward and part of the cache key would
> work, since the requests would hit the cache in that case, right? Why was
> the option specifically defined to unsafe-to-forward? I’d like to know
> because if I have missed something in the proxy processing I could get the
> OSCORE processing wrong.

Let's see what happens when we have a client -> proxy -> server chain
using CoAP over UDP where the proxy does not understand the
No-Response option.

If the No-Response option was safe-to-forward, then

* the client would send a request and not expect a response,
* the proxy would forward the request and expect a response,
* the server would not send a response,
* the proxy would detect the absence of a response after some timeout
and send an error response to the client.

>From the perspective of the client, this isn't very useful, because
the client didn't want a response. (Or, if the client just preferred
to not get a response, it wouldn't have hurt if the proxy had sent the
actual response instead of the error.)

>From the perspective of the proxy, the server appears to be
unavailable -- or at least heavily congested. This means the proxy
must throttle its traffic to the server, which intensifies the longer
the proxy doesn't receive anything from the server.

>From the perspective of the server, the server initially saves sending
a response, but then is basically cut off from the network because the
proxy no longer sends requests to it at a reasonable rate. So it's
really in the interest of the server to send responses to the proxy.

Making the No-Response option part of the cache-key in this scenario
would just mean that any matching request from any client will be
answered with a cached timeout error by the proxy as long as the proxy
believes that the server is unavailable.

Now, if the proxy does understand the No-Response option, things
slightly improve between the proxy and the client(s). But the
communication between the proxy and the server is still severed. So
the No-Response option is really most useful between the client (or
proxy in the client role) that doesn't a response and the next hop.

What does that mean for OSCORE?

A server (or proxy in the server role) that understands the
No-Response option should check if the *previous* hop does not want a
response. If the previous hop is a client with which the server has a
security association, then I'd say the No-Response option should be an
inner option. If the previous hop is a client (or proxy in the client
role) with which the server does not have a security association, then
I'd say the No-Response option should be an outer option, not
safe-to-forward, and not part of the cache key.

Does that make sense?

Best regards,
Klaus

---

From: Francesca Palombini <[email-masked]>
Date: Mon, 15 Jan 2018 13:34:28 +0000

Hi Klaus,

Thanks for the quick reply!

You are right, I did not consider proxies doing congestion control, when thinking about No-Response. That makes sense now, thanks.

> Now, if the proxy does understand the No-Response option, things slightly
> improve between the proxy and the client(s). But the communication
> between the proxy and the server is still severed. So the No-Response option
> is really most useful between the client (or proxy in the client role) that
> doesn't a response and the next hop.

Side question: why would the communication proxy-server be severed if the proxy understands No-Response? The proxy should not assume that the server is congested if it recognize a request including the No-Response option. I am not sure congestion control with No-Response requests make any sense (proxies cannot recognize between voluntarily non-responding and congested server)

> A server (or proxy in the server role) that understands the No-Response
> option should check if the *previous* hop does not want a response. If the
> previous hop is a client with which the server has a security association, then
> I'd say the No-Response option should be an inner option. If the previous
> hop is a client (or proxy in the client
> role) with which the server does not have a security association, then I'd say
> the No-Response option should be an outer option, not safe-to-forward, and
> not part of the cache key.
> 

I agree with your analysis. Now from a specification/implementation point of view, it is the client that has to encode the No-Response as an inner or outer option.

Considering the part I had missed about congestion control, my new proposal is: the client must set No-Response as inner and outer.
* If the proxy is No-Response unaware, it is going to drop the No-Response. The server will receive the inner No-Response, but since it will not receive the outer No-Response, it will know it is dealing with No-Response unaware proxies, and applications can decide how to deal with it. (For example, if the No-Response is used to request specific responses that are otherwise optional, as in multicast, it is not necessary that the proxy understands the No-Response but still useful that the server does and can verify its integrity)
* If the proxy is No-Response aware, the server receives both inner and outer. Normal OSCORE processing defines that the server drops the outer and uses the inner.
I think this is in accord with what you wrote above, keeps the proxy functionality and protects the option.

I am going to write a proposal in the draft, let me know if you see any red flags!

Thanks,
Francesca

---

From: Esko Dijk <[email-masked]>
Date: Mon, 15 Jan 2018 14:01:41 +0000

Hello Francesca, Klaus,

> Side question: why would the communication proxy-server be severed if the proxy understands No-Response? The proxy should not assume that the server is congested if it recognize a request including the No-Response option.

Same question I had - in what way would it be severed?

> I am not sure congestion control with No-Response requests make any sense (proxies cannot recognize between voluntarily non-responding and congested server)

For Confirmable type messages, the Proxy can still estimate congestion I think - without receiving any response.  The No-Response option with CON can be used to suppress/avoid separate responses that a server makes, or to avoid lengthy responses that the client is not interested in (replacing the lengthy response effectively by a shorter ACK message.)
When the Coap client uses NON messages, this doesn't imply that the Proxy can't use CON type messages once in a while just to estimate the congestion. The Proxy could use either CON or NON here.

> I am going to write a proposal in the draft, let me know if you see any red flags!
Sounds good; this seems the best solution.

Best regards
Esko

-----Original Message-----
From: Francesca Palombini [mailto:[email-masked]]
Sent: Monday, January 15, 2018 14:34
To: Klaus Hartke <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: No-Response option and OSCORE

Hi Klaus,

Thanks,
Francesca

________________________________
The information contained in this email may be confidential and/or legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original email.