Re: [core] No-Response option and OSCORE

[Esko Dijk <[e-mail]>]

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:[e-mail]]
Sent: Monday, January 15, 2018 14:34
To: Klaus Hartke <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
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.

> 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

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