Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
> I agree, but I don't see the value in adding bytes to the wire. +1 To reduce testing effort for adopters of this solution it's best if we do not specify/allow other resources than '/'. We haven't identified yet the value of allowing other resources (only disadvantages). Esko -Original Message- From: Michael Richardson Sent: Wednesday, November 2, 2022 08:07 To: Brian E Carpenter Cc: Esko Dijk ; Carsten Bormann ; anima@ietf.org; c...@ietf.org Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP Brian E Carpenter wrote: > 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 I agree, but I don't see the value in adding bytes to the wire. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
Yes it's probably better to call it "path of the resource" or "URI path".
(Background: In CoAP implementations the term "resource name" is colloquially
used for the final URI path component. In the RFC 7252 URI composing section
it's used for the entire URI path + query components.)
Esko
-Original Message-
From: Michael Richardson
Sent: Wednesday, November 2, 2022 08:08
To: Brian E Carpenter
Cc: Esko Dijk ; Carsten Bormann ;
anima@ietf.org; c...@ietf.org
Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
{wasn't actually offlist}
Brian E Carpenter wrote:
> 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.
I give up :-) whatever.
Uri-Path is the name of the CoAP option that I would like permission to omit.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
{wasn't actually offlist}
Brian E Carpenter wrote:
> 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.
I give up :-) whatever.
Uri-Path is the name of the CoAP option that I would like permission to omit.
--
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
Brian E Carpenter wrote: > 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 I agree, but I don't see the value in adding bytes to the wire. -- 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
Esko Dijk wrote: > 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. I guess one concern might be that in a GRASP-focused ACP network, the join proxy might not otherwise speak CoAP. For instance, maybe the join-proxy is actually an ACP-multi-Gb-ethernet ISP appliance that has an 802.15.4 radio attached so that it can capture environmental reports from sensors in the data center. My two thoughts here are: a) the join-proxy can use stateful mode, which avoids any CoAP knowledge. b) the Registrar has to known CoAP anyway, but that knowledge is limited to the Registrar. So I think that we are in good hands. > 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. I think it's okay: learning a bit of CoAP is not that hard. You don't have to be an expert on it. -- 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
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 rai
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
Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
> Why should we reject if it is included? The Registrar-Proxy would typically not accept any CoAP forward-proxy request, that is, any request containing the Proxy-Uri or Proxy-Scheme Option. Instead it would return 5.05 (Proxying Not Supported) error as defined already by 7252 Section 5.7.2. It doesn't operate as a forward-proxy because we have defined it as a reverse-proxy (at least, we have done that per the latest discussion emails.) In practice a CoAP endpoint of course could operate as both forward and reverse proxy, but I don't think we have to say anything about such a situation. (RFC 7252 should cover any remaining cases and what to do in case the same CoAP endpoint is used for multiple purposes.) Esko -Original Message- From: Michael Richardson Sent: Monday, October 31, 2022 15:30 To: Toerless Eckert Cc: Esko Dijk ; anima@ietf.org; c...@ietf.org Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP 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. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
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. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
Hi Toerless, I don't think we have to explain why particular CoAP Options are not included in the request - there are many CoAP Options we don't use. And in principle we also don't need to motivate our design choices extensively in the draft. We can just define the positive example of what we do use, as written in the current text of the draft. So what we currently use is a "regular" CoAP request to the reverse-proxy (i.e. the Registrar-Proxy). I say "regular" in quotes because it is a regular request but to a resource that is a special case in CoAP Uri-Path option encoding (the root resource /). The Registrar-Proxy indeed selects the "next" destination which is the Registrar. (This often called 'next leg' or '2nd leg' in the CoRE WG.) Esko -Original Message- From: Toerless Eckert Sent: Thursday, October 27, 2022 19:58 To: Michael Richardson Cc: Esko Dijk ; anima@ietf.org; c...@ietf.org Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP 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 ? 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 ? Cheers Toerless On Wed, Oct 26, 2022 at 07:38:12PM +0200, Michael Richardson wrote: > > Esko Dijk wrote: > > Yes, the assumption is still that a CoAP request made to the root > > resource (/) is valid and can be encoded by including 0 Uri-Path > > Options. > > Well, the word from the Oct.12 meeting was that we didn't need it. > > > Since the proposed CoAP message does not contain any Uri-Path > > option, it should be directed to the root resource. There could also be > > 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 :-) > > > 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. > > I'm hoping that Carsten or Christian will express an opinion. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- 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
> > 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 '/'. 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
Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
On 2022-10-27, at 19:57, Toerless Eckert wrote: > > next hop ?? I thought we were in a thread about Uri-Path. (If this is indeed a reverse proxy, that gets to choose the paths it supports; I don’t know what paths the actual registrar would use — sorry for not following all the discussion here.) Grüße, Carsten ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
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 ? 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 ? Cheers Toerless On Wed, Oct 26, 2022 at 07:38:12PM +0200, Michael Richardson wrote: > > Esko Dijk wrote: > > Yes, the assumption is still that a CoAP request made to the root > > resource (/) is valid and can be encoded by including 0 Uri-Path > > Options. > > Well, the word from the Oct.12 meeting was that we didn't need it. > > > Since the proposed CoAP message does not contain any Uri-Path > > option, it should be directed to the root resource. There could also be > > 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 :-) > > > 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. > > I'm hoping that Carsten or Christian will express an opinion. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- 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
> On 2022-10-26, at 19:39, Michael Richardson wrote: > > So, no Uri-Path option is equivalent to /? Actually, to coap://foo and coap://foo/ For contrast, note that coap://foo? and the equivalent coap://foo/? actually have a single empty Uri-Query Option, but no Uri-Path Option. Grüße, Carsten ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
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 =- 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
Esko Dijk wrote: > Yes, the assumption is still that a CoAP request made to the root > resource (/) is valid and can be encoded by including 0 Uri-Path > Options. Well, the word from the Oct.12 meeting was that we didn't need it. > Since the proposed CoAP message does not contain any Uri-Path > option, it should be directed to the root resource. There could also be > 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 :-) > 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. I'm hoping that Carsten or Christian will express an opinion. -- 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
On 2022-10-26, at 16:57, Esko Dijk 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. (The rest of step 8 would have created the Uri-Path options.) Grüße, Carsten ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
Yes, the assumption is still that a CoAP request made to the root resource (/) is valid and can be encoded by including 0 Uri-Path Options. Since the proposed CoAP message does not contain any Uri-Path option, it should be directed to the root resource. There could also be 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. 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. Esko -Original Message- From: Michael Richardson Sent: Wednesday, October 26, 2022 16:53 To: Esko Dijk ; anima@ietf.org; c...@ietf.org Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP Esko Dijk wrote: >> The Proxy-Scheme option is set to "coap". Do I even need this? > I don't think we can use the Proxy-Scheme (or the Proxy-Uri) Option If we don't need it, then GREAT, that's six bytes we save. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP
Esko Dijk wrote: >> The Proxy-Scheme option is set to "coap". Do I even need this? > I don't think we can use the Proxy-Scheme (or the Proxy-Uri) Option If we don't need it, then GREAT, that's six bytes we save. -- 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
Hi Michael, > The Proxy-Scheme option is set to "coap". > Do I even need this? I don't think we can use the Proxy-Scheme (or the Proxy-Uri) Option here. The reason is that it is meant for a CoAP forward-proxy, that is a proxy that receives a CoAP request and creates another fresh/new CoAP request again, based on the received request payload and the included Proxy-Uri option or alternatively the included Proxy-Scheme option plus other Uri-* options. But, in our case here the proxy does not even create a new CoAP request. Rather, it takes the payload bytes only and sends these over UDP to the Registrar's DTLS port. (If the Registrar is a local process, the UDP I mention here is just local communication.) So a CoAP forward proxy seems really not appropriate and it should be a CoAP reverse proxy instead. See 5.7.3. of RFC 7252. Using a reverse proxy means you can just remove the Proxy-Scheme option. Esko -Original Message- From: core On Behalf Of Michael Richardson Sent: Monday, October 24, 2022 03:58 To: anima@ietf.org; c...@ietf.org Subject: [core] ANIMA constrained-join proxy revision to use CoAP Hi, the -13 version of draft-ietf-anima-constrained-join-proxy is posted now. Here is the diff: https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-constrained-join-proxy-12=draft-ietf-anima-constrained-join-proxy-13=--html The -13 is created from a series of pull requests which are not merged, but he parts where I change the "JPY" to a CoAP header are at: https://github.com/anima-wg/constrained-join-proxy/pull/42 Some questions to the CoAP experts. The Proxy-Scheme option is set to "coap". Do I even need this? It costs 6 bytes, I think, assuming that "coap" is a four byte string, and not code for a enumerated type. If not, I'd have no options, and the additional overhead of CoAP vs custom CBOR would be two bytes. Christian said two weeks ago that we didn't need Uri-Host or Uri-Path options. I think that we will be running on a custom port. (But, RFC9031 thought it needed them. Was that wrong?) The Registrar's DTLS stack might need to send more than one reply in response to a single DTLS "POST". This is buried in the DTLS state machine, and might be related to DTLS handshake fragmenting headers, or to rekeys, or... Is that going to be a problem, and is POST still the right method? Appendix A has some details on the CoAP header, which I'd like a review. Did I even get it halfway right? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
