Re: [core] [Anima] ANIMA constrained-join proxy revision to use CoAP

[Esko Dijk <[e-mail]>]

The Pledge here is not using unsecured CoAP towards the Join Proxy - the Join Proxy is using unsecured CoAP towards the "Registrar-Proxy" that is situated on a specific port on the Registrar host.
So there should be no big security issues for rogue Pledges. We could of course explain in the Security Considerations section that the "Registrar-Proxy" needs to (or must) support only one CoAP resource for the Registrar-Proxy functionality and not accept requests to arbitrary other resources. Just to be complete.

Suppose that a Pledge would try to send unsecured CoAP to a Join Proxy: 
* if sent to the Join Proxy port (i.e. the DTLS port), the Join Proxy would just forward this as a data blob as usual and eventually the Registrar will try to parse the CoAP message as "DTLS" and fail.
* if sent to any other port, the Join Proxy must discard the data since it is not using the proper encryption of the (mesh) network.  The JP only has a port "open to the outside world" to relay DTLS data blobs and other ports are not open.

On the one hand if we decide to use CoAP for a particular function then we may expect implementers need to know CoAP as well and e.g. read RFC 7252. Including thinking about security issues of unsecured-CoAP. The benefit or re-use comes with that responsibility as well as the CoAP protocol is far more rich/complex than what we actually need.
But if we fear that implementers not versed in CoAP are going to mess things up, we may want to write some additional guidance. Like how to deal with the various options the client may include.

The forward/reverse proxy we tried to explain in https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-07#section-3.5  (in the context of CoAP group communication). No pictures there unfortunately.

Esko

-----Original Message-----
From: Toerless Eckert <[e-mail]> 
Sent: Tuesday, November 1, 2022 16:21
To: Michael Richardson <[e-mail]>
Cc: Esko Dijk <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP

Our proxy is an application using CoAP. In that respect it is IMHO not a bad
idea to be explicit in what options are and what options are not to be included
in the CoAP headers, and not expect that implementers should/could figure this
all out by themselves. Especially, when there are options whose inclusion and
reaction to could create a security risk.

I guess i do not understand CoAP well enough, but the wy it sounds to me,
unclusion of the Uri option would be a security risk, because it would
allow the Pledge to indicate to the constrained proxy which registrar/proxy to
connect to, right ? Which a pledge shuoldn't be able to know anyhow, but if it
was including it, it could make the proxy select a registrar proxy that it 
shouldn't use.

If we do not document this, how would an implementer be supposed to come to
the conclusion of what E.g.: Esko wrote in his reply, e.g.: that an error
would be raised (which seems what we should do).

Whats even all this terminology - forward/reverse proxy... Is there a simple
picture anyhwere in any of the RFC references explaining this ?

Thanks!
    Toerless

On Mon, Oct 31, 2022 at 03:30:09PM +0100, Michael Richardson wrote:
> Toerless Eckert <[e-mail]> wrote:
>     > Can we make sure that the text does explain why the field is not
>     > inclueded, and explain that the packet MUST be rejected if it was
>     > included ?
> 
> Why should we reject if it is included?
> 
>     > Seems like:
> 
>     > Field is not included and would cause rejection of the packet if it was
>     > present, because it is inappropriate for the initiator to choose the
>     > next hop after the proxy not only because the Pledge would not know it,
>     > but because it is also not appropriate for security purposes for the
>     > Pledge to choose it.
> 
>     > Do i correctly understand this ?
> 
> I don't think it's about the initiator choosing the next proxy.

-- 
---
[e-mail]