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 <[email protected]> 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.
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
