Re: [Anima] Result//Re: WGLC for draft-ietf-anima-brski-ae-04, ends April 3rd, 2023
Toerless Eckert wrote: > 2. I would suggest to move RFC7030 to normative references. This would make > it consistent with lightweight CMP references also being normative, and given > how the endpoint naming scheme is derived and meant to be backward compatible with > EST, and EST being explicitly mentioned several times in that context.. Do people implementing the CMP-AE need to know what EST is in detail? That doesn't jive with me. I think it can stay informative, but it's really a quibble. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [COSE] [Rats] cose+cbor vs cwt in MIME types
Smith, Ned wrote: >> As I mentioned before, the multiple suffixes draft might not >> land... So it would be better to avoid multiple plus >> I was following your lead from earlier in the thread. the advice I got verbally last week was to use as specific a +thing as possible. So +cwt is better than +cose+cbor, even though +cose+cbor is a superset of +cwt. (Every CWT is a COSE object) I'm not even sure that +cose+cbor ever makes sense, since +cose implies +cbor. But, +cose+gzip might make sense in some context. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [COSE] [Rats] cose+cbor vs cwt in MIME types
Laurence Lundblade wrote: > I think the main goal for EAT is to allow a general EAT handler to know > if EAT is CBOR/CWT or JSON/JWT. Either “eat+cbor” or “eat+cwt” will do > that. Probably “eat+cwt” is better because it is more specific. An EAT handler will need to process application/eat+FOO. I think that there is no dispute here. MIME media types are used for not just assertions about what something is, but also in Accept: headers to say what the requester would like to receive. The utility of the +stuff, particularly if there are multiple +stuff, is when one has a non-specific handler that would like to decode as much as possible. For instance, wireshark/tcpdump, or your favourite software IDE. I have just sent requests to media-types for +cwt and +cose to go through Expert Review. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] registration for +cose
as per RFC6838: Name: application/cose +suffix: +cose References: STD96 Encoding considerations: CBOR is always encoded as binary Interoperability considerations: None Fragment identifier considerations: N/A Security considerations: as per STD96 Contact: IETF COSE WG Author/Change controller: IESG (I was writing an ID for this, then realized that application/cose was already a thing, and that all we needed was a suffix, which is Expert Review) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [COSE] [Rats] cose+cbor vs cwt in MIME types
Esko Dijk wrote: >> So I just don't know what to do, but I think we what have done is >> wrong. > What we have now is "application/voucher-cose+cbor", which is not wrong > I think. There's currently no rule saying your media type needs to be It's not wrong, but it's not sufficiently right :-) > named in a particular way, there are options to name it. In this same > discussion thread (or parallel thread with same subject) we have > discussed that "application/voucher+cose" would also be a good name, if > we register the "+cose" suffix with IANA. My reading is that we can have +cose for the cost of an Expert Review. application/cose is already registered. My next message is about that. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [COSE] [Rats] cose+cbor vs cwt in MIME types
Esko Dijk wrote: > As you said also the following would be possible today: > application/voucher+ysid > if we register 'ysid' as being CBOR-YANG-SID that's included in a COSE > wrapper. I find this less useful than the first options of '+cbor' or > '+cose' , it seems too specific. I'm agnositc because: 1) over COAP it's a single CONTENT-FORMAT, so the size does not matter. 2) over HTTPS, it's a rich network environment, so bytes do not count. We've been told at this point that we should use as specific a format as possible. I don't think that voucher+ysig is meaningful (or accurate) for us, because we also COSE sign it, which not every YANG-SID use will do. So I just don't know what to do, but I think we what have done is wrong. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [COSE] [Rats] cose+cbor vs cwt in MIME types
Laurence Lundblade wrote: > I’m not sure identifying something as COSE, or even CWT is that useful > because there’s no standard for the key material and key identification > that cuts across all uses of COSE or CWT. Knowing that it's COSE, a dissector can know: 1) it's an array with four elements. 2) the [3] element is a signature. 3) the [0] element contains parameters 4) the [1] element is a protected hash 5) the [2] element is a bstr with cbor inside it. Of course, the 18() also tells you that :-) To know what keys, you need to know that it's EAT, and some additional context. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [COSE] [Rats] cose+cbor vs cwt in MIME types
Orie Steele wrote: > At IETF 116 this draft was discussed: > - https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes - > https://youtu.be/BrP1upACJ0c?t=1744 > TLDR; there is work in progress to define multiple suffixes, and how > they are interpreted. Right, I read through mediaman-suffixes. I got the feedback that we should use the most specific type available. >> Luckily because COSE is just "plain CBOR" itself , we can use the >> subtype '+cbor'. So having "voucher-cose+cbor" would be fine. Also I don't understand why it's not application/voucher+cose+cbor. The outer encoding is cbor, the next layer is cose. There is the a third layer which is `yang-core`. (It seems that we ought to call this "ysid"? or maybe +cst. ) +cwt is also three layers: CBOR, COSE, and then CWT claims inside the signed part. So, if we'd call it application/eat+cwt, then we ought also call it application/voucher+ysid It seems that we ought to have registered +ysid in RFC9254. Can we do it in draft-ietf-core-sid-20? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] zerotier setup
Michael Richardson wrote: > Contact me for the network ID, after installing it, you do: > pippin-[~] mcr 10015 %sudo zerotier-cli join dbCOFFEE12345678 Actually, I had only setup "pippin" in host mode, and not in L2-bridged mode for the rest of my IETF HackVPN VLAN. I have adjusted some things: a) marked the device/interface as no-auto-assign IP in the web GUI. b) setup a Linux Bridged interface that includes the device. There is some editing to /var/lib/zerotier-one/devicemap required. I haven't found a way to run a script when the zerotier device turns on, which would put it into the bridge directly. You need the above configuration if you intend to have more than one (more than the zerotier host) as part of the ACP L2 VPN. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] zerotier setup
The bad news: while zerotier supports mikrotik, and the smallest devices can even run the RouterOS 7.x, Zerotier is only supported on the ARM/ARM64 devices, and not on the MIPSBE devices that we got for EU20. The good news: a VM (or container) works too. The better news: it works with v4 or v6. 21:57:38.970142 IP6 2620:120:9002:209::40.45489 > 2605:9880:400:c3:254:f2bc:a1f7:19.9993: UDP, length 33 21:57:38.970168 IP6 2620:120:9002:209::40.45489 > 2605:9880:400:c3:254:f2bc:a1f7:19.9993: UDP, length 33 21:57:38.970179 IP6 2620:120:9002:209::40.45489 > 2605:9880:400:c3:254:f2bc:a1f7:19.9993: UDP, length 33 21:57:38.970190 IP6 2620:120:9002:209::40.45489 > 2605:9880:400:c3:254:f2bc:a1f7:19.9993: UDP, length 33 It even seems like it has difficulty deciding which to use: 21:57:39.615728 IP6 2607:f0b0:f:3::41.20410 > 2620:120:9002:209::40.45489: UDP, length 122 21:57:39.616159 IP 10.10.209.41.9993 > 209.87.249.16.20410: UDP, length 122 Contact me for the network ID, after installing it, you do: pippin-[~] mcr 10015 %sudo zerotier-cli join dbCOFFEE12345678 -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Rats] cose+cbor vs cwt in MIME types
Michael Richardson wrote: > COSE CHAIRS: can we have 5 minutes for this discussion? > I guess I can make two slides tomorrow and get Thomas to co-author them. I guess we didn't get any time at COSE. https://github.com/anima-wg/voucher/blob/main/presentations/ietf116-cose-mime-cwt.pdf ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Rats] cose+cbor vs cwt in MIME types
Smith, Ned wrote: > Does it belong with the "EAT Media Types" topic, or is it a separate topic? Well, it's not a RATS topic, it's a COSE topic. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Rats] cose+cbor vs cwt in MIME types
COSE CHAIRS: can we have 5 minutes for this discussion? I guess I can make two slides tomorrow and get Thomas to co-author them. Thomas Fossati wrote: > On 13/03/2023, 18:10, "Thomas Fossati" tho.i...@gmail.com<mailto:tho.i...@gmail.com> wrote: >> >> On Mon, Mar 13, 2023 at 5:49 PM Michael Richardson >> mcr+i...@sandelman.ca<mailto:mcr+i...@sandelman.ca> wrote: >> > Thomas Fossati thomas.foss...@arm.com<mailto:thomas.foss...@arm.com> wrote: >> > > I have commented on your respective issue trackers. >> > >> > I saw, but I think that this requires some cross-WG discussion and consensus, >> > and I think that the COSE WG should tell us what to do. >> >> Sure, thank you for bringing COSE in the loop. > I just realised this needed some follow-up from my side. > What MCR is talking about is the eat-media-type [1] draft we are doing > in RATS. The document requests registration of the +cwt structured > syntax suffix (see Section 6.1). > The idea is to use +cwt to indicate that the media type is encoded as a > CWT, symmetric to +jwt. > In our case we'd be using it in composition with application/eat to > differentiate between the JWT and CWT serialisations of EAT. > COSE is the natural stakeholders for this, so if you could have a look > and see if we are doing the right thing it'd be awesome. And, if ANIMA should also be using +CWT for what is now RFC8366bis (and used to be in the constrained-voucher document), or if our use of application/voucher-cose+cbor is wrong. (DAMN. It's not in rfc8366bis yet. It should be) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide 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-grasp-distribution-07.txt
Sheng Jiang wrote: > I actually agree your observation on the supportiveness of use case > section. We were discussing to move use cases section into > appendix. Overall, use cases here are not necessary or as a MUST. What > we should focus on is the validity of technical requirements on Section > 4. If yes, infrastructure would be used when it is ready and good > enough to be used. 1) The use cases motivate doing the work. 2) The use cases tell us something about the threat/risk/benefit of the environment, and inform the reviewer what assumptions have been made. So moving them into an appendix just makes it harder to understand what problem you are trying to solve. It also obscures that some of the use cases are not really credible. Instead, I suggest: a) pick a specific use case (firmware update?) and implement it. b) talk about that implementation, and see if any of the proposed other users are interested in the solution. Otherwise, my advice to the chairs is that there is no audience for this innovation, and we should not go through the expense/effort of publishing it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* 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-grasp-distribution-07.txt
Hi, I recalled that I'm the document shepherd for this document. I did my shepherd review a year ago on version -04, and I also did a review in 2020 when we adopted it: https://mailarchive.ietf.org/arch/msg/anima/hCv5bZxBrzSzA6BjA5DY7_RDo6U/ I am updating my shepherd review, but let me highlight some comments from January 2022 review, and my January 2020 comments that have still not been acted upon. I think that the use cases are not well supported. I can not comment on whether SBA is a reasonable use case, if it were, then I would expect a 3GPP document to cite this one. Has that occured? I do not find the INC use case credible. I can see that yes, the INC needs data backup and data aggregation, but I don't see why they would do that via the ACP. I can see that perhaps there is an ASA that would run over an ACP that would provision where computing is supposed to go, but the actual movement of the data seems to belong in the production network. Then the data might move by rsync, etc. I don't find the V2X communications use credible either. This is because I don't think V2X will deploy an ACP, or for that matter *can* deploy such a thing as it would cross the boundaries of authorities. The thing that I **do** find credible is software updates, particularly within Enterprises and ISPs for their core switching equipment, but also for IoT devices that might be connected at the edge of the switching network. The firmware updates can be transfered across a high-speed network to the edge where slow/sleepy IoT devices can pick them up via one-hop communications. I did not find the Smart Home use case credible. Amazon, Google and Apple have invested in CSA/MATTER, and it has it's own communication fabric. That spec does not cite this spec, so I don't see how this helps. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] cose+cbor vs cwt in MIME types
Thomas Fossati wrote: > I have commented on your respective issue trackers. I saw, but I think that this requires some cross-WG discussion and consensus, and I think that the COSE WG should tell us what to do. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* 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-grasp-distribution-07.txt
Has anyone implemented for any of the use cases given in section 3? -- 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] ANIMA@IETF116: Call for agenda items
Hi, topics that I guess I'm the hook for: 1) rfc8366bis: summary of the wrapping up of YANG [3 min + 10 min questions] 2) plans for interop testing going forward from IETF116 [5min] 3) masa and registrar considerations documents [5 minutes each] -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [lamps] lamps(/anima): another struggle related to CSR attr, draft-ietf-lamps-rfc7030-csrattrs-01 and draft-ietf-anima-brski-prm
Salz, Rich wrote: > I don't think that the IETF hasn't defined any CA/Registrar protocols, > other than the BRSKI drafts. I'm curious about what part of RFC8995 makes you think that there is a CA/Registrar protocol included... we would have liked to do this, but we haven't. > It "used to be" that almost every CA that wanted to issue certificates > for enterprise customers had its own variety of Registrar > integration. You couldn't walk down any of the aisles of the RSA > conference and not bump into one. They were all custom, private. A > subset had protocols or API's that let you plug your enterprise > identity system (e.g., ActiveDirectory) into their provisioning > system. I don't know if that kind of thing is still popular. Yes, that's my experience as well. That's why getting all the right stuff into the CSR is so important. > As for your earlier question, could a certificate end up having things > that weren't in the CSR? Yes. Often or always. The obvious ones are > issuer, validity period; sometimes keyUsage and extendedKeyUsage, the and often policy OIDs and SCTs and ... It's often this bloat that becomes really annoying when running protocols on challenged networks. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] [Cbor] CDDL Model for YANG-SID (draft-ietf-core-sid)
Carsten Bormann wrote: > On 2023-02-25, at 23:21, Carsten Bormann wrote: >> >> Examples don’t validate. > Patchup script included. > (But errata not yet submitted.) > https://www.ietf.org/archive/id/draft-bormann-cbor-rfc-cddl-models-01.html#name-rfc-8366 Thank you... but the YANG still went through your brain, not a tool :-) So, I'm still concerned that the content might be wrong in some way that deceives our brains. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Cbor] [core] CDDL Model for YANG-SID (draft-ietf-core-sid)
Carsten Bormann wrote:
> On 2023-02-25, at 22:52, Carsten Bormann wrote:
>>
>>> RFC8366.
>>
>> Good idea. Let’s see when I get to it…
> Examples don’t validate.
Yes, I know that the base64 isn't valid. I guess we should have made it
valid base64, even if it was nonsense inside. Putting ten lines of base64
signature in the example in the middle of the text seemed distracting to
readers.
>>> Base64.strict_encode64(Base64.decode64("base64encodedvalue=="))
> => "base64encodedvaluQ==“
> Grüße, Carsten
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] CDDL Model for YANG-SID (draft-ietf-core-sid)
Carsten Bormann wrote: > draft-ietf-core-sid defines a file format for the interchange of > YANG-SID allocation information. > This is a JSON file, a data model for which is provided in YANG (via > RFC7951 YANG-JSON). > The spec of course also contains an example instance of such a file, > which is directly useful as the SID allocation for the ietf-system YANG > module. > However, it appears that the YANG ecosystem currently does not provide > a way to mechanically validate that instance against the YANG model. Yes... I was told to use yanglint, but it's not actually capable of parsing all the new fangled things. > I find this rather unsettling. Me too. I'm not yet convinced that the examples in **RFC8366** even validate correctly, which makes it hard for me to know if 8366bis is actually correct. > Since we just did a global change (to fix our incorrect representation > of uint64 in YANG-JSON), I wanted to make sure the SID file is not > broken. I will probably be on the hook to fix sid.py to round trip the revised content, so anyone who wants to unicast me and tell me if there is some magic python that makes it do the right thing, I would appreciate it. > So I translated the YANG model into CDDL (and, yes, the example instance does validate, phew). Even without any kind of top-level wrapper dict? I see you added: "ietf-sid-file:sid-file": which pyang *does* insert or parse, and I suspected that it was wrong not to. I think you did this manually, right? > While I was at it, I remembered that there are a few other RFCs (or > soon-to-be-RFCs) that would benefit from having CDDL models handy. > So I wrote an I-D [1] that presents a number of such models, including the SID-file model. > [1]: https://www.ietf.org/archive/id/draft-bormann-cbor-rfc-cddl-models-00.html 2.4. Your favorite RFC here... RFC8366. Not seeing a venu for your draft. The thing is, once it gets translated to CDDL, I'm actually not sure I want to keep the YANG anymore. A huge huge huge amount of effort on our part, for almost zero benefit. We didn't really have CDDL 8 years ago, so we had no clear alternative when we started, but I sure wouldn't go down the YANG path again. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] WGLC comments on brski-cloud, and Re: I-D Action: draft-ietf-anima-rfc8366bis-06.txt
I have merged in the YANG extensions that were done in BRSKI-CLOUD, which I had missed before. You can see it in the diff: > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-rfc8366bis-06 Only, you can't, because the YANG didn't process correctly! Let's see, okay: https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-rfc8366bis-07=draft-ietf-anima-rfc8366bis-05 The pull request to remove the YANG from brski-cloud is at: https://github.com/anima-wg/brski-cloud/pull/23 The pull request to remove the YANG from constrained-voucher is at: https://github.com/anima-wg/constrained-voucher/pull/262 The pull request to remove the YANG from brski-ai is at: https://github.com/anima-wg/anima-brski-prm/pull/78 It might be better to allow the WGLCs to proceed and *then* move the YANG as being less confusing to reviewers. It might also be better to change rfc8366bis from a document that obsoletes RFC8366, to one that just Updates (Amends) the RFC8366's YANG, and has no other text. -- 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] changes for CORE-SID and SX:structure in draft-ietf-anima-rfc8366bis-04 and -05
Fries, Steffen wrote: > looks fine from a BRSKI-PRM perspective. The parameters defined are > contained. While BRSKI-PRM does not specify further values, I was > thinking if equivalent values for the constraint case for - > agent-provided-proximity-registrar-cert: for constraint also > agent-provided-proximity-registrar-pubk and > agent-provided-proximity-registrar-pubk-sha256 - agent-sign-cert: for Esko, should we? -- 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] WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023
Sheng Jiang wrote: > I do not prefer the "all-covered" model. As you stated, all has to be > "known" for now. What if another unknown requirement appeared？ Another > bis, BRSKI v3? I think it is better that rfc8366bis covers an > extensible generic framework and rules for future extensions. So, the > future requirements and their mechanism can be developed independently > without update BRSKI fundamental specification. It would be better to make it extensible, but augment does not amend existing modules, it extends them to make new modules. If another requirement arrives, we have to do another revision. That argues for making rfc8366bis not replace RFC8366, but just amend the YANG module. These are questions I've been posting about for months now. You'll see how the YANG is isolated in other submissions, such as: draft-ietf-opsawg-service-assurance-architecture draft-ietf-opsawg-service-assurance-yang 8366 doesn't have a lot of explanation actually, outside of the YANG module. -- 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] WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023
(Sheng's new email puts html in both the text/html and the text/plain parts) >>>>> "SJ" == MichaelRichardson writes: SJ> In general, I don't have preference whether this document of SJ> rfc8366bis defines YANG components. The major differency would be SJ> rfc8366bis would depend on the brski-prm document. That could means SJ> rfc8366bis could not be published as RFC until brshi-prm published. This is not a *preference* question, it's a quesiton of YANG mechanisms. What we were doing was NOT going to work, and I feel that we avoided a major issue by catching this now. Andy has weighed in to both tell us we don't have to do it this way, and also to say that we do have to do that. I conclude that we have not had enough review from sufficiently invested YANG experts. -- 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] WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023
Fries, Steffen wrote: > Just to chime in here, my understanding was that we collect all known > requirements for vouchers in RFC8366bis hoping that we covered all to > avoid increasing complexity during augmentation of the voucher. It's not about complexity. It's about it actually just being wrong. None of us are really generating code from the YANG, so we aren't seeing the failures. -- 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] WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023
Sheng Jiang wrote: > This message starts the two-week (*) ANIMA Working Group Last Call to > advance draft-ietf-anima-brski-prm-06, which specifies enhancements to > BRSKI (RFC8995) to facilitate bootstrapping in domains featuring no or > only time limited connectivity between apledge and the domain Hi, please be aware that the YANG components of this will be moved to rfc8366bis. They are already in the rfc8366bis-05, but I don't yet feel that we have *WG* Consensus to do this. Toerless has asked me to regurgitate the entire discussion, again, which I think that I won't do. > If you do not feel this document should advance, please state > your reasons why So, as much as I'd like it to advance, I don't think it can advance until we agree what to do with the YANG. -- 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] New Version Notification for draft-ietf-anima-rfc8366bis-05.txt
Michael Richardson wrote: > I see that I still have RFC8792 wrapping in the voucher-request YANG, while I > did fix that for the voucher YANG. I did patches for pyang to sort the SID values everywhere, but I don't consitently use that version pyang, so the values didn't get sorted. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] New Version Notification for draft-ietf-anima-rfc8366bis-05.txt
internet-dra...@ietf.org wrote:
> Html:
https://www.ietf.org/archive/id/draft-ietf-anima-rfc8366bis-05.html
> Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-rfc8366bis-05
Hi, Toerless asked for a clear Changes since RFC8366 section.
I've added that as section 5, and I would sure appreciate review comments at:
https://github.com/anima-wg/voucher/pull/22
I asked Toerless for a WG Consensus Call on this approach to dealing with the
problems that augment has gotten us into.
There are threads in the archives on what the challenge is.
We are looking for technical objections to this pull request and this approach.
In addition to the section 5, I have replaced "bootstrapping" with
"onboarding", and adjusted some of the other introductory text to include
more of the other documents.
I resisted the urge to describe {{PRM}} as "SneakerNet", since I was afraid
to find a definition for that.
I have been unable to use yanglint verify the example JSON that RFC8366
defined. It tells me it does not match I get no further details. I felt
that I should first establish this before believing it about the YANG
provided in this document. I see this as a critical thing for the document,
but not for merging this pull request.
(I redid Table 1 in kramdown, but I don't know how/if I can make a cell
span multiple columns, so for now, I haven't)
I see that I still have RFC8792 wrapping in the voucher-request YANG, while I
did fix that for the voucher YANG.
5. Changes since RFC8366
[RFC8366] was published in 2018 during the development of [BRSKI],
[ZERO-TOUCH] and other work-in-progress efforts. Since then the
industry has matured significantly, and the in-the-field activity
which this document supports has become known as _onboarding_ rather
than _bootstrapping_.
The focus of [BRSKI] was onboarding of ISP and Enterprise owned wired
routing and switching equipment, with IoT devices being a less
important aspect. [ZERO-TOUCH] has focused upon onboarding of CPE
equipment like cable modems and other larger IoT devices, again with
smaller IoT devices being of less import.
Since [BRSKI] was published there is now a mature effort to do
application-level onboarding of constrained IoT devices defined by
The Thread and Fairhair (now OCF) consortia. The [cBRSKI] document
has defined a version of [BRSKI] that is useable over constrained
802.15.4 networks using CoAP and DTLS, while
[I-D.selander-ace-ake-authz] provides for using CoAP and EDHOC on
even more constrained devices with very constrained networks.
[PRM] has created a new methodology for onboarding that does not
depend upon a synchronous connection between the Pledge and the
Registrar. This mechanism uses a mobile Registrar Agent that works
to collect and transfer signed artifacts via physical travel from one
network to another.
Both [cBRSKI] and [PRM] require extensions to the Voucher Request and
the resulting Voucher. The new attribtes are required to carry the
additional attributes and describe the extended semantics. In
addition [cBRSKI] uses the serialization mechanism described in
[YANGCBOR] to produce significantly more compact artifacts.
When the process to define [cBRSKI] and [PRM] was started, there was
a belief that the appropriate process was to use the [RFC8040]
_augment_ mechanism to further extend both the voucher request
[BRSKI] and voucher [RFC8366] artifacts. However, [PRM] needs to
extend an enumerated type with additional values and _augment_ can
not do this, so that was initially the impetus for this document.
An attempt was then made to determine what would happen if one wanted
to have a constrained version of the [PRM] voucher artifact. The
result was invalid YANG, with multiple definitions of the core
attributes from the [RFC8366] voucher artifact. After some
discussion, it was determined that the _augment_ mechanism did not
work, nor did it work better when [RFC8040] yang-data was replaced
with the [RFC8971] structure mechanisms.
After significant discussion the decision was made to simply roll all
of the needed extensions up into this document as "RFC8366bis".
This document therefore represents a merge of YANG definitions from
[RFC8366], the voucher-request from [BRSKI], and then extensions to
each of these from [cBRSKI] and [PRM]. There are some difficulties
with this approach: this document does not attempt to establish
rigorous semantic definitions for how some attributes are to be used,
referring normatively instead to the other relevant documents.
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
[Anima] changes for CORE-SID and SX:structure in draft-ietf-anima-rfc8366bis-04 and -05
Did I post this already? I have just posted -04, which includes some, but not all, of the BRSKI-PRM changes. I missed the assertion changes in -04, but they are in -05. -04: In fixing the SID allocations to be consistent (and fixing pyang/sid.py to always dump .sid files and list output in SID order. The augment mechanism results in a change the leaf path for the voucher-request, from: /ietf-voucher-request-constrained:voucher/nonce to: /ietf-voucher-request:voucher/voucher/nonce The change from request-constrained to request is anticipated, and I think acceptable. (This affects the JSON serialization) But, the additional of an extra "voucher" in the path concerns me. I tried "augment-structure" as described in RFC 8791, but pyang didn't like it. I tried to hack on things with yanglint, but I think it doesn't work. rfc8366bis-05: * I've also fixed the wrapping in the description so there are no rfc8792 wrapped lines. (Kudos to kramdown: it doesn't tell you about 8792 if it doesn't use them) * Table 1 is now down up in markdown format. I'm not sure how to make cells span rows. I would appreciate someone else to verify the new table 1 against RFC8366's version. https://github.com/anima-wg/voucher/pull/22/files I'm not going to merge this PR until I get some additional review on the differences, and the overall approach to the YANG. **I AM ASKING FOR A WG CHAIR CONSENSUS CALL** -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [netmod] 答复: CORE-SID and SX:structure and draft-ietf-anima-rfc8366bis-01.txt
Andy Bierman wrote: >> Fengchong (frank) wrote: >> > Hi Michael, >> > You can use augment-structure to extend a yang structure. >> >> You can't use augment-structure to extend in-place an existing yang >> structure >> Augment-structure produces a new structure with a new name that has been >> extended. > No. It just adds nodes to the specified parent, the same as a regular > augment. I think that you are mixing up my terminology, which is probably my fault: from https://mailarchive.ietf.org/arch/msg/yang-doctors/rsstdJegAaDPIhHdgXNfCwOCwgo/ From: Andy Bierman > But, I think that sx:augment-structure, if done by "B", and then done in a > different document by "C" would result in duplicate data nodes if "D" were > to > import both. There is nothing in YANG that does what you want, which (I think) is to add schema nodes to the module A namespace from module B. signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] CORE-SID and SX:structure and draft-ietf-anima-rfc8366bis-03.txt
Michael Richardson wrote:
> * I will merge in the changes to ietf-voucher and ietf-voucher-request
from
> draft-ietf-anima-constrained-voucher. At which point, the document title
> will *really really* be wrong, since it won't even contain the voucher,
> just constrained-BRSKI. But, we fixed the title awhile ago.
> I propose to do this in -03, so one can see a clear progression of
changes.
I have merged the changes into to the -03 draft, which has just been posted.
(I hope that these baby steps are useful to people)
One thing that we could include at this point is a created-on/expired-on
(and last-renewal-date) encoded as an integer seconds since epoch.
(CBOR Tag 1)
YANG might look like:
leaf created-on-epoch {
type uint64;
mandatory false;
description
"A value in seconds since EPOCH (CBOR Tag 1) indicating
the date this voucher was created. This leaf replaces
created-on, and one of the two MUST be present.
This node is primarily for human consumption and auditing. ";
}
leaf expires-on-epoch {
type uint64;
must 'not(../expires-on)';
description
"A value in seconds since EPOCH (CBOR Tag 1) indicating
when this voucher expires. This leaf replaces expires-on.";
}
leaf last-renewal-date-epoch {
type uint64;
must '../expires-on';
description
"The date (in seconds since EPOCH) that the MASA projects
to be the last date it will renew a voucher on. This
field is merely informative; it is not processed by pledges.";
}
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] 答复: [netmod] CORE-SID and SX:structure and draft-ietf-anima-rfc8366bis-01.txt
Fengchong (frank) wrote: > Hi Michael, > You can use augment-structure to extend a yang structure. You can't use augment-structure to extend in-place an existing yang structure Augment-structure produces a new structure with a new name that has been extended. Perhaps you'd like to go back in the archives and read my postings, and try out the pyang scripts labelled A/B/C/D. Perhaps you have some insight that makes this process unneeded, and if so, great. > TL;DR> we can not use augment to get the behaviour that we want of being to > extend existing YANG modules with new attributes. We have to revise > 8366 each time we want extend things. This email details the work to > make that occur. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] CORE-SID and SX:structure and draft-ietf-anima-rfc8366bis-01.txt
Michael Richardson wrote: >> A diff from the previous version is available at: >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-rfc8366bis-01 > * I have revised the ietf-voucher YANG module to use sx:structure (RFC8971) > rather than YANG-DATA (RFC8040). I seem to have missed doing this for > voucher-request, which I'll fix in the next revision. If you wish to see the diffs on the source side, and comment on them, they are at: https://github.com/anima-wg/voucher/pull/22 I don't merge this until I get some agreement to my emails and diffs. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] CORE-SID and SX:structure and draft-ietf-anima-rfc8366bis-01.txt
TL;DR> we can not use augment to get the behaviour that we want of being to extend existing YANG modules with new attributes. We have to revise 8366 each time we want extend things. This email details the work to make that occur. internet-dra...@ietf.org wrote: > Title : A Voucher Artifact for Bootstrapping Protocols > Authors : Kent Watsen > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-rfc8366bis-01 * I have revised the ietf-voucher YANG module to use sx:structure (RFC8971) rather than YANG-DATA (RFC8040). I seem to have missed doing this for voucher-request, which I'll fix in the next revision. * I have worked on pyang so that it will produce SID values for the sx:structure extension. The pull request is at: https://github.com/mbj4668/pyang/pull/839 As I suspected, it was about five lines of changes. I have some test cases for pyang for this, but I'm struggling to get pyang's "make test" to finish period. * It seems that the assignment of SID values between YANG-DATA and sx:structure is consistent, which is really good. * As discussed at some of the design team meetings, and I think at IETF115, I have merged into the rfc8366bis the ietf-voucher-request content from RFC8995. * yes, there seem to be duplicate SID values for ietf-voucher-request, and I'll sort that out, now that I notice I didn't update it to sx:structure. That will be -02. * I will merge in the changes to ietf-voucher and ietf-voucher-request from draft-ietf-anima-constrained-voucher. At which point, the document title will *really really* be wrong, since it won't even contain the voucher, just constrained-BRSKI. But, we fixed the title awhile ago. I propose to do this in -03, so one can see a clear progression of changes. * I will merge in the changes from PRM in -04. * Since we have to revise rfc8366bis whenever we want to extend or amend the YANG module, there seems to be no point in having the iana-voucher-assertion-type submodule. I propose to remove that, and just leave it all as a flat enumeration. * I don't think we can attempt to get to Internet Standard with this document. There will be, I think, too many changes which have not gone through interoperability tests. Perhaps in two years, this could occur via IESG Action. * The document will need a significant re-edit, and I would ask everyone to please read it with the view to: what should we omit, or just reference RFC8366, and what do we need to revise given the additional pieces that are being merged in. One thought is that we change our mind about making this a Obsoletes, and go back to making this document an Updates:, but I am still stting on the fence for this. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] how should join proxy react to multiple registrars
Brian E Carpenter wrote:
> M_FLOOD includes a TTL.
> "The message MUST contain a time-to-live (ttl) for the validity of the
> contents, given as a positive integer value in milliseconds. There is
> no default; zero indicates an indefinite lifetime."
Sure, so after that time, throw away the announcement.
So the list empties itself without a problem.
> In any case, floods must be ignored after their TTL expires, obviously.
> I see that RFC 8995 specifies the TTL as 18 ms.
> So there's also:
> 5. Pick the one with the longest remaining TTL.
> That should be about the same as #1, but maybe not quite, if we ever
> decided to vary the TTL in future.
Yes, okay, I'll take variation.
We can throw out announcements that don't work, I think.
Let's say one gets a Port Unreachable or No Route to Host.
> Are there any protocol or standard implications? I don't think so, but I
> wanted to check.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
[Anima] how should join proxy react to multiple registrars
I've opened ticket: https://github.com/anima-wg/constrained-voucher/issues/260 Assume that a Join Proxy is receiving GRASP M_FLOOD messages on it's uplink (ACP) side. What should it do when it receives announcements from multiple Registrars (distinct v6 locators). Where does it connect to? The choices are: 1. pick most recent announcement 2. pick the one to which a reply was most recently received (or TCP connected successfully) 3. pick one at random 4. pick one in a round-robin fashion If a packet is forwarded to a Registrar, and it does not reply within ?-seconds, does it then drop that registrar from the list (or put it at the back of the list) if it has others? Do any of these choices have implications for security, resilience or deterministic identification of errors? Remember that the pledge can't see any of this. Assume that all announcements are legitimate, but perhaps not all Registrars always function perfectly. It seems that 3. pick one at random either results in random failures, or it results in some probability that a good registrar will get picked on the next try, and the onboarding will occur (resiliency). 4. also guarantees that a new connection is chosen each time. 1 and 2 favour devices which are more active. Round-robin seems the easiest to implement, is deterministic (which is good for unit tests), and allows the load to be distributed easily. Are there any protocol or standard implications? I don't think so, but I wanted to check. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
Esko Dijk wrote: > The worry I have here is that by the time we get to the document update > people may not be around anymore to remember why the 'SHOULD' ought to > be a 'MUST' and then the wrong change will be made. okay. Rob Wilton (rwilton) wrote: > If the errata is "Hold for Doc Update" then the RFC editor won't > automatically apply the diff. I'm pretty sure that is only ever done > for verified errata. so, let's mark it this way for now. > There are also notes that can go along with the errata to give further > information (e.g., what the proposed long-term resolution is) if that > is helpful. If have consensus for the next text, then I think the RFC-editor site can do the patch process, though, when we mark it as verified. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
Esko Dijk wrote: > The proposed text still needs some work here; I would urge the WG not > to accept this in current form. That said, using normative language in > this specific part certainly helps to clarify the requirements for > implementers. So, I agree, but "Hold for document update" means that we can, effectively update it when we update the document. Yes, the rfc-editor can/will perform XML substitution for the errata process, and so we should care a bit about the text proposed, but my take is that it's better than what we had, and we can tweak this at our leisure. But... feel free to wordsmith! > idevid-issuer: The Issuer value from the pledge IDevID certificate > SHOULD BE included to ensure unique interpretation of the serial- > number. > In the case of a nonceless (offline) voucher-request, an > appropriate value MUST be configured from the same out-of-band > source as the serial-number. Yes, it SHOULD be, "SHOULD be" ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
RFC Errata System wrote: > The following errata report has been submitted for RFC8995, > "Bootstrapping Remote Secure Key Infrastructure (BRSKI)". > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7263 > -- > Type: Technical > Reported by: Rufus Buschart Agreed. Please mark as hold for document update. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-prm-05
Martin Björklund wrote: >> This is important to know, as the intention with the augmentation was >> to extend the voucher with additional values as you did in the example >> above. > Ok. Just to be clear; this is not what is defined today. In order to > get this, 8366bis would have to use sx:structure, and then an 8995bis > would have to use sx:augment-structure. But, I think that sx:augment-structure, if done by "B", and then done in a different document by "C" would result in duplicate data nodes if "D" were to import both. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-prm-05
Martin Björklund wrote:
>> And then Module D wishes to inherit from B and C :-)
> "inherit from" is quite generic; I would need to see a detailed
> example of the definitions you envision in B, C and D to give
> guidelines.
Yes, you are right.
>> In practical terms, this would be a constrained version of PRM.
>> (combining draft-ietf-anima-constrained-voucher +
draft-ietf-anima-brski-prm)
>>
>> > But if the intention is to add leafs to the *existing* structure
defined in RFC
>> > 8366 ("voucher-artifact"), then this approach doesn't work.
>>
>> We do this today in RFC8995 with augment.
> No, 8995 defines a *new* structure; it doens't add to the existing
> one.
Yes, I recognized this in the shower the other day.
We used augment to create a new structure, (with a new set of SID values,
btw), the voucher-request.
But, in PRM ("B") we want to extend the existing structures with new items, but
use
the same SID values.
Ditton in Constrained-Voucher ("C").
When we get around to doing Constrained PRM ("D"), then we would like the items
from "B" and from "C".
> (Note that this is hypothetical; it is not possible to do this with
> the current RFC 8366, since it uses rc:yang-data).
Understood.
> So it all depends on what you want to do with the instance documents -
> are they supposed to be "locked down" by explicit strcutures in
> different RFCs, or do the RFCs define pieces of structures that can be
> combined by implementations?
Not so much by implementations, but by derived RFCs.
>> We want to go this way, but we want to be sure we are really doing it
wrong.
>> Do you have an opinion about whether there is just a bug in pyang's
SID.py?
>> Or is there something else missing in the YANG?
> Yes this is missing in pyang. I have asked the authors of the sid
> plugin to have a look at this.
I have also filed and fixed bugs in sid.py, but before I do that, I just want to
make sure that the YANG is sane, otherwise, I might be doing the wrong thing.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] FW: New Liaison Statement, "LS on the initiation of the new work item Y.AN-Arch-fw: "Architecture Framework for Autonomous Networks""
Rob Wilton \(rwilton\) wrote:
> ITU-T Working Party 1/13 would like to inform you about the initiation
> of the new work item "Architecture Framework for Autonomous Networks"
> at its last meeting, Geneva, 25 November 2022. The new work item will
> be progressed within Question 20/13 ("Networks beyond IMT-2020 and
> machine learning: Requirements and architecture").
> This document derives from the deliverable of the Focus Group on
> Autonomous Networks (FG-AN) established under ITU-T SG13 in December
> 2020. The document describes requirements, architecture, components and
> related sequence diagrams which together comprises an architecture
> framework for autonomous networks. The architectural framework for
> autonomous networks is based on the key concepts of exploratory
> evolution, real-time responsive online experimentation and dynamic
> adaptation.
What document, does "this document" refer to?
I can't really comment on this without knowing what documents I'm supposed to
read.
> SG13-LS37
>
https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2022-12-02-itu-t-sg-13-ietf-ls-on-the-initiation-of-the-new-work-item-yan-arch-fw-architecture-framework-for-autonomous-networks-attachment-1.docx
An editable version of the same email. I don't understand why people do
this.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Yangdoctors early review of draft-ietf-anima-brski-prm-05
Thank you very much for the review.
Martin Björklund via Datatracker wrote:
> From a YANG perspective, this module is quite simple and looks good. The
only
> thing you should change is to use sx:structure (from RFC 8791) instead of
> rc:yang-data.
yes, but we need to do this across the entire set of documents.
We have an RFC8366bis in progress anyway, so the timing is right.
> However, you wrote in the request for the review "we would want to use
this
> document as the spearhead for resolving our issue of augmenting rfc8366
YANG".
> I have read the thread on the netmod mailing list, but I am not sure I
> understand the problem correctly. In the ML thread, there was the
example of
> two independent modules that augmented RFC8366:
> module B adds some leafs to RFC8366
> module C adds some leafs to RFC8366
And then Module D wishes to inherit from B and C :-)
In practical terms, this would be a constrained version of PRM.
(combining draft-ietf-anima-constrained-voucher + draft-ietf-anima-brski-prm)
> But if the intention is to add leafs to the *existing* structure defined
in RFC
> 8366 ("voucher-artifact"), then this approach doesn't work.
We do this today in RFC8995 with augment.
> If this is the
> intention, the base structure needs to be defined with sx:structure, and
B and
> C would have to use sx:augment-structure to add their leafs. This
approach
> would e.g. allow an implementation to instantiate a "voucher-artifact"
> structure with leaves from *both* B and C, even though they are
independent
> modules.
We want to go this way, but we want to be sure we are really doing it wrong.
Do you have an opinion about whether there is just a bug in pyang's SID.py?
Or is there something else missing in the YANG?
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [netmod] mcr's YANG question raised during the ANIMA WG session
Carsten Bormann wrote: > On 2022-11-24, at 17:02, Jan Lindblad (jlindbla) > wrote: >> >> If any of this causes problems with SID generation, I'm afraid that's >> not my territory. :-) > I think it would be good if there were sx:structure support in PYANG > that we can use. (Which still may not be your territory…) I see two possibilities: a) there is a genuine bug in the sid module for pyang. b) there is some missing/wrong YANG, and if I just tweaked something, it would work. I'd really like to eliminate (b) before I go on a bug hunt. There are some additional concerns. 1. do all the modules that inherit from module-A use module-A's SID file and allocation space? Or, do they need their own SID allocation for extensions that they do, with the understanding that they may also use any of module-A's values? In which case, an implementation actually needs access to multiple SID definition files. 2. a module SID number is allocated as the outer wrapper. I think that module B,C,D, etc. should all use their number for the outer wrapper. 3. in some cases not illustrated in this test, we have, under "augment", refined the rules for some leaves. It's not clear to me that we can do this using sx:structure, and I think that augment-structure has the same failings as "augment" had. I would very much like to have a wider discussion of this. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [netmod] mcr's YANG question raised during the ANIMA WG session
Jan Lindblad (jlindbla) wrote: >> I have taken a third pass at getting the extension of yang modules >> done. > Sorry for my slow response. I had a look at your latest version now, > and I think it looks good from a general YANG pov. so, this business of each module defining stuff, and then using it, rather than augmenting an existing module is the right way/ >> This time, I am using RFC8791 (Structure), rather than YANG-DATA. I >> do not use Augment (or structure-augment). Not sure how I would. > Yes, if what you want is to describe protocol messages, sx:structure > would be a good way to package this. We are describing data at rest, not protocol messages. >> This is not great, but better than before. > What aspect of this solution do you consider less than optimal? That's > not quite obvious to me. Well, it's incompatible with what we did in RFC8366 / RFC8995. So, we have to revise both, I think. > If any of this causes problems with SID generation, I'm afraid that's > not my territory. :-) I'm not convinced that we have actually created any leaves, only definitions. That is, it feels like the definitions are templates rather than definite. >> The results are still at: >> >> https://github.com/mcr/yang-augment-test look at module-?3.yang and >> practice3.sh. > Thanks for putting this in concrete and easily accessible form, i.e. as > compilable YANG modules on github. Glad it helped, if I could have presented it better, let me know. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] how to process RFC8791 examples
wrote: > You should run it with "--tree-print-structures". Thanks. That makes sense. I admit that much of my pyang use is cargo culted from one draft to another. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] sids not allocated for sx_structure/RFC8791.
Hi, if you haven't seen my thread on how ANIMA can do extensions for YANG modules, then please go read: https://mailarchive.ietf.org/arch/msg/netmod/1z7qo_6kZ0aTZmXeU4ELuwt-Rxo/ Maybe I've found a solution at the YANG level, but at the SID level, it's worse. a) No SID values get allocated to any leaves. b) A module SID value for B,C,D are created, and the old ones removed, which is wrong. c) New SID files are being created, despite having specified the --sid-update-file. This is probably not a bug in the ietf-core-sid specification, or in the RFC9254 that we published, but in the PYANG tool. However: https://github.com/mbj4668/pyang/issues/716 there was some confusion, but it seems that SIDs were generated for groupings. I don't know if I need to re-introduce deeper groupings, I don't think so. I have opened: https://github.com/mbj4668/pyang/issues/835 -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [netmod] mcr's YANG question raised during the ANIMA WG session
I have taken a third pass at getting the extension of yang modules done.
This time, I am using RFC8791 (Structure), rather than YANG-DATA.
I do not use Augment (or structure-augment). Not sure how I would.
My module D, which wants to inherit from A, B and C, even though B and C also
inherit from A, looks like this:
sx:structure module-D-things {
uses module-D;
}
grouping module-D {
description "A module D structure";
container module-D {
description "A wrapper container for the module-D things";
uses vA3:module-A-contents;
uses vB3:module-B-contents;
uses vC3:module-C-contents;
uses module-D-contents;
}
}
grouping module-D-contents {
leaf attribute-D-Delta {
type binary;
description "DeltaThree";
}
}
This produces a tree printout of:
module: module-D3
grouping module-D:
+-- module-D
+-- attribute-A-Alpha? binary
+-- attribute-B-Beta?binary
+-- attribute-C-Gamma? binary
+-- attribute-D-Delta? binary
grouping module-D-contents:
+-- attribute-D-Delta? binary
This is not great, but better than before.
The results are still at:
https://github.com/mcr/yang-augment-test
look at module-?3.yang and practice3.sh.
Please tell me/us (ANIMA WG) if we can do better.
We have revisions to RFC8366 that we'd like to go forward with, but we need
to make sure that we accomodate the extensions that are planned.
Probably converting to RFC8791 is also a good thing.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
[Anima] how to process RFC8791 examples
Hi, I've been looking at how to move RFC8366 from YANG-DATA/RFC8040 to RFC8791. I think that maybe we can solve the multiple inclusion/derivation problem in 8791 space rather than 8040 space. I extracted the A.1. "structure" Example to a file and ran: pyang --path=.../yang/modules/ietf -f tree --tree-print-groupings example-module.yang and I get nothing out, because that example module doesn't actually express something, just defines a structure. At least, that's what I think. Maybe I'm doing it wrong. I look back at what I did with draft-ietf-core-sid, and actually I don't see any clear difference. So how do I get the tree structure printed from the examples in RFC8791? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Opsdir last call review of draft-ietf-anima-constrained-join-proxy-09
Jürgen, you did a great review back in April. We recently made a bunch of revisions to constrained-join-proxy. In the end, we have replaced our custom "JPY" encapsulations with a CoAP header. The cost in the end is two bytes, and the result is that it is identical to RFC9031. We have also changed the MTI. There is a diff in the DT, and I wonder if you'd take a look at that and give us your 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] [netmod] mcr's YANG question raised during the ANIMA WG session
Hi, I completed two examples, one using the augment method that we were
using, which you pointed out was broken. Thank you for helping with this,
and I hope you have a moment to review my test files... probably there is a
*third* way that works better.
What we want is to be able to write extensions in different RFCs, and then be
able to compose them together easily.
And yes, I get errors:
MODULE D
module-D2.yang:14: warning: imported module "module-A" not used
module-D2.yang:37: error: the 'yang-data' extension must have exactly one child
that is a container
module-D2.yang:39: error: there is already a child node to "module-D2-artifact"
at module-D2.yang:37 with the name "module-A-things" defined at
module-D2.yang:39 (at module-A.yang:30)
module-D2.yang:47: error: node module-D2::module-B2-things is not found
module-D2.yang:55: error: there is already a child node to "module-D2-grouping"
at module-D2.yang:42 with the name "module-A-things" defined at
module-D2.yang:45 (at module-A.yang:30)
module-D2.yang:56: error: node module-D2::module-C2-things is not found
My first example (D1) created new grouping, which I import separately, but do
not augment.
But, the results has quite a bit of unwanted "structure":
MODULE D
module: module-D1
grouping module-D1-grouping:
+-- module-D1-things
+-- module-A-things
| +-- attribute-A-Alpha? binary
+-- module-B-things
| +-- module-A-things
| | +-- attribute-A-Alpha? binary
| +-- attribute-B-Alpha? binary
+-- module-C1-things
| +-- module-A-things
| | +-- attribute-A-Alpha? binary
| +-- attribute-C1-Gamma? binary
+-- attribute-D-Delta? binary
Maybe there is a way to fix this to be saner.
It's all in a git repo, https://github.com/mcr/yang-augment-test
The file "practice1.sh" uses the method with multiple uses, which I think it
was has been recommended, but looks weird above:
grouping module-D1-grouping {
description "Grouping for module D1";
container module-D1-things {
uses vA:module-A-grouping;
uses vB:module-B-grouping;
uses vC1:module-C1-grouping;
leaf attribute-D-Delta {
type binary;
description "Delta";
}
}
}
The file practice2.sh uses the old method we were using with augment, which
does *not* work.
--
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] [netmod] mcr's YANG question raised during the ANIMA WG session
To follow up finally.
To recap: we have been doing A:grouping-A, B:grouping-B-augment-group-A, and
now are facing
C:grouping-C-augment-group-B, which seems to be wrong.
We start with RFC8366's YANG for voucher.
It is augmented in RFC8995 to create voucher-request.
What I am hearing is that we did it wrong in RFC8995.
grouping voucher-request-grouping {
description
"Grouping to allow reuse/extensions in future work.";
uses vch:voucher-artifact-grouping {
refine "voucher/created-on" {
...
}
augment "voucher" {
description
"Adds leaf nodes appropriate for requesting vouchers.";
leaf prior-signed-voucher-request {...};
}
}
What I think you are saying is that we should have done:
grouping voucher-request-grouping {
description
"Grouping to allow reuse/extensions in future work.";
augment "voucher" {
description
"Adds leaf nodes appropriate for requesting vouchers.";
leaf prior-signed-voucher-request {..}
}
uses vch:voucher-artifact-grouping;
uses voucher-request-grouping;
Then other uses could just add the the groupings that they need.
I'm trying this now.
--
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] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022
Toerless Eckert wrote: >> Your 868 system might be unable to complete onboarding, or maybe it will take >> an hour. > I have to admit i do not even managed to figure out the nominal bitrate best case > for he 969 Mhz system ;-) But also the ZWave "Interview" (the system i am using in the > USA) is taking several minutes. I can't say this is a good user experience, so i am > all for finding best compromise - but challenging. Goran, Malisa and I have a document: draft-selander-ace-ake-authz-05 which aims to do onboarding in 3 round trips of 802.15.4 packets. >> Yes. But, let's not boil the ocean. >> It's a PS. We need to finish it so that we can deploy it so that we can >> learn. Perfect is the enemy of good enough. > Sure. I just wold love to see us not loosing the insight we're getting here... > wiki / github - where would you think we could best collect them better than > here in email ? Here in email, and in an agenda item for a future IETF. Some working groups have a "freezer" draft. -- 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] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022
Toerless Eckert wrote: > On Wed, Oct 12, 2022 at 07:49:06AM +, Esko Dijk wrote: >> For the stateless proxy, it is hard to determine a good rate limit number. 1% is not good because it would slow down the joining process of a genuine Pledge to a crawl. Some strategies that could work better: > What is the typical lowest-bitrate that you are worried about, > and what is the total amount of data of an enrolment process ? Onboarding with a certificate takes around ~3kbytes of data, particularly DTLS overhead. > How would you deal with proxies that are on frequencies where the duty cycle > is limited by law. For example devices on my 868 home automation network needs to maintain > a 1%/hour duty cycle. "by law" or by regulation or by protocol? Your 868 system might be unable to complete onboarding, or maybe it will take an hour. > The problem to me seems that under those regulations, badly behaving nodes > can force proxy and registrar into exhausting their regulatory limit as > well unless either proxy and/or registar do something against that. Yes, that's true, and why we want to be able to switch onboarding on/off. > It almost feels as if radio networks where there are strict duty-cycle > limits are requring per-pledge state on the proxy if the proxy wants to > defend itself against the attacking pledge exhausting the proxies own > duty-cycle. Unless the proxy function itself stricly operates > independent of pledge on a cycle that is below the overal permitted > duty-cycle for the proxy. Yes, if one has ram and power, a stateful proxy can do a better job of defending the network against attacks. A mains-powered PLC gateway between power and 802.15.4 could/should do exactly that. (Mind: I saw PLC systems that do Gb/s at networkX two weeks ago...) > Proxy operations as described in this document are not necessarily sufficient > to protect proxy and/or registrar against misbehaving pledges that attack > proxy/registar with too much data, especially when using (radio) networks > with regulatory limitations on the volume permitted per sender (such as > 1% duty-cycle per hour limitatios). Yes. But, let's not boil the ocean. It's a PS. We need to finish it so that we can deploy it so that we can learn. Perfect is the enemy of good enough. -- 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
[Anima] constrained-join-proxy registration of BRSKI_JP
https://github.com/anima-wg/constrained-join-proxy/pull/44
## GRASP Discovery Registry
IANA is asked to extend the registration of the "AN\_join\_registrar" (without
quotes) in the "GRASP Objective Names" table in the Grasp Parameter registry.
This document should also be cited for the objective values "BRSKI_RJP" defined
in {{graspregistrardiscovery}}.
(I don't know why we had to write "without quotes", but we and IANA did)
--
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
{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
[Anima] constrained-join-proxy registration of BRSKI_JP
Brian E Carpenter wrote:
> 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).
Hi... I can easily think that something got lost as we moved where we were
registering things around. I think you speaking about section 5.1.2:
["AN_join_registrar", 4, 255, "BRSKI_JP"],
[O_IPv6_LOCATOR,
h'fda379a6f6ee02006401', IPPROTO_UDP, 5684],
This was actually defined "first" at:
https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-18.html#name-grasp-discovery-2
So, I think that the complaint should be about constrained-voucher now.
I agree that there is no IANA Considerations in this document about BRSKI_JP.
I'm not sure what exactly to do.
https://www.rfc-editor.org/rfc/rfc8995.html#name-grasp-objective-names
registered the AN_join_registrar, and we did not, AFAIK, specify how
objective values would be registered.
I guess that constrained-voucher needs to ask IANA to add a pointer to
constrained-voucher! (And constrained-join-proxy in next email)
https://github.com/anima-wg/constrained-voucher/pull/238/files
## GRASP Discovery Registry
IANA is asked to extend the registration of the "AN\_Proxy" (without quotes) in
the "GRASP Objective Names" table in the Grasp Parameter registry.
This document should also be cited for the new protocol value UDP defined in
{{grasppledgediscovery}}.
IANA is asked to extend the registration of the "AN\_join\_registrar" (without
quotes) in the "GRASP Objective Names" table in the Grasp Parameter registry.
This document should also be cited for the objective values "BRSKI_JP" defined
in {{graspregistrardiscovery}}.
--
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
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
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
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
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
[Anima] 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 =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Example where CoAP is used as relay protocol for Join Proxy
Esko Dijk wrote: > Per the ANIMA/CoRE/IOTops call discussion today, I’m sending the > pointers to Thread documents and OpenThread source code where CoAP is > used as the relay protocol (outer layer) of a “Join Proxy” entity. > There’s a Thread white paper here: > https://www.threadgroup.org/Portals/0/documents/support/CommissioningWhitePaper_658_2.pdf > that mentions the “Joiner Router” function which is similar to Join > Proxy. It’s unfortunately somewhat out of date, but can be useful to > understand the context. Thank you. For IPR reasons, I have avoided reading the source code. I have the white paper open, but I haven't finished reading it, and likely won't before the ID deadline. -- 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] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022 / 6.1.1. Discovery example fix?
Esko Dijk wrote: --> For completeness the server should also respond with the BRSKI root resource, which matches the filter. So: > RES: 2.05 Content > ;rt=brski.rjp, > ;rt=brski, okay. > The motivation why to do this particular query is not so clear in the > document. I assume the following was intended: > 1. JP wanting to find out if stateful JP is supported in this network: > it can send this (without the asterisk) > REQ: GET /.well-known/core?rt=brski > 2. JP wanting to find out if stateless JP is supported: > REQ: GET /.well-known/core?rt=brski.rjp > 3. JP wanting to find out both in a single query: > REQ: GET /.well-known/core?rt=brski* Yes, sounds reasonable. > In case 1 and 3 the JP may be looking for "rt=brski" in the > response. Hence, in our example the rt=brski resource must be > present. Otherwise, no interoperability. > Note that the JP won't care about the details of the /rv, /vs, /es > resources. It just needs Registrar address and port. Agreed. -- ] 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[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022
Esko Dijk wrote: > For the stateless proxy, it is hard to determine a good rate limit > number. 1% is not good because it would slow down the joining process > of a genuine Pledge to a crawl. Some strategies that could work better: > 1. Initially allow a (near) unlimited use of "uplink" bandwidth, to get > a fast enrollment in the common case. When the relayed traffic persists > for some time (either by same Pledge or other Pledge, no difference) > apply a stricter rate limit. Well, you've described a 1% limit with a longer integration time :-) > 2. Apply a (rough) 'data budget' for upstream traffic to the > Registrar. Only if sufficient "downstream" traffic comes back from the > Registrar to Pledge(s), the upstream data is allowed at a high rate. If > that's not the case, a strict rate limit is applied. This is a kind of token bucket system where the downstream traffic fills the bucket. > 3. Send the radio frames associated to relayed "upstream" traffic with > the lowest priority. I.e. have a scheduler with packet priority. I > know e.g. OpenThread has this to prioritize mesh management-traffic. Yes, as does 6tisch. I think that this is probably the simplest, because it requires the least state. > A combination of approaches is also possible. > Solution 3 seems easiest to implement, if the mesh network stack > already has a working priority-based scheduler. But it will probably > need to be combined with some rate-limit approach too. :-) > Proxy SHOULD locally schedule the "upstream" IP packets to be sent with > lowest priority. And Proxy SHOULD apply a rate limit to "upstream" > data volume to be approximately equal to the "downstream" data volume > (all that's coming back from the Registrar). It seems that you have some suggested text. > Yes, the key part here is that when a Proxy once discovers a Registrar > it cannot assume that this Registrar will be alive on that IP address > forever. So it needs to rediscover in case the original discovery > information expired. If rediscovery fails, it will not forward traffic > anymore to the old IP address. GRASP makes this timeout pretty clear. mDNS does too, I think. It's just CoAP RD that has the problem, I think. -- 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] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022
Toerless Eckert wrote: > For the stateful proxy, the pull request from my review i sent last friday suggests the > following text: > To protect itself and the Registrar against malfunctioning Pledges > and or denial of service attacks, the join proxy SHOULD limit the > number of simultaneous mapping states for each IP_p%IF to 2 and the > number of simultaneous mapping states per interface to 10. When > mapping state can not be built, the proxy SHOULD return an ICMP error > (1), "Destination Port Unreachable" message with code (1), > "Communication with destination administratively prohibited". I've adapted this text and inserted it into the ed-review-comments branch. > Do you think these are useful numbers ? They seem reasonable. > from the proxy and only have it on the registrar. The best DoS protection i could > think of on the proxy is therefore just a total packet rate limiter. Is > it possible I agree, that limiting total packets/bytes that can be (ab)used is the best way. This may mean that attackers can keep legimate pleges from joining, but if we knew who was legitimate a-priori, we wouldn't need to do this at all. > to come up with good recommendations on such packet rate limiters ? For example > 1% of the "uplink" bitrate ? Can you think of mesh networks where this would not > be a good enough number ? If this (or another number) makes sense we could suggest > to add it to the stateless proxy section. In RFC9031, we used used DSCP to mark upward join traffic as distinct, in order to avoid having 6tisch think it was legitimate traffic and allocate additional bandwidth for it. A different DSCP marks downward traffic, because if the Registrar considers it worth responding, then the response really needs to get there. > I can already see a BRSKI scenario in the USA, where the manager of the > east-coast NOC went home at 5PM and some IT folks on the west coast > still want enroll new equipment in an installation and wonder what > happens. I can see the same thing. I think that this is a layer 8 issue. What we need is to be able to more clearly signal it. https://datatracker.ietf.org/doc/draft-ietf-roll-enrollment-priority/ is about this kind of control being expressed down to the leafs. But, turning the Registrar on/off also helps. > Instead of stopping service announcements (registrar and proxy), i > would then love to see the service > announcements witth some "service status" flag/field. For example "off > hours" or the like. Workflow: > Device to be enrolled has single color LED. You connect it (west coast) > to the network, and it would indicate "off hours" through eg.: > repeating three short blinks. This validates that network connectivity > works, and that enrolment will proceed once someone switches "BRSKI on" > (next morning). > Does that make sense ? yes, it does. How do you signal the device in an authentic way that can't be spoofed? It seems that you have to actually do the onboarding process (including voucher return) in order to establish trust, and then you can say, "off hours", which certainly doesn't help the DoS problem. That's one reason why EST/RFC7030 has this 202 status process. The enrollment that started at 5:06pm on Friday is waiting for a human to come in on Monday morning and click the "ok" box. -- 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] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022
een them. The term
doc> "installation IP_address" refers to an address out of the set of
doc> addresses which are routable over the whole installation network.
ED> both terms are never used again in the document. So suggest to remove
ED> this text - it is not needed.
I agree.
ED> 5.3.1
ED> any kind of of per session
-> typo 'of of'
ED> 6.1.1
ED> The coaps+jpy scheme is registered is defined
-> is registered and defined ?
ED> 6.1.2
ED> Figure 6: Example of Registrar announcing two services
-> isn't it 3 services here? 3 ports are advertised.
ED> 9.2
ED> The text contains "{{stateless-jpy}}" which should be a section
reference.
I think I got all of these.
ED> 13.1
ED> [RFC9032] is not a normative reference as far as I can see. It is
ED> only mentioned in 6.3.2 and this says that 6tisch is not even using
ED> the present protocol.
fixed.
--
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] Call for agenda items/attendance ANIMA @ IETF 115 / agenda request constrained-voucher
Esko Dijk wrote: > Name of Presenter(s): Esko Dijk Length of time requested: 10-15 > mins Draft: draft-ietf-anima-constrained-voucher > Practical question: besides slides I could also show a live software > demo; is that okay to do via the MeetEcho screen sharing function? I suggest that you record a demo/screencast to youtube and share link. That avoids much of the demo-effect, and avoids the time pressure. Not that there is also a happy-hack hour on Monday as part of the hackathon. -- 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] KIRA – A Scalable ID-based Routing Architecture for Control Planes
I'm interested in this as well, but it might be better to have a separate virtual interim with ROLL, ANIMA people invited, and fewer conflicts. -- 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] Call for agenda items/attendance ANIMA @ IETF 115
I need ten minutes to talk about the current resolution for join-proxy of the "jpy" situation. There are probably other updates that I need to do, but that is the one occupying my time right now. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [IANA #1229125] expert review for draft-ietf-anima-constrained-join-proxy (core-parameters)
Amanda, Carsten, Rob, based upon the discussion this week, we will still need brski.jp. We will also still need brski.rjp, but the latter will be different in its description. I think that it's best to just defer the IANA actions until the document is revised. Rob, I think that the document will need to return to the ANIMA WG for yet another WGLC on the changes... I've never had this situation where a document gets passed by the IESG, but fails at IANA Expert Review? I'm sure it's happened before. I anticipate working on the revisions at the end of next week. I will post a summary to the ANIMA (and CORE) ML later tonight to explain the discussion on Wednesday. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] ace-ake-auth updates for latest EDHOC principles
The authors of draft-selander-ace-ake-auth have been discussing how to update
this draft to reflect some of the changes in EDHOC. Specifically, there is a
concern that ace-ake-auth reveals too much in message_1, things which EDHOC
has worked hard to keep private.
For those that don't know ace-ake-auth, it fits into the "Ultra-constrained"
onboarding column for the diagram that was part of
https://datatracker.ietf.org/doc/html/draft-richardson-enrollment-roadmap-03
(and was in the IoT-Dir wiki, which needs to be resurrected. The diagram is
also visible at:
https://github.com/anima-wg/enrollment-roadmap/blob/master/technology-components.svg
)
The ACE connection is that the backend (aka "BRSKI-MASA" protocol equivalent)
was leveraged against the ACE mechanism. There is now some reconsideration
here. Fundamentally, it would be nice to know where the document adoption is
going so that we'd know where to have public discussions about the trade-offs.
(please note reply-to)
The location of the MASA (aka "W" in the document) is provided in the clear
during message_1, with the actual device serial number encrypted to W using a
static DH key that the pledge ("U") has been provisioned with.
It would be nice to move some of this from message_1 to message_3, which
would guard better against on-path attacks that impersonate V. The URL
provided during message_1 is visible to any observers, and since this is
onboarding, any network privacy is not yet applicable.
OTH, the authorization step needs to complete before message_2 can properly
be formed, as it contains enough of the RFC8366 constrained-voucher semantics
that it allows the pledge (U) to authenticate V.
Knowing the identity of the MASA may tell you a lot about the device in
question. This is a place where having many MASA outsourced to a big MASA
helps with privacy. It's also a place where perhaps oblivious-HTTP might
help.
There is a question about what the security policy of W is.
Is it TOFU-ish, aka promiscious MASA, or does *it* know which device has been
sold to whom?
Also, the URL for the MASA is ideally very very short :-)
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022
Okay, thank you. I'll crunch through your comments on Friday. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Review of ANIMA BRSKI-AE draft
Hi, I've finished reading BRSKI-AE. I made a pull request https://github.com/anima-wg/anima-brski-ae/pull/25 with six small suggested wording changes, two of which are aasvg hacks. I wanted Alternative Environment (and Asynchronous Enrollment) to bold or underline the A and E in the HTML/PDF, but it seems that I don't really know how to do that. I settled for *A*, which seems to result in italic, which is really not what I expected. I numbered the arcs in figure 3 because Request/Response repeats confused the pattern matcher in my brain. https://github.com/anima-wg/anima-brski-ae/issues/24 which alternatives does this document actually standardize? I think that we should merge sections 4.3 and 4.4, and just say that we are extending for CMP, and leave the rest to fend for themselves. https://github.com/anima-wg/anima-brski-ae/issues/23 CA Certs request does not seem to fit BRSKI or PRM I think that the figure 3 time sequence diagram is inconsisten with BRSKI's choice of which operation to do when (but that might be okay), but it is also may be inconsistent with PRM's needs. As I wrote in issue #22, about the nice SVG that is impossible to include, we need to figure out what are the essential pieces, and then maybe make two or three smaller diagrams that would work. -- 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
[Anima] comments on anima-brski-prm
Hi, I've done a top-to-bottom review of draft-ietf-anima-brski-prm. While I'm an author on the document, I haven't kept up on every change as Steffen and Thomas have taken lead. I should remind people that git hates trailing whitespace, and please configure your editors to remove. I use emacs, and I have some code I use, but most editors now have an option. So some diffs you may see are just trailing space removal, which I guess I could have done on main/master. I made a whole bunch of small editorial fixes, which I collected at: https://github.com/anima-wg/anima-brski-prm/pull/76 (I didn't make all those changes on the 18th, there was a rebase in the middle) You may find that the rich diff at: https://github.com/anima-wg/anima-brski-prm/pull/76/files?short_path=39089b2#diff-39089b29400b74ce53b0f9b46cc0e8c08434b3518372da2bb356646768a1d56e provides for easier review. In many cases I just split up long paragraphs into more digestable parts. ** If it would help discussion for me to split these up into a bunch of separate ** pull requests, I can do that. I tweaked many of the diagrams so that aasvg would produce beautiful HTML/PDF. I also opened the following issues: https://github.com/anima-wg/anima-brski-prm/issues/75: misuse of mDNS https://github.com/anima-wg/anima-brski-prm/issues/74: what is the threat for registrar-agent mis-use https://github.com/anima-wg/anima-brski-prm/issues/73: pledge-status responses are cumullative right? https://github.com/anima-wg/anima-brski-prm/issues/72: section 5.5 is foreshadowed/repeated https://github.com/anima-wg/anima-brski-prm/issues/71: more tweaks need for ts diagram https://github.com/anima-wg/anima-brski-prm/issues/70:why is certificate optional in section 5.5? two trivial questions I want to bring up here. https://github.com/anima-wg/anima-brski-prm/issues/67: shorten the pledge end points in constrained-voucher, we wind up shortening all the end-points, so I wonder if we shouldn't just shorten the ones used in PRM *now* so that they can work with CoAP over BTLE, when we get to that stage? https://github.com/anima-wg/anima-brski-prm/issues/66: reference to registrar as LDevID(Reg) The Registrar certificate is referred to as LDevID(Reg), and I'm not entirely sure why.Yes, it could and probably should be issued by the Enterprise CA, but I don't think it has to be. It's just the Registrar Certificate. It actually should have the cmcRA EKU set, so it's not just an ordinary LDevID. Am I missing something here? Hope to talk to you all on Tuesday evening. -- 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] discovery of Registrar by stateless Join-Proxy (was Re: [core] Join-proxy information in the RD (Re: CoRE WG Virtual Interim 2022-09-14))
Christian Amsüss wrote: >> It's not unidirectional! I'm not able to parse "semi-" here, but I >> suspect that is what you are trying to get at. > What I meant was "duplex, but one side can only reply to traffic > initiated by the other"; I think we're in agreement here. There are situations in DTLS where more than one "reply" packet has to be sent by the server, or where it needs to initiate an interaction. But, you are right that the tunnel can only be initiated via the pledge. >> > Given that this only works locally (if it were run > separately, >> that separte entity would need to keep state, whereas the >> >> I'm not sure what you mean, "only works locally" Do you mean it only >> works on the localhost, on the link-local, or in the local >> (autonomous) network? > What I meant by "working locally" was that the UDP endpoint that is the > server in the JPY protocol typically resides on the same host as the > one UDP endpoint that server in CoAPS -- in figures 2 and 3, this is > the case by both being IP_R:something. yes, you are right: the mechanism is easiest to implement inside of the Registrar itself, as it an put the extra state into the DTLS context. But, it could also be done with a stateful join proxy :-) >> The join-proxy is the thing looking for this resource, not the >> (pledge) end node. The pledge can tunnel a RD through the COAPS to >> get a list of things. > Outside of all the .jp and .rjp proxy addresses, can you give an > example of the concrete resources the pledge would want to discover > at/through the join proxy? In section 6.2.1 it discovers transport, but > I suppose at a later step it will want to discover a path for a > concrete resources (dunno, maybe an rt=brski.es or brski.rv), where > would it currently learn that? > These lines might be a good starting point to work out a more concrete > example with a `;jpy-port=...` option. I think that this is in the other thread now. -- 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
[Anima] discovery of Join-Proxy/Registrar by pledge (was Re: [core] Join-proxy information in the RD (Re: CoRE WG Virtual Interim 2022-09-14))
Christian Amsüss wrote: > * Similarly, the query for ?rt=brski.jp returns a resource, when it is > actually asking for a transport endpoint. Moreover, there *are* > resources available that the pledge likely will need to discover (any > of the brski.rv/vs/es). Before I can make any good statements or > suggesions here, how is it currenlty envisioned that the pledge will > find these resources? This is an interesting situation. I actually think that we've probably got this wrong! We should not ever do rt=brski.jp. We should be doing instead rt=brski*, as you say, because it's the rv/vs/es that we really are looking for. So it should look like: REQ: GET coap://[FF02::FD]/.well-known/core?rt=brski* RES: 2.05 Content ;rt=brski.rv;ct=836, ;rt=brski.vs;ct="50 60", ;rt=brski.es;ct="50 60", It would be nice if we could get back: ;ct=287 as well, but I don't know how/if we can ask for rt=est* as well as rt=brski* in a single operation. This is in section 6.1.1 of the -12. Maybe we just don't need brski.jp *AT ALL* The Join Proxy should answer as if it was the Registrar, with coaps: at the front. -- 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
[Anima] discovery of Registrar by stateless Join-Proxy (was Re: [core] Join-proxy information in the RD (Re: CoRE WG Virtual Interim 2022-09-14))
Hi, I've added anima@ietf.org, and removed some of the direct CC's, because I know those people are on the MLs. I will also reply a few times with the intention of splitting up the discussion into better threads. Christian Amsüss wrote: > There are some aspects about both rt= that make me concerned: > * ;rt=brski.rjp > This indicates that there is a resource at the given URI that can be > interacted with in some way described by this resource type. But while > there may be also a resource there (in particular, the `/` resource of > the forward target), that's not what this line is making a statement > about. This line is making a statement about the transport endpoint > associated with the URI (which is a bit of a hack but does not disturb > the semantics of the remaining URI metadata ecosystem; at [1] I'm > developing terminology for that). I agree that it's awkward. > At the minimum, I think this should use a dedicated target attribute > rather than the rt=, as Resource Type semantics are (in all their I don't have a problem with changing rt= to something else completely. > * Only partially related, the whole coaps+jpy scheme (which looks to me > really more like a generic semi-unidirectional UDP tunnel than anything > CoAP related) might not need registration at all. It's not unidirectional! I'm not able to parse "semi-" here, but I suspect that is what you are trying to get at. > The relevant metadatum which is transported in this (AIU) is that for > some UDP port (eg. [2001:db8:0:abcd::52]:5684), there is an additional > UDP port (currently advertised as > `;rt=brski.rjp`) that has > equivalent destination semantics but does all the state-keeping and > unwrapping. Yes, that's totally correct. In practice, we can do whatever smells the least. Our goal is simply to have a pure-RD mechanism for networks that want CoAP and do not want GRASP or mDNS. > Given that this only works locally (if it were run > separately, that separte entity would need to keep state, whereas the I'm not sure what you mean, "only works locally" Do you mean it only works on the localhost, on the link-local, or in the local (autonomous) network? Yes, the Join Proxy probably has a ULA, and I expect the reply will be a ULA, but there is nothing in the protocol that constrains that. Yes, I use the GUA documentation prefix in the examples. (I actually started to write a draft in 6man creating a documentation prefix in ULA-R space) > local service can take shortcus and only keep state after DTLS got > established), might it not be a better option to just advertise that > the CoAPS port has a an additional way in, say, > `;jpy-port=7634` (abbreviated as > `;jpy-port=7634`)? We looked at ways which would allow us to insert the state information into the DTLS framing, like we can when CoAP is on the outside, but that couldn't be done in a way that didn't violate the crypto context of DTLS. > There is a downside compared to the current approach -- the > `?rt=brski*` does not offer all relevant information any more. > However, the registrar may still offer the `;jpy-port=7634` the line > even when it does not match the filters, given that query filtering is > generally optional, or offer it on any of the brski.* lines reported. Yes, that's true. The join-proxy is the thing looking for this resource, not the (pledge) end node. The pledge can tunnel a RD through the COAPS to get a list of things. > * In unrelated comments, I find it odd that the JP MUST implement both > and the registrar only SHOULD do stateless. I can well imagine a JP I think that we changed this at least, I want to. > I think that "JP may implement either, JR MUST support both" would be > better.. I did put that into my presentation for 114. It's possible we didn't implement that conclusion into the ID. -- 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] ACP RPL profile and dynamics
Hendrik Mahrt wrote: > I'm not quite sure how the type of media or its capability to broadcast > interacts with RPL parent selection. The way I understand ACP, IPsec > tunnels are established with all link neighbors of the same ACP domain. Yes. In a busy L2 broadcast domain, establishing an IPsec tunnel with every neighbour is probably excessive. A device should accept many incoming connections, as there might not be any other device willing to talk to it, but I think initiating more than about three on a single L2 domain is probably too much. There is some work to be done here! > This is done prior to RPL coming into action. It is also necessary to > exchange RPL ranks with all neighbors. How else would a node determine > its parent(s)? I guess afterwards tunnels to neighbors that are neither > parent nor child of a node could be closed again, yes. Yes, bring up the tunnel, send DIOs, listen for DIOs. I wouldn't close the tunnel afterwards until there was a resource constraint, but perhaps one might wind up marking the tunnel as "do not rekey". The other end may feel different though. >> It's a good question, and I assumed that global route repair would >> occur periodically, and whenever the NOC found that it couldn't reach >> some nodes. There is probably a gap in knowledge/experience here. > The wording in ACP Section 6.12.1.7 is "The DODAG version is only > incremented under catastrophic events", therefore I was under the > impression global repair would only be done in extreme circumstances, > and not periodically. A link going down in an ISP is probably a catastrophic event. Maybe the text needs adjustment. -- 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] ACP RPL profile and dynamics
Hendrik Mahrt wrote: > First question: In the ACP RPL profile it is stated that "Nodes SHOULD > select more than one parent, at least three if possible". But I'm not > sure how multiple parents are selected by OF0 without nodes being > greedy. > The OF0 RFC [RFC 6552] does not contain any information about > multiple parents, except for a 'backup feasible successor' (Section > 4.2.2). Remember that each parent is reachable over an IPsec tunnel. It's somewhat different than from a typical LLN situation where one could hear from multiple parents on a broadcast media. (Well, in fact the GRASP DULL message serves that purpose) My thinking, which may be entirely wrong, is that the idea is to keep at most three IPsec tunnels up with potential parents. DAOs should go down those tunnels so that: a) each end is aware of each other's rank b) were we ever to do p2pRPL, or DAO projection, that we'd have some lateral tunnels to use. c) that we somehow learn of the ETX and latency across that link, and derive a metric for that direction. We could do this within the tunnel, using RPL messages, ICMPv6s, or we could do this using the tunnel, using IKEv2 DPD messages. On the one had we could have situations where there is some ACP-unaware L2 fabric connecting many ACP nodes, and it really would be silly to form all the adjacencies. In this case, initiate at most three, and pick one as parent, but keep the other two up (and monitor them) On the other hand, a more typical ISP situation is there is a router with three or four WAN links, each of which is a p2p ethernet. In that case, there is really only one peer on each link, and it makes no sense not to have a tunnel up on every interface. > But if I understand correctly this successor is not 'actively' > sought after, i.e., the node does not actively increase its rank to > obtain it, as that would surely violate the rules of RPL on greediness > formulated in RFC 6550 in sections 3.7.1 and 8.2.2.4?! Or am I > mistaken? Yes, that's right, the parent is not *selected*, but rather kept in reserve. See for instance, some of the recent RPL work https://datatracker.ietf.org/doc/draft-ietf-roll-rnfd/ which would use these "lateral" relationships to detect if the parent had died. > Second question: The ACP RPL profile, as I understand it, features no > form of global repair or DODAG version increase (except manual > intervention by admin). How would that work with node mobility (which > is mentioned in Appendix A.4)? MaxRankIncrease would limit a node's It's a good question, and I assumed that global route repair would occur periodically, and whenever the NOC found that it couldn't reach some nodes. There is probably a gap in knowledge/experience here. -- ] 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[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] ACP RPL profile and dynamics
Hendrik Mahrt wrote: > I also looked at the 'unstrung' RPL implementation for enlightenment > but found nothing really regarding multiple parents or handling link > failures? The implementation looks to be WIP though. I might also have > missed something, in which case I would be grateful if someone can > point me to the relevant code sections. unstrung is certainly lacking in this area. I would be happy to talk about how to extend it in the right areas. -- 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
[Anima] MUD for (Virtual) RFC8995 Registrar Appliances -- register a port number?
I have begun shipping virtual appliances for RFC8995(BRSKI) Registrars to Enterprises. I anticipate shipping SBOM information with the virtual appliance, and it would be relatively easy to do that via DHCP/LLDP MUD file. I have been thinking about how to write up this MUD file. Most of the MUD ACLs are easy: 1) https access to update server 2) inbound ssh access for maintenance/diagnostics from a known place 3) inbound port-8443 access for BRSKI-EST connection 4) outbound GRASP announcements (3) and (4) may well fall below the level of most MUD controllers, since that will be enterprise internal (NOC) traffic. And I'm not sure that multicast destinations will realy fit well into what a MUD Controller might expect ACLs, but ... Then we get to: (5) outbound connections using HTTPS on undetermined ports to undetermined destinations for the BRSKI-MASA connections. The specific port that is connected to is determined by the MASA URL extension in the IDevID certificate. In writing RFC8995, we figured that we were removing a hassle to deployment by not requiring a specific port number. In particular, not using port-443. Eventually, the ACLs could be part of a supply chain integration, but for now, this is a problem for Enterprises that are hesitant to open port numbers. ** Now I think that we should have registered a port number for the BRSKI-MASA ** connection, which would have let us at least write a somewhat restrictive ** ACL. I'm unclear if it's possible to write a MUD ACL that permits connection to any host on a particular port. My reading of RFC8519 is that yes, one can have a l4.tcp ACL without having an l3 ACL. So, to make that workable, we'd at least need a registered port. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] session-id as epoch-id (was: Re: Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts])
Brian E Carpenter wrote: tte> So, the question is what attack vector we would open up if we used tte> sequential session-ids. Given how the signature protects the tte> message, i will claim there is no new attack vector as long as the tte> signature is checked. But if GRASP forwarders do not check the tte> signature, then the sequential allocation could increase the risk tte> that an attacker tries to stop valid flooded messages by tte> "pre-flooding" faked messages with the guessed session-ids. bc> Right. So I'm not yet convinced we should repurpose the session ID for bc> this. If we're going to focus on signing objectives, maybe we need to bc> decouple this aspect completely from the session ID? I am sitting on the fence still here. I think that during flooding, that the whole point is to replay the object until all interested parties have seen it :-) Aside from the anti-replay aspect, it would be nice to be able to avoid having to have a cache of every flooded message since the dawn of time. For that reason, it's probably good to have an Epoch ID as a separate object, so that when it changes, then you can safely throw away your session-id cache. >> Now, some part of this "pre-flooding" risk exists today: If i am a bad >> ANI node, i receive the valid flood-message, and i have a second >> connection to another part of the network, i can pre-flood a broken >> message and stop that the real message makes it to that part of the >> network. Aka: This is an argument to actually do check signature when >> flooding them. The argument, why checking signature would be 'free' >> is that for most flooded messages the ANI node would not only be >> flooding, but also receivign/using. And those nodes would need to >> check signature anyhow. > Possibly. But from an implementer's viewpoint, the relay path doesn't > decode the message - it just decrements the loop count and resends > immediately on all the other interfaces. It's a quite separate code > path that decodes (parses) the message and would verify the signature. > I'm not saying it can't be done, but it's like the fast path/slow path > argument for routers. This puts relaying on the "slow" path. I'd argue for always checking signatures if they are there before flooding. If it's too expensive, then I think that I'd rather lower the strength of the signature until it's cheap enough. If it's a thing that has security critical information, then if some ASA finds that the signature is too weak, then it could just do some unicast GRASP with a stronger signature. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] session-id as epoch-id (was: Re: Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts])
I think Toerless wrote: >> I don't really know what "all epoch" mechanisms would mean. Ideally we >> would look for the most easily adopted replay protection mechanism >> that had in some othr protocol passed IETF SEC standards >> approval. Whether its called epoch or not. Brian E Carpenter wrote: > I mean that if you write the current epoch number into non-volatile > storage and then your node sleeps for a year, the epoch number could > perhaps have cycled. However, I agree that we should not re-invent this > wheel. I'm working on a document on epoch-id distribution that I hope to share in a week or so. In my model one should be able to get several (hundred) epoch's behind and still securely catch up. However, there are some edge cases where a system would have to engage in M_REQ_NEG (I think) unicast with the Epoch distributor to re-initialize one's state. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Consolidated floods [was Signing GRASP objectives]
Brian E Carpenter wrote: > (b) but it could be implemented *on top* of the current > definition of GRASP, if the floods in question were issued with a loop > count of 1 (so they would never be relayed per RFC8990), and there was > a flood consolidator - effectively just a special ASA as far as GRASP > is concerned - that sent out consolidated floods. why couldn't the flood consolidator collect and relay things with higher loop counts, as long as it didn't do it too often? (is that called a "dam"? sluicegate? me wastes ten minutes reading about dams on wikipedia) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] ACP vs. Data plane Re: Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
Toerless Eckert wrote: > I can not link ICN to the use-cases you describe. I could however > easily map the resilient light-switch use-case to multicast and GRASP: okay. > Light switches could M_FLOOD instructions, such as in old building > automation: GROUP_123 on/off. And lights are then preconfigured to > belong to a group. Or as you propose, they could M_FLOOD status, as you > propose. And lights are then preconfigured to be interested in a > particular set of light-switches (or other states, motion sensors > etc..). ICN is just a signed M_FLOOD here. > I am sure a pub-sub geek would describe this as a pub/sub bus kinda > operation. Difference to multicast/messages is that buses supposedly > cache state, so a light that had power failure should immediately get > th relevant information, whether it is group status or other states of > interest from the bus instead of having to wait or re-request messages. I think that in an ICN, any node with the signed message can retransmit it. > Wrt to resilience and whether to run data across ACP to be able to > validate its correct/resilient operation: I think we often said that > simpler networks such as low-power iot networks may not want to afford > the complexity of separate ACP and data-plane, in which case the > data-plane is the acp, aka: automatic/secure/resilient. However: Yes, but I'm not talking about the lower-power part of the network. I'm thinking about a 100G/s backbone in a building, whose purpose is to provide data services to the tenants. (Probably using SR6, metro-ethernet, QinQ, or...). The ACP would be the management plane for that network. Some gateways/routers would have 100G interfaces, but also low-power IoT interfaces, or powered BACnet/100baseT1. Or even GPIO boards that have analog wires to buttons. > In a large/fast/complex netework, you may have different degrees of > degradation of the network, and the purpose of the ACP is to be the one > layer of last-defense, of what the network should be able to do when > everything else may have failed, especially also to perform possibly > complex repair operations remotely. So the question really is how much > you want put into that last line of defense. part of my point is that if you think of the ACP as being the "last line", then that means that you might not notice if it has broken. > IMHO automated testing and automated injection of errors and all this > good stuff for resilient networks should test the data-plane, and in a > simple approach, all the control for these ongoing OAM operations could > go across the ACP, but maybe even most of that complex and maybe > high-load control should go to data-plane. Think about ongoing Mbps > streams of network telemetry to centralized or decentralized analytics > engines that attempt to measure network health. ACP or not... I come back to SHIM6, MPTCP or QUIC/MASQUE. Initiate the connection over ACP addresses, but then discover some higher bandwidth IP addresses and prefer them for the bulk transfers. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
Toerless Eckert wrote: > Could as well simply be a function which buffers flood-messages over a > period of e.g.: 60 seconds and coalesces them together, so it's > transparent to the originators (loose coupling). > So, now i have a single flood-message with multiple objectives, each > objective requiring its own signature, because it comes from a > different originator/certificate. I can buy this example. I think that the cost of the flood across the wired/powered part of the network is low, and the number of messages we can coalesce is not that many. at least ~50 bytes per message, given a 32-byte EcDSA signature. That's still a 20:1 ratio though, and nothing to sneeze at. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
Toerless Eckert wrote: > On Wed, Aug 24, 2022 at 08:33:43PM -0400, Michael Richardson wrote: >> >> Brian E Carpenter wrote: > I need to >> understand epochs a bit better. I wonder whether an epoch > boundary >> should define when session-id repetition becomes OK (even if > highly >> improbable). There's a practical argument for that: a good > >> implementation will cache obsolete session-ids to detect repetition, > >> but needs to age out that cache somehow. My code does that with a > >> simple LRU but that isn't ideal. >> >> That's totally a good idea. is: >> https://www.ietf.org/archive/id/draft-ietf-rats-architecture-21.html#name-example-3-epoch-id-based-pa >> helpful? > How do you think Rats epoch-id is different from Grasp session-id, > where each originator in grasp simply has its own epoch-id space > (because the session-ids from each originator are in context of that > originator) ? Ah. A trusted third party would rain Epoch IDs down on all nodes, both transmitters and receivers. They could use signed M_FLOODs.yes, that creates a circular problem, but the EpochIDs could be arranged to be a hash list, a la S/Key. > I couldn't find reasonable examples of how often epoch-ids in rats > would be changed, so i have a hard time coming up with a qualitative > comparison. It's a good question, and the answer depends upon how things will be used. I would envision a new Epoch every few minutes to every few hours. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
Brian E Carpenter wrote: > I need to understand epochs a bit better. I wonder whether an epoch > boundary should define when session-id repetition becomes OK (even if > highly improbable). There's a practical argument for that: a good > implementation will cache obsolete session-ids to detect repetition, > but needs to age out that cache somehow. My code does that with a > simple LRU but that isn't ideal. That's totally a good idea. is: https://www.ietf.org/archive/id/draft-ietf-rats-architecture-21.html#name-example-3-epoch-id-based-pa helpful? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
Carsten Bormann wrote: > That is getting closer to my question “what does it mean for > (something) to be signed”? > Apparently, this is a statement from an initiator, valid within the > session-id, optionally scoped to the locator option, and expressed in > the objective. These four are picked out of the message. The > mechanism is specific to M_FLOOD and needs to be re—done for any other > message type. > The signed-data is missing a freshness component, which is either an > absolute timestamp (like CWT exp, possibly enhanced with nbf/iat info) > or an epoch marker. Yes. Toerless thinks it might be contained in the session-id, but I've been sitting on the fence about that. > We want the objective to stand alone for forward compatibility; hence > the signature would have a detached payload. > What I don’t understand is why the signature then needs to be encoded > as part of the objective. Why can’t I sign a combination of objectives > that are only valid as that combination? I think it could go somewhere else, but I'd like to first understand an example of this combination. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
The use case that led me to start some of this discussion was that of using Information Centric Networking in emergency situations. A key observation that many have made is that backup/emergency systems need constant maintenance and testing, and if they aren't used regularly then they tend to rot. This leads to the view that if a converged network can be made resilient enough to be used during emergencies, then there are a number of advantages: a) it probably has more than enough capacity for the emergency traffic! b) if it breaks, then someone will notice, and there is an incentive to fix it c) many situations which aren't full on emergencies benefit from the resiliency I looked through some documents, such as: https://www.rfc-editor.org/rfc/rfc7945.html#section-3 https://www.rfc-editor.org/rfc/rfc8884.html Research Directions for Using Information-Centric Networking (ICN) in Disaster Scenarios Read the requirements at: https://www.rfc-editor.org/rfc/rfc8884.html#section-3.3 and compare them to what GRASP offers? In thinking about building automation IoT systems, the ICN approach is rather useful. In it, one does not tell a light switch which light bulbs to control, but rather tells a light bulb what senses should be relevant to it. The sensors then simply announce their state, and the bulbs respond. In a converged building network, where there might be many hundred Gb/s of bandwidth for the tenants to use, the sensor network could be accomodated by a series of gateways which translate between 802.15.4 radios or BACnet, and a fiber-optic backbone. But the control network needs to be protected from the rest of the traffic, and isn't that what the ACP does? Is there that much difference between learning that an optical module has gone bad via SNMP/NETCONF over ACP, and learning that the elevator door is damaged and won't close, so elevator 14 is out of service, over BACnet? (Could the two be related?) So in the view that the resiliency of the control network must be continuously be tested, then the right answer is to use the control (ACP) network for all the automation functions. Of course we can run DTLS for MQTT and the like over the ACP, and for many things we probably should do that, but we also need all the caching and flooding mechanisms that GRASP offers. (particularly during a flood. Hmm. Some kind of RFC2616-like RFC about new M_FLOOD objectives for use during a flood ) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
Brian E Carpenter wrote: > On 23-Aug-22 21:56, Toerless Eckert wrote: >> Agreed. My opininion is that the mandatory-to-verify is not at the >> level of the flood-message, but at the objective definition level. > If that's the case, we are on the wrong track. Should we be discussing > signing GRASP objectives, rather than messages? That might better fit the goals. Probably we should have started with a few use cases. > In many ways, that would be much easier to design and retro-fit. cool. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] remote attestation Epoch ID distribution in IPv6 and GRASP
Henk Birkholz wrote: > If there is interest in this application of a source for freshness, we > can certainly make that happen. > And while we are at it: If ANIMA has any requirements on potential > payloads of an epoch marker, please say so :-) So while I know exactly what I want to do for initial onboarding within BRSKI, which is very clearly background check, I'm unclear what to do for *ACP* uses for continuous verification that the device hasn't gone bad. The IoT case, particularly the Home IoT case, is similar, but different in subtle ways. For instance, it's not crazy to *me* to do a soft reboot of your lightbulbs once a day (without touching the hardware registers that control the state of the bulb), in order to get a fresh measured boot value. In addition to being good for attestation, it also gives one a "hitless" way to do regular firmware updates without annoying anyone. But, for routing equipment, I'm not so sure. This is a place where I think that Eric Voit has a much better handle on how we produce evidence that is fresh.. Would you want to use the "hitless" facilities which now seem ubiquitous from the major manufacturers? (I first saw this from Brocade in 2010, but I never saw it actually work) In either case, this is where the Epoch ID comes into play to me. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Extending GRASP messages and signing GRASP multicasts
Brian E Carpenter wrote: > We would prefer that this doesn't invalidate existing (unsigned) GRASP > code. That could be done by appending an optional signature to the > existing M_FLOOD message format. An alternative is to add a new flood > format that is signed, but would not be understood by existing code. A third option is that we make what might be a breaking change. A subject of some debate has been whether some of the proposed changes are in fact breaking changes to the spec, or just to how some code (mis)-intrepreted the spec. At this point, my opinion is that we do not have enough GRASP deployment for this to matter. I think that having signed M_FLOOD messages, even if they are inside a protected ACP, is a sufficiently useful thing that we should just do that. I have one use case that involves Information Centric Networking (ICN) inside of an ACP. > 3. It seems fairly obvious that we should use COSE, most likely with a > detached payload, so that the M_FLOOD message appears unsigned for > nodes that don't support signing and verification. One possible breaking change would be to use COSE in non-detached payload mode. > 4. We don't claim to have solved the general problem of key > distribution for multicast destinations, but in the ACP context it > seems likely that we can flood out the necessary public keys. I feel confident that for a number of use cases that this won't be an issue, and that we can leverage the BRSKI enrollment process to get any application specific keys that we need. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] remote attestation Epoch ID distribution in IPv6 and GRASP
As explained at:
https://www.ietf.org/archive/id/draft-ietf-rats-reference-interaction-models-05.html#name-uni-directional-remote-atte
and also referenced at:
https://www.ietf.org/archive/id/draft-ietf-rats-architecture-21.html#name-example-3-epoch-id-based-pa
(which has a cool SVG diagram)
one of the key ways to get freshness for remote attestation mechanisms is to
have
some entity send a series of Epoch IDs to all parties. They are
non-repeating, non-deterministic nonces that wind up being included in the
signed Evidence produced by Attesters.
draft-birkholz-rats-epoch-markers imagines reuse of RFC3161 TimeStampTokens
as one example.
In bilateral systems where TLS is used as a transport (such as in BRSKI
onboarding), then it possible to use tls-unique^WTLS Exporter to get
something which is fresh. In other scenarios where Evidence will be
shared with a Verifier that did not participate in the TLS connection (such
as in background check model, which is what BRSKI would need to use) then
the Epoch ID mechanism may be a better way.
When working on this freshness model in the RATS architecture, one
distribution mechanism that we envisioned was some kind of rain from
("heaven") above of Epoch IDs. Such as having them embedded in a GPS or 3G
signal/beacon. This has advantages for uni-directional attestation where no
signals are allowed into the nuclear power plant, yet fresh attestations need
to be emitted.
Much more mundane scenarios just need to have the EpochID distributed in an
efficient manner.
One thought is an RA option. The universal RA option comes to mind, but the
EpochID is not a constant, so it does not entirely fit into one concept of
universal RA where it's something that can just get inserted verbatim into a
router configuration.
(I was going to CC 6man, but I'm not doing that yet)
A second thought is to do this via GRASP (RFC8990) M_FLOOD.
ANIMA's ACP operators will want to do regular attestation of routing
platform, so we will need such a thing. A GRASP M_FLOOD could be forwarded
through the ACP, and if an Enterprise situation, could be then multicasted on
the normal links for hosts that need the EpochID.
As GRASP is just CBOR over UDP, sometimes multicast on IPv6-LL, it's not
more complicated than an RA. As draft-birkholz-rats-epoch-markers seems to
be defining a signed EpochID in CBOR format, the match seems quite good.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
