Hi Toerless, hi Esko, Sorry for providing the feedback after the IETF deadline but I did not manage it earlier.
I reviewed BRSKI discovery and variations (draft-ietf-anima-brski-discovery-05) https://datatracker.ietf.org/doc/draft-ietf-anima-brski-discovery/05/ First of all, I think it was a good move to collect the different discovery mechanisms in one document avoiding that each BRSKI variation defines an own and to ensure consistency over the different discovery mechanisms. What would be good is to see the functionality implemented at least for some of the discovery mechanisms to verify the overall approach. Based on the experiences of the BRSKI implementation, several issues become obvious during implementation. The following is a list of comments regarding points I stumbled upon. They are of different nature (nits, comments, thoughts). I provided some proposals using OLD/NEW. General: - Throughout the document often the term "IP or IPv6" is used Proposal to state "IPv4 or IPv6" - The document uses the term "roles" to describe the different BRSKI components or BRSKI services. I double checked RFC 8995 and it also uses both terms. For the sake of simplicity I would propose to use just one term for description and stick to "BRSKI services". - "Section 1" is referenced in several places, which should be double checked. It seems it sometimes rather refers to "BRSKI [RFC 8995]", but in some locations like 2.1.2 it likely refers to different references - Instead of the term "root CA certificate" we may use "trust anchor" - Update of references: - OLD I-D.ietf-lamps-lightweight-cmp-profile, NEW RFC 9483 - OLD I-D.ietf-anima-brski-ae, NEW RFC 9733] Section 2.1.1 - OLD "F0r", NEW "For" Section 2.1.3 - Just as a thought: The statement regarding BRSKI proxies may not apply in BRSKI-PRM to the discovery of pledges by the Registrar-agent. This discovery would not involve BRSKI Join proxies as of BRSKI-PRM. For the connection between the registrar-Agent and the Registrar it applies. - Proposal to refer to the "BRSKI proxy" rather as "Join proxy" or "BRSKI Join proxy" as defined in RFC 8995. If the functionality goes beyond the join proxy, we should define the term Section 2.2 - OLD Defining these via registry tables maximizes consistency across discovery mechanisms and makes support for variations across different discovery mechanisms easier and consistent. NEW Defining these via registry tables maximizes consistency across discovery mechanisms and eases support of variations across different discovery mechanisms. Section 3.1.3 - OLD "BRKSI", NEW "BRSKI" Section 3.1.5 - The variations for vformat only relate to the "outer" format. With the current approaches in BRSKI, BRSKI-PRM and cBRSKI this is consistent as they do not provide further variations of inner/outer format. In BRSKI CMS is used as a wrapper for JSON. If some draft in the future utilizes a different format wrapped with CMS, the variation type "cms" is no longer unique. One approach may be to name it "cms-json" instead. - Regarding the variation type "enroll", BRSKI-PRM defines 2 new endpoints at the registrar to allow for provisioning of wrapped enrollment information (requestenroll, wrappedcacerts). As these are defined in addition to the EST endpoints, it might be necessary to have either something like a PRM-flavored EST or to be able to conclude that a combination of prm and est in the variation string relates to an enhanced EST capability. Section 3.1.7 - OLD "agents", NEW "Registrar-agents" Section 3.2 - Relevant initiators (of discovery) are stated as pledges and proxies. Does proxy relate to the "BRSKI Join proxy" here? Imitator would relate to the case when the Join proxy is actually discovering the appropriate registrar for a connecting pledge? As in BRSKI-PRM the Registrar-agent is the initiator, it could be added as well. This may be not relevant for the case in which a service technician is connected to the same LAN segment as the pledges to discover them, but if the Registrar-agent is co-located with the registrar it may be different. BRSKI-PRM does not assume the pledge discovery over a Join proxy. - Relevant responder are considered as proxies and registrars is still fine from my understanding. I was thinking if the pledge as responder for BRSKI-PRM would make sense too. Again rather for the case of co-located Registrar-agent. But I was not sure if this makes sense based on the description of the responder selection in section 3.2.1. Here it relates rather to the responder as a kind of infrastructure service rather than the actual pledge to be bootstrapped. Section 3.2.1 - Just a thought: The last two paragraph regarding resilience may be put in a separate "operational consideration section". On the other hand this would rip the description and the considerations also in other sections apart. This is also valid for other section. Right now, I'm seeing a benefit in keeping the information together. Section 3.3.2.1. - Heading: OLD "Direction Connections Mode", NEW "Direct Connections Mode" Section 3.3.2.2 - OLD "annuncements", NEW "announcements" - The text regarding load balancing is partly repeated from section 3.2.3 and could be referenced. Section 3.3.2.3 - JPY should be explained or referenced with the constraint join proxy draft - proposal to rename the mode name for consistency from OLD "Proxy in Name Only Mode on Registrars" to NEW "Proxy in Service Name Only Mode on Registrars" Section 3.4.3 - The statement "Manufacturer published LDevID identification schema" should refer to the IDevID instead of the LDevID, as the manufacturer does not have control over all of the LDevID content - Proposal to change: OLD "BRSKI components perform cryptographic authentication of the IDevID ..." NEW "BRSKI components perform cryptographic authentication using the IDevID ..." - The following part is not quite clear to me regarding the context it applies to: OLD "In this normal case, a BRSKI component only needs to be configured with a list of root CA certificates that the BRSKI component trusts to provide pledges with IDevIDs and configure a manufacturer-name for each." - The second part related to the IDevID provision should relate to the LDevID as the IDevID is taken as granted in BRSKI. The manufacturer name configuration would be relevant for the Registrar-agent and potentially DNS-SD. If that is the case we could change it to: NEW "In this normal case, a BRSKI component (i.e., Registrar-Agent, Registrar) needs to be configured with a list of root CA certificates that the BRSKI component trusts to provide pledges with IDevIDs and configure a manufacturer-name for each in the related discovery component (Registrar-agent, DNS-SD)." - The statement "Typically, an owner will not know the IDevID of a pledge before being able to connect to it." somehow contradicts with the following description. Based on the supply chain integration, the owner should be able to have access to IDevID information or at least serial number information based on the delivery information or packaging. - Maybe a side question, do we distinguish between owner and operator? If not, maybe we should stick to operator. Section 3.5.2.2 - Based on the example in Figure 4 my conclusion is the the default for GRASP would always be "rrm" and therefore does not need to be stated explicitly Figure 4 states: "["AN_Proxy", 4, 1, "", ". The explanation is provided later on in section 4.2.2 with the usage of the default mode, but it may be good to also state it here Section 4.2.2 - in the table line |BRSKI, | |jose |ThisRFC |Dflt*|JOSE-signed JSON, Default when prm is | the reference should be provided to I-D.ietf-anima-brski-prm instead of I-D.ietf-anima-brski-ae in the note column - in the table line | |vformat |jose |ThisRFC |Dflt |JOSE-signed JSON, Default when prm is | the reference should be provided to I-D.ietf-anima-brski-prm instead of I-D.ietf-anima-brski-ae in the note column Section 4.2.3 - in table line | |[I-D.ietf-anima-brski-prm] |prm-jose |prm jose | | it is maybe worth to add a note that the combination of prm and est assumes the additional enrollment endpoints define in BRSKI-PRM to provide wrapped enrollment objects (see also comment above). Again, thanks for taking up that work. I will do a more in depth review in the near future. >From the current state I think the document is very comprehensive regarding >the technical approach. It definitely needs some more thinking through the different use cases and examples on my side. Best regards Steffen -- Steffen Fries Siemens AG
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
