[core] No-Response option and OSCORE

[Francesca Palombini]

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

[Klaus Hartke]

Hi Francesca!

Post by Francesca Palombini
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.

Post by Francesca Palombini
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.)

Post by Francesca Palombini
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.

Post by Francesca Palombini
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

[Francesca Palombini]

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)

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.

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

[Esko Dijk]

Hello Francesca, Klaus,

Post by Francesca Palombini
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?

Post by Francesca Palombini
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.

Post by Francesca Palombini
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:***@ericsson.com]
Sent: Monday, January 15, 2018 14:34
To: Klaus Hartke <***@projectcool.de>; ***@ietf.org
Cc: ***@philips.com; draft-tcs-coap-no-response-***@ietf.org
Subject: RE: No-Response option and OSCORE

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.

Post by Francesca Palombini
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)

Post by Francesca Palombini
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.

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

________________________________
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.