Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
P.S. to that, following an off-list comment: By "URI resource name", do you mean "URI path component"? "Path" seems to be the official name for what follows the host in a URI, according to RFC3986. "Resource name" is confusing because a URN is different: RFC8141. Regards Brian Carpenter On 02-Nov-22 08:58, Brian E Carpenter wrote: On 31-Oct-22 22:24, Esko Dijk wrote: cases where the Registrar would configure another resource (e.g. /j or > /join or whatever) and in such case a Uri-Path option would be needed. Okay, but I'd like to not do that :-) Okay, I see your point - let's go for the '/' resource option and see if reviewers further down the line are okay with that. I just noticed that when GRASP discovery is used (service "BRSKI_RJP") the Join Proxy only discovers IP address and port so has to make an assumption on the URI resource name being '/'. Two comments there: 1) It would be trivial to extend the definition of the BRSKI_RJP objective by giving it a meaningful value field, such as a string defining the URI resource name. Like: objective-value = text ; URI resource name 2) At the moment draft-ietf-anima-constrained-join-proxy cuts a corner in its definition of BRSKI_JP. Even if you want to save typing by citing Fig. 10 of RFC8995, you need to add an IANA Consideration formally registering the objective (like section 8.7 of RFC8995). Regards Brian If any other CoAP resource would be possible as well, then that resource name would have to be advertised in GRASP too. We could say that because our service is being discovered on a particular port (typically differing from the default CoAP port as shown in Section 5.1.1 example) we don't have the issue that we would interfere with other resources using name "/". So, no Uri-Path option is equivalent to /? Yes! It's also equivalent to the same URI without the trailing slash, which is the format we show in Section 5.1.1. Regards Esko -Original Message- From: Michael Richardson Sent: Wednesday, October 26, 2022 19:39 To: Carsten Bormann Cc: Esko Dijk ; anima@ietf.org; c...@ietf.org Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP Carsten Bormann wrote: >> I'm not 100% sure if for a resource at the root (/), one Uri-Path >> Option with 0 length is needed or if 0 Uri-Path Options can be used. >> Or if both methods would be valid. > That is a well-known idiosyncracy in the URI format. > Have a look at: https://www.rfc-editor.org/rfc/rfc7252#section-6.4 > Step 8 treats coap://foo and coap://foo/ in the same way: >If the value of the component of |url| is empty or > consists of a single slash character (U+002F SOLIDUS "/"), then move to > the next step. So, no Uri-Path option is equivalent to /? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
On 31-Oct-22 22:24, Esko Dijk wrote: cases where the Registrar would configure another resource (e.g. /j or > /join or whatever) and in such case a Uri-Path option would be needed. Okay, but I'd like to not do that :-) Okay, I see your point - let's go for the '/' resource option and see if reviewers further down the line are okay with that. I just noticed that when GRASP discovery is used (service "BRSKI_RJP") the Join Proxy only discovers IP address and port so has to make an assumption on the URI resource name being '/'. Two comments there: 1) It would be trivial to extend the definition of the BRSKI_RJP objective by giving it a meaningful value field, such as a string defining the URI resource name. Like: objective-value = text ; URI resource name 2) At the moment draft-ietf-anima-constrained-join-proxy cuts a corner in its definition of BRSKI_JP. Even if you want to save typing by citing Fig. 10 of RFC8995, you need to add an IANA Consideration formally registering the objective (like section 8.7 of RFC8995). Regards Brian If any other CoAP resource would be possible as well, then that resource name would have to be advertised in GRASP too. We could say that because our service is being discovered on a particular port (typically differing from the default CoAP port as shown in Section 5.1.1 example) we don't have the issue that we would interfere with other resources using name "/". So, no Uri-Path option is equivalent to /? Yes! It's also equivalent to the same URI without the trailing slash, which is the format we show in Section 5.1.1. Regards Esko -Original Message- From: Michael Richardson Sent: Wednesday, October 26, 2022 19:39 To: Carsten Bormann Cc: Esko Dijk ; anima@ietf.org; c...@ietf.org Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP Carsten Bormann wrote: >> I'm not 100% sure if for a resource at the root (/), one Uri-Path >> Option with 0 length is needed or if 0 Uri-Path Options can be used. >> Or if both methods would be valid. > That is a well-known idiosyncracy in the URI format. > Have a look at: https://www.rfc-editor.org/rfc/rfc7252#section-6.4 > Step 8 treats coap://foo and coap://foo/ in the same way: >If the value of the component of |url| is empty or > consists of a single slash character (U+002F SOLIDUS "/"), then move to > the next step. So, no Uri-Path option is equivalent to /? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
On Tue, Nov 01, 2022 at 05:14:23PM +, Esko Dijk wrote: > 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. Ah. Right. The pledge is out of the picture wrt to header parameter choice proxy/registrar. I was confused. So wrt to security we're unchanged from our pre-coap solution, e.g: needs to depend on ny underlying security of the mesh network, including e.g.: ACP if its an ANI thats providing registar/proxy connectivity. > 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. Right. > 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. Yes. > 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. Well, in the case of ACP (RFC8994) i was put by security AD under a good amount of discus' etc. to detail all the profile detail of TLS, DTLS and IPsec in ACP. And i for each of the protocol pieces i choose either to specify a manually defined very lightweight MTI profile to make implementation as lihtweight as possible or was referring to some pre-existing profile guidance rfc. Which i think are fairly big set of options. But i choose all of that only for the pieces i thought where "non-constrained", aka: can have a lot of TLS/... code for all the different crypto etc. So, for our CoAP/CoAPs i am quite clueless whether a) the RFCs (CoAP) we're referring to has a single MTI profile that will ensure all possible independent proxy and registrar implementations will interoperate b) That profile will allow proxies not to have more code than what you would like there to be (for CoAP/CoAPs) to be implementable only whatever you think the most lightweight proxy is that you're interested in. This is now a more generic review comment than my misguided URI comment. If we're fine on this a) and b) thats great. > 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. Don't do unreasonavble stuff for me. If the above a) and b) makes sense and is solbed by existing text, we're done on this piece i think. > 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. Ok, will check in detail. Thanks Toerless > Esko > > -Original Message- > From: Toerless Eckert > Sent: Tuesday, November 1, 2022 16:21 > To: Michael Richardson > Cc: Esko Dijk ; anima@ietf.org; c...@ietf.org > 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
Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
Toerless Eckert wrote: > 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 ? No. The CoAP that the Pledge sends is inside the DTLS. The CoAP that we are discussing is added by the Join Proxy. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
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 Sent: Tuesday, November 1, 2022 16:21 To: Michael Richardson Cc: Esko Dijk ; anima@ietf.org; c...@ietf.org 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 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
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 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
