Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy
On 03-Dec-21 07:01, Michael Richardson wrote: * While reviewing latest updates; one other issue came up: the draft (re * latest in Github) currently mentions DNS-SD as a means for a Pledge to * discover a Join Proxy. please note that this discovery occurs on the untrusted ("DULL") side. Brian E Carpenter wrote: I think there's another reason for deferring it. We have a pending proposal in draft-eckert-anima-grasp-dnssd for how DNS-SD will integrate in an autonomic environment. It seems wise to have more clarity about that before defining how DNS-SD works for a Join Proxy. The two things may be completely orthogonal, but that requires a little thought. I don't think we can assume any GRASP or DNS-SD interoperation on the untrusted side. It's just a bad idea. Yes. Probably that merits a MUST NOT in the Security Considerations of draft-eckert-anima-grasp-dnssd. Brian As for the Join Proxy discovering the Registrar, that's a different question. We defined GRASP already for that. If we have a DNS-SD method as well, then that would just be an additional method inside an ACP. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text
This email just to summarize conclusions to the list. Esko Dijk wrote: >> I don't think that we should make this extensible via IANA registry. >> Any update will mostly have to Amend this document, probably it will have to >> obsolete it. > I don't have a strong preference here. Relying on a future follow-up > document to Amend it, or Obsolete it in a responsible way, seems > fine. So we have to decide whether to keep the registry or remove it - > topic for the call today! We have concluded this morning that we would use: mcr> 3) receiver can process first five items as they are, and new items mcr> can be placed after the payload, which older receivers are told mcr> to ignore. > For using the current single-array structure, my preference is > (3). Doing (2) seems risky from an implementation perspective. In > today's Agile SW world, people don't consider tomorrow's change so much > in today's code. Because they're supposed to only consider that in > tomorrow's code. But as we know today's code isn't always maintained > anymore when tomorrow comes ;)Identifying the particular risk here > is left as an exercise to the reader. We need to write text that says that receivers should: 1) check for >= 5 items. 2) always copy all items into the reply (but update the content/payload) We discussed using instead of IP + family. (it will shortly be RFC 9164 , not in AUTH48). It would cost 1 byte more. if we don't, we concluded, for family to use: https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- 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] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy
* While reviewing latest updates; one other issue came up: the draft (re * latest in Github) currently mentions DNS-SD as a means for a Pledge to * discover a Join Proxy. please note that this discovery occurs on the untrusted ("DULL") side. Brian E Carpenter wrote: > I think there's another reason for deferring it. We have a pending proposal > in draft-eckert-anima-grasp-dnssd for how DNS-SD will integrate in an > autonomic environment. It seems wise to have more clarity about that before > defining how DNS-SD works for a Join Proxy. The two things may be > completely orthogonal, but that requires a little thought. I don't think we can assume any GRASP or DNS-SD interoperation on the untrusted side. It's just a bad idea. As for the Join Proxy discovering the Registrar, that's a different question. We defined GRASP already for that. If we have a DNS-SD method as well, then that would just be an additional method inside an ACP. -- 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] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text
> I don't think that we should make this extensible via IANA registry. > Any update will mostly have to Amend this document, probably it will have to > obsolete it. I don't have a strong preference here. Relying on a future follow-up document to Amend it, or Obsolete it in a responsible way, seems fine. So we have to decide whether to keep the registry or remove it - topic for the call today! > Of these, I have a slight preference for (2) over (3). > I don't like (1) at all. For using the current single-array structure, my preference is (3). Doing (2) seems risky from an implementation perspective. In today's Agile SW world, people don't consider tomorrow's change so much in today's code. Because they're supposed to only consider that in tomorrow's code. But as we know today's code isn't always maintained anymore when tomorrow comes ;) Identifying the particular risk here is left as an exercise to the reader. > If we really need extensibility, then I would suggest we consider instead: On your CDDL proposal: using a map here doesn't seem necessary. We need to limit the overhead of the JPY message to the absolute minimum - it may be transported over 6lowpan links, where the DTLS packet size may be near the 1280 byte limit. Then there's hardly any space to add more JPY header... If we really want a clear separation of Header and Content, which isn't the case in the current draft, then we could use 2 arrays: [ [ ip : bstr, port: int, family : int, index : int payload : bstr ], payload : bstr ] Only the embedded array (Header field) is extendible in length. Doing this approach adds only 1 byte to the JPY message size; examples: [h'FE80C0A801C8', 48551, 6, 0, h'0011'] --- 26 bytes ; what's currently specified [[h'FE80C0A801C8', 48551, 6, 0], h'0011'] --- 27 bytes ; above dual array proposal [{0:h'FE80C0A801C8', 1:48551, 2:6, 3:0}, h'0011'] --- 31 bytes ; the smallest possible 'map' approach. But I'm also ok with a single-array structure if we choose the approach (3) i.e. any extensions come *after* the payload element. Esko -Original Message- From: Anima On Behalf Of Michael Richardson Sent: Wednesday, December 1, 2021 19:32 To: anima@ietf.org Subject: Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text Esko Dijk wrote: > Good point; these are not CBOR map keys because it's not a map but an > array. But still, for an array, the indices could be managed in an IANA > registry for the JPY protocol. This allows future documents to add new > map indices to the registry. An alternative is not to create a registry > at all but just allow an RFC to update the array with 1 or more > indices. I don't have a preference for one of these solutions. Arrays are not as easily extensible as maps. Receivers can't just ignore keys that they don't know. Fortunately, it's CBOR, so things that the receiver doesn't know about can be skipped, assuming they implement enough of CBOR. {Right now, we have bstr, and int. The enclosing array can be open-coded as a test for 0x85. Or processed as an array. No map, tstr, etc. code needed} I don't think that we should make this extensible via IANA registry. Any update will mostly have to Amend this document, probably it will have to obsolete it. I don't think we can easily accomodate multiple documents asking for a code. There are three ways we can extend this array: 1) receiver can see that new array has 6+ elements, and then can assume the "new" format. That could involve completely changing the order of what is there. 2) receiver can process first four items as they are, and then process the last element as the payload. Anything between the fourth element and the payload would be ignored in this version, but future versions put new things there. 3) receiver can process first five items as they are, and new items can be placed after the payload, which older receivers are told to ignore. Of these, I have a slight preference for (2) over (3). I don't like (1) at all. Just remind other readers: [ ip : bstr, port: int, family : int, index : int payload : bstr ] If we really need extensibility, then I would suggest we consider instead: JPY_message = [ details : { ip : bstr, port: int, family : int, index : int }, payload : bstr ] {please forgive my poor CDDL here} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Constrained-join-proxy: how best to define the protocol family number in JPY header?
(@authors: this is a repeat of a private message to you, but now for on-list discussion) Here one inconsistency I found: the Appendix A example uses IP protocol family number 10 for IPv4, while Section 5.3 does not define how the family number is chosen; and Section 9.1 defines IPv4 as value 4 and IPv6 as value 6. So we need to either fix the example, or the Section 5.3 / 9.1 text. Or preferably both! There’s also the option to base the family number upon a long time existing IANA registry of protocol families: https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml In this case we would get 1=IPv4 and 2=IPv6. (Minor benefit of the existing registry is that also many other protocols as shown in the registry could potentially be used. No need to constrain it to only IPv4 and IPv6…) Best regards Esko IoTconsultancy.nl | Email/Teams: esko.d...@iotconsultancy.nl ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima