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 <t...@cs.fau.de> 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. -- --- t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima