Subject: [core] Stateless-Proxy option

From: Mališa Vučinić <[email-masked]>
Date: Fri, 24 Feb 2017 15:42:27 +0100

Dear Core,

As part of the work on bootstrapping in 6TiSCH working group, we are using CoAP proxying functionality to facilitate communication between a new node (pledge) and the Registrar. The pledge does not have global IPv6 connectivity at the time of the join so it communicates over link-local addresses with a potentially constrained one hop neighbor that acts as a CoAP proxy.

Note that in this scenario a constrained proxy implements forwardng-related options but does not necessarily need to implement a cache.

To relay the response back to the client, the proxy needs to keep some state, such as IPv6 address of the client, port number and at CoAP level the token. With limited memory, this opens up a constrained proxy to a potential DoS attack by unauthenticated pledges. 

One solution that we have discussed is to register a new option, Stateless-Proxy option, that could be used by a proxy to add en-route the state information needed for its operation. State information would be opaque to the server who would need to echo it back in the response.

Your feedback would be most welcome.

Regards,
Mališa Vučinić

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 24 Feb 2017 17:52:02 +0100

> One solution that we have discussed is to register a new option, Stateless-Proxy option, that could be used by a proxy to add en-route the state information needed for its operation. State informat…

This is something that was actually discussed during the development
of RFC 7252: storing actual state in the Token, which *is* state
information that is opaque to the server and echoed back in the
response. The idea was dropped, however, for security reasons (IIRC):

If the information is not only a state identifier but encodes the
state itself, then the server gains the ability to create arbitrary
state at the client (or proxy in the role of a client). While the
client/proxy may trust the server to properly process the request it
sends, this doesn't mean that the (potentially subtly compromised)
server can be trusted not to temper with the state information that it
echoes back. So there needs to be at least an authentication tag,
replay detection, etc. This might become more complicated and costly
than just storing a bit of state at the client/proxy.

Another issue that interferes with a stateless proxy is that a proxy
in general needs to keep state for each client not only to pass a
response back, but also to properly react to request retransmissions,
to (re-)transmit separate responses, to perform congestion control, to
return 5.04 timeout errors, etc. It is almost never the case that a
proxy can simply receive a message, make some stateless modifications,
and pass it on to the next hop.

If you're thinking about (accidental or deliberate) DoS attacks, then
you're on the right track. But this needs more thinking; a
Stateless-Proxy option doesn't quickly solve the problem.

Klaus

---

From: Dan García Carrillo <[email-masked]>
Date: Fri, 24 Feb 2017 22:52:02 +0100

Hi Mališa:

In our draft marin-ace-wg-coap-eap we propose the concept of CoAP relay for the bootstrapping phase. We currently have an implementation of the concept of CoAP relay. The next step we are working on is the CoAP stateless proxy. 

If you have any comments, please let us know. 
Best Regards,
Dan. 

> El 24 feb 2017, a las 15:42, Mališa Vučinić <[email-masked]> escribió:
> 
> Dear Core,
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core