Hi Mahesh, Regarding the operational documents we have started the discussion in the ANIMA Design Team to update the document based on the discussion about the new section in BRSKI-PRM. Both documents are applicable for other BRSKI variants as well. I included the link to both documents as a pointer, even though they are not finished yet. They were intended as informative references to not create a dependency. So based on that the new section in BRSKI-PRM concentrates on additions due to the Registrar-Agent, while for already existing components like the Registrar or the MASA the more general documents are pointed to.
Regarding the corrections in the logging section, I correct the malformed list and put the update on the ANIMA git: https://github.com/anima-wg/anima-brski-prm. It will then be included in the next submission. Best regards Steffen From: Mahesh Jethanandani <mjethanand...@gmail.com> Sent: Monday, January 13, 2025 1:58 PM To: Fries, Steffen (FT RPD CST) <steffen.fr...@siemens.com> Cc: draft-ietf-anima-brski-...@ietf.org; anima@ietf.org Subject: Re: [Anima] AD review of draft-ietf-anima-brski-prm-15 Hi Steffen, See inline with [mj]. On Jan 3, 2025, at 9:12 PM, Fries, Steffen <steffen.fr...@siemens.com<mailto:steffen.fr...@siemens.com>> wrote: Hi Mahesh, Thank you very much for the review and your comments. I will provide the response inline in this email to keep the context. We will provide an updated version to datatracker containing the comment resolution as indicated below and we finalized the discussion on the comment resolution. Intermediate versions will be available on the ANIMA git. From: Mahesh Jethanandani <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> Sent: Wednesday, December 25, 2024 9:14 AM To: draft-ietf-anima-brski-...@ietf.org<mailto:draft-ietf-anima-brski-...@ietf.org> Cc: anima@ietf.org<mailto:anima@ietf.org> Subject: AD review of draft-ietf-anima-brski-prm-15 Hi Authors of draft-ietf-anima-brski-prm, First of all, thank you for working on the document. I am trying out a slightly different process by having Last Call Expert Reviews done before or in tandem with my AD review. Please address the comments provided by the experts also. While I expect some kind of response to the COMMENTS I have provided, I will leave it up to you to decide if you want to address the NITS or not. [stf] Just upfront: We will provide answers below and also extend the document regarding the proposed enhancements. We'll also incorporate the NITS, as they improve readability. The draft effectively highlights scenarios (e.g., NAT/firewall traversal) where traditional BRSKI fails, justifying the need for a pledge responder mode. Aligning to existing BRSKI mechanisms with EST and voucher exchanges ensures compatibility. With these capabilities come potential issues that I would like to see highlighted in a separate section, called Operational Considerations. * The introduction of the Registrar Agent introduces an additional component in the architecture. * Operational complexity and potential misconfiguration in deploying and managing this entity could pose challenges. * With the added interaction between the Pledge, Registrar Agent, and the Registrar might come additional latency. * While the draft discusses backward compatibility, edge cases in heterogeneous deployment (e.g., mixed-mode BRSKI and BRSKI-PRM) need further elaboration. For example, the draft introduces new roles and behaviors, such as the Registrar Agent and Pledge Responder Mode, which extend the traditional BRSKI model. However, it does not explicitly discuss: * How these new components coexist with legacy BRSKI components in mixed environments. * Whether traditional BRSKI pledges and registrars can seamlessly interact with those using BRSKI-PRM. * Please clarify whether and how existing Registrars can interoperate with Pledges using PRM without requiring significant updates. [stf] It is a good idea to provide a separate section regarding operational considerations with the points you mentioned above. Some of the points have already been addressed in section 5 (architecture) like the last bullet point for deployment options (stand-alone vs. integrated Registrar-Agent), which can also be referred to. In addition, also section 6 (refers to certain operational considerations in the description of the components. In addition, for BRSKI there is already a separate document targeting operational considerations, which is more elaborate: https://datatracker.ietf.org/doc/draft-richardson-anima-registrar-considerations/ and https://datatracker.ietf.org/doc/draft-richardson-anima-masa-considerations/. We will include a reference to these drafts as well. [mj] Unfortunately, both the drafts have expired, and I do not know what the plan is for their revival. Even if they are, they are I-D at this time, and the time it will take to progress them to an RFC status could stall this work. Have you considered incorporating some of the relevant text here? Terminology Section: Although a general terminology section has been defined, one that is dedicated to terms used in this draft would have been preferred. In either case, defining new terms (e.g., Registrar Agent) upfront would enhance readability. [stf] We will include a terminology definition of the Registrar-Agent. Figures and Diagrams: The architectural diagrams could be more detailed, especially to clarify the interaction between components (Pledge, Registrar Agent, Registrar). [stf] I guess you are referring to Figure 2 and Figure 3 here as Figure 1 already contains the clarification. We will add the protocol information in the respective figures. Section 5 containing the figures also has the verbal description of the interaction. It may also be good to add a forward reference to section 7, which contains a detailed description of the exchanges between the involved components. Security Consideration: The draft addresses security extensively, including: - Mutual authentication. - Voucher-based onboarding. - Protection against replay attacks. However, even though there is mention of it, further elaboration on potential risks introduced by the Registrar Agent, such as man-in-the-middle attacks or compromised agents would strengthen this section. [stf] We will review and enhance the section accordingly to explain boundary conditions. Specifically as the Registrar-Agent is a new and likely a stand-alone component the handling of compromised Registrar-Agents should be included. Logging Considerations: It was refreshing to see that the authors had considered including events that should be logged, and the analysis done. Further improvements could be had by: * Clearly outline the key events to log, such as: * Communication attempts between the Pledge, Registrar Agent, and Registrar. * Voucher requests and responses. * Authentication successes or failures. * Protocol negotiation and onboarding steps. * Allow adjustable logging levels (e.g., debug, info, error) to cater to different operational needs. * Include guidance on protecting log files, such as: * Encryption of log storage. * Controlled access to logs based on roles. * Redaction or hashing of sensitive data (e.g., device identifiers, cryptographic keys). * Address secure transmission of logs to centralized log servers, particularly in cloud or distributed environments. * Include metadata in logs to identify whether a specific interaction pertains to traditional BRSKI or BRSKI-PRM (e.g., log tags like BRSKI vs. PRM). * Improve logging around interactions involving the Registrar Agent. * Recommend logging detailed error codes and diagnostic information for failures, such as: * Registrar Agent is not reachable. * Timeouts during voucher exchange. * Authentication failures with the registrar or pledge. * Emphasize logging timestamps with time synchronization (e.g., via NTP) to ensure accurate sequencing of events across components. * Recommend log output in standard formats (e.g., JSON, syslog) for easy integration with log analysis tools and SIEM systems. * Suggest logging key operational thresholds (e.g., high latency, failed onboarding attempts) to trigger alerts for proactive issue resolution. [stf] The intention of including logging was exactly to support failure detection and handling. The points you listed above can be used to enhance that section and provide more details and pointers to deployed technology. We will elaborate more on these. [mj] Thanks for adding most of these above points. BTW, the four bullet items in the first paragraph that have been added are malformed. Can they be fixed? Cheers. Privacy Considerations: While logging is essential, it may inadvertently capture sensitive or personal data, which the draft does not sufficiently address. - Specify privacy-preserving measures in logs, such as: - Avoid logging personally identifiable information (PII) unless necessary. - Anonymize or pseudonymize data where possible. [stf] Good points. We will add this to the Privacy Considerations. No reference entries were found for these items, which were mentioned in the text: [draft-ietf-netconf-sztp-csr-06], and [draft-ietf-anima-brski-async-enroll-03]. [stf] Both drafts only appear in the change history in Appendix C, which will be deleted before final publication. So I don't think it needs to be solved separately. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "he"; alternatives might be "they", "them", "their" [stf] In general agree, but I could not find an occurrence of "he" in the document. Could you provide a pointer to the section? * Term "traditional"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread" [stf] Replaced "traditional" in the YANG module section with "common" NITS: The term "pledge" is sometimes capitalized as "Pledge" and other times in lowercase. Please choose one (I prefer uppercase) and apply it uniformly when referring the entity called Pledge. [stf] I double checked the document, we use "Pledge" in the context of explanations of abbreviations or terms like BRSKI-PRM, PVR, and PER to have an easier connection between the abbreviation and the related term. With this approach we aligned to BRSKI and thought it might be good to keep the same use of capitalization. Document references draft-ietf-netconf-sztp-csr, but that has been published as RFC9646. [stf] thanks, updated accordingly Document references draft-ietf-anima-jws-voucher-10, but -14 is the latest available revision. [stf] This will be automatically updated in the new version Document references draft-irtf-t2trg-taxonomy-manufacturer-anchors-03, but -04 is the latest available revision. [stf] This will be automatically updated in the new version Document references draft-ietf-anima-brski-ae-12, but -13 is the latest available revision. [stf] This will be automatically updated in the new version Document references draft-ietf-anima-brski-discovery-04, but -05 is the latest available revision. [stf] This will be automatically updated in the new version Section 1, paragraph 11 > entity, as defined in [RFC9483]. Typically a device or service that owns a pu > ^^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "Typically". [stf] included Section 3.2, paragraph 1 > ng on behalf of the registrar. In addition the registrar must be able to veri > ^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "addition". [stf] included Section 5.2, paragraph 2 > ut the operational complexity of standalone Registrar-Agents by integrating > ^^^^^^^^^^ Do not mix variants of the same word ("standalone" and "stand-alone") within a single text. [stf] changed to stand-alone to match other occurances Section 6.1, paragraph 6 > ry to apply DNS-SD with mDNS. For Ethernet it is provided by simply connectin > ^^^^^^^^ A comma is probably missing here. [stf] included Section 7.2, paragraph 4 > R trigger. The registrar MAY consider to ignore any but the newest PER artifa > ^^^^^^^^^^^^^^^^^^ The verb "consider" is used with the gerund form. [stf] change to "ignoring" Section 7.2, paragraph 7 > re-enrollment can be supported in a similar way. In this case, the pledge MAY > ^^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "similarly" to avoid wordiness. [stf] done as suggested Section 7.2.2.2, paragraph 9 > gistrar converts the PVR artifact to an Registrar Voucher-Request (RVR) arti > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". [stf] change to "a" Section 7.3, paragraph 4 > . Depending on policy, the MASA MAY chose the type of assertion to perform. F > ^^^^^ The modal verb "MAY" requires the verb's base form. [stf] changed to "choose" Section 7.3.1, paragraph 7 > , the domain registrar MUST add an additional JWS Protected Header and JWS Si > ^^^^^^^^^^^^^^^^^^^^^ This phrase might be redundant. Consider either removing or replacing the adjective "additional". [stf] removed "additional" as suggested Section 7.3.3, paragraph 1 > re 24 depicts exchanges for the PER request handling and the following subse > ^^^^^^^^^^^ In this context, "PER-request" forms an adjective and is spelled with a hyphen. [stf] done as suggested Section 7.3.4.1, paragraph 5 > MUST verify that * the PER was signed signed with the private key correspondi > ^^^^^^^^^^^^^ Possible typo: you repeated a word. [stf] deleted repeated word Section 7.3.4.1, paragraph 11 > result in a pledge EE certificate singed by the domain owner (e.g., LDevID > ^^^^^^ Are you sure you meant to write "singed" (a synonym for "burnt"), or did you mean "signed"? [stf] "signed" was meant, Section 7.3.5, paragraph 3 > e-enrollment may be supported in a similar way with the exception that the c > ^^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "similarly" to avoid wordiness. [stf] done as suggested Section 7.4, paragraph 16 > ion 6.1.2. The Registrar-Agent MAY stored information from the first connecti > ^^^^^^ The modal verb "MAY" requires the verb's base form. [stf] changed to "store" Section 7.5, paragraph 3 > Voucher Status. If the pledge did not did not provide voucher status telemet > ^^^^^^^^^^^^^^^ This phrase is duplicated. You should probably use "did not" only once. [stf] delete double occurrence Section 7.11.2, paragraph 2 > r-Agents, pledges are more subject to DoS attacks from Registrar-Agents in B > ^^^^^^ It appears that a hyphen is missing in the plural noun "to-DoS". [stf] changed to "DoS-attacks" Section 7.11.2, paragraph 4 > on may be that the pledge does not limited the number of voucher-requests it > ^^^^^^^ The auxiliary verb "do" requires the base form of the verb. [stf] corrected Section 7.11.2.1, paragraph 10 > ystem in an authenticated way. In addition it is required that the Registrar- > ^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "addition". [stf] added comma Section 7.11.2.1, paragraph 13 > ignature on "agent-signed-data". Furthermore the registrar also verifies the > ^^^^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "Furthermore". [stf] added comma [stf] The next set of comments seems to be doubled from the above(Section 7.2, paragraph 4 - Section 7.11.2.1, paragraph 13). Will proceed with the comments to the Appendix Section 7.2, paragraph 4 > R trigger. The registrar MAY consider to ignore any but the newest PER artifa > ^^^^^^^^^^^^^^^^^^ The verb "consider" is used with the gerund form. Section 7.2, paragraph 7 > re-enrollment can be supported in a similar way. In this case, the pledge MAY > ^^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "similarly" to avoid wordiness. Section 7.2.2.2, paragraph 9 > gistrar converts the PVR artifact to an Registrar Voucher-Request (RVR) arti > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". Section 7.3, paragraph 4 > . Depending on policy, the MASA MAY chose the type of assertion to perform. F > ^^^^^ The modal verb "MAY" requires the verb's base form. Section 7.3.1, paragraph 7 > , the domain registrar MUST add an additional JWS Protected Header and JWS Si > ^^^^^^^^^^^^^^^^^^^^^ This phrase might be redundant. Consider either removing or replacing the adjective "additional". Section 7.3.3, paragraph 1 > re 24 depicts exchanges for the PER request handling and the following subse > ^^^^^^^^^^^ In this context, "PER-request" forms an adjective and is spelled with a hyphen. Section 7.3.4.1, paragraph 5 > MUST verify that * the PER was signed signed with the private key correspondi > ^^^^^^^^^^^^^ Possible typo: you repeated a word. Section 7.3.4.1, paragraph 11 > result in a pledge EE certificate singed by the domain owner (e.g., LDevID > ^^^^^^ Are you sure you meant to write "singed" (a synonym for "burnt"), or did you mean "signed"? Section 7.3.5, paragraph 3 > e-enrollment may be supported in a similar way with the exception that the c > ^^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "similarly" to avoid wordiness. Section 7.4, paragraph 16 > ion 6.1.2. The Registrar-Agent MAY stored information from the first connecti > ^^^^^^ The modal verb "MAY" requires the verb's base form. Section 7.5, paragraph 3 > Voucher Status. If the pledge did not did not provide voucher status telemet > ^^^^^^^^^^^^^^^ This phrase is duplicated. You should probably use "did not" only once. Section 7.11.2, paragraph 2 > r-Agents, pledges are more subject to DoS attacks from Registrar-Agents in B > ^^^^^^ It appears that a hyphen is missing in the plural noun "to-DoS". Section 7.11.2, paragraph 4 > on may be that the pledge does not limited the number of voucher-requests it > ^^^^^^^ The auxiliary verb "do" requires the base form of the verb. Section 7.11.2.1, paragraph 10 > ystem in an authenticated way. In addition it is required that the Registrar- > ^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "addition". Section 7.11.2.1, paragraph 13 > ignature on "agent-signed-data". Furthermore the registrar also verifies the > ^^^^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "Furthermore". [stf] Proceeded with comment incorporation here "Appendix B.", paragraph 7 > o create a Pledge-Voucher-Request and an Pledge Enroll-Request. From IETF dra > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". [stf] Was in Appendix C. Corrected but belongs to history of changes, which will be deleted "Appendix B.", paragraph 8 > request to IETF-voucher-request-prm to to allow better listing of voucher rel > ^^^^^ Possible typo: you repeated a word. [stf] Was in Appendix C. Corrected but belongs to history of changes, which will be deleted - The acronym "PRM" is used in the title and throughout the document without an initial definition. Please define it upon first occurrence. [stf] Done already in the Abstract and the Introduction of the draft. - References to sections within the document sometimes use "Section" with a capital "S" and other times with a lowercase "s." Please use it consistently. [stf] double checked the main part of the document. No changes in Appendix C for history of changes - In Section 5.2, the phrase "nomadic connectivity" is misspelled as "nomdic connectivity." [stf] was already corrected - Terms like "bootstrapping phase" and "boot-strapping phase" are used interchangeably. Pick one, probably the latter, and apply it consistently. [stf] aligned to "bootstrapping phase" - Some references to other documents are not uniformly formatted, with variations in the use of brackets and italics. Ensure all references follow the same formatting style per the IETF guidelines. [stf] double checked formatting style - Phrases like "BRSKI-PRM introduces new endpoints for the Domain Registrar and pledge, and a new component, the Registrar-Agent" are repeated in both the abstract and introduction. Consider rephrasing to avoid redundancy. [stf] could not find the indicated repetition - In Section 3.1, lists such as "Building Automation, Infrastructure Isolation Policy, Less Operational Security in the Target-Domain" are presented without commas separating the items. [stf] Not sure I understand the request. What is meant by lists? - Some section headings use title case (e.g., "Supported Environments and Use Case Examples"), while others use sentence case (e.g., "Limitations"). Adopt a consistent captilization style, preferably title case. [stf] changed to title case - Figures and tables are presented without numbering, making them difficult to reference. Number all figures and tables sequentially and provide descriptive captions for each. [stf] double checked the TXT and HTML version in datatracker contain numbers for figures and tables. They were included automatically, based on the MD template we used to create the draft Best regards Steffen Mahesh Jethanandani mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> Mahesh Jethanandani mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
