[Anima] AD review of draft-ietf-anima-brski-prm-15

Mahesh Jethanandani <mjethanandani@gmail.com> Wed, 25 December 2024 08:14 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76242C14F60A; Wed, 25 Dec 2024 00:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtIXWEzZuQys; Wed, 25 Dec 2024 00:14:04 -0800 (PST)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C804C14F70A; Wed, 25 Dec 2024 00:14:04 -0800 (PST)
Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-2ef72924e53so6098043a91.3; Wed, 25 Dec 2024 00:14:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735114443; x=1735719243; darn=ietf.org; h=to:cc:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=czcjU46OlDlzZG343WA/npTMkeYhEvY70kqWI1YpDzI=; b=jNY3TaTwxrCZP3gFO3+wM+TJRie9htCVBbFq/0nl6CPJytZkV5wG84vffsC6LA5DWy 51S01zc8wAXinXFnGcK1Cy4cg8rK9ZNbdM5Lb8+b64ELtG6W9ZaITUZYxGNgaByu0oEH 7702W7dY0cQdnWovQtwjRs7D/4mhMgq+P+MWgxdbfIELsnxqf3nNwL0sGv71F7QVQRl0 zClFL74UMhw0PqtYQD/SmqGQI3FQwMrYd+rMgsLad5x67+sOgHMl/f8s7W3BWgcq45fR uICNFpky7pxx491nJaC9ycMj69Ig4UN5YyfmlcRsV55rWtlSwsOJGClzT8fNWSFpcHXZ U4/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735114443; x=1735719243; h=to:cc:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=czcjU46OlDlzZG343WA/npTMkeYhEvY70kqWI1YpDzI=; b=VA1V+VMIateqlTCEus/e3nJTw+wn/RveBkkjC5ln9shIbfc+BhzhaxPQk8I4GWD8tq 7k/ckETvGjliduFvIDeqAG9lYX79qDaknL8hNd+J9ygOEslSwLhIoPqflJC6yvFTPp8e xbduJrs4g7AtBjLbKzcdlH1Hiwqya2jMq5ufTZU2EWZNtpAPjy6b0A91rVKTceuHK0i5 ht3/00mFh7eCjzRDPa2EXFvTarmHDEIXWzd3vgjNaSYtZCrO+ZkP+2389bMeV5In6IUE oJNeyjwt4N4NVt2h+qBlkA+amsnj77E4dOVvtZxnrGYUjbQnri5f1H8M3JN89WlXFyPh LQPw==
X-Gm-Message-State: AOJu0YyGBRjWu7SBKG3Jbx3Nn27HUKm/yhNXmTfcKmv031cefMWkgYDN BnpwqOpHYI2ALMoI8Na5bhSb7kF7VD5PL1wmyROJVjA2cRB7CN2K/Us+EhFdDJA=
X-Gm-Gg: ASbGnctf6i5ecGgOcjicLRLbVZSTotM7Xyxnlr6rjua3jUQUoUnKbeKBTgW6Rq/aR0B shlRtl+4rDMo4FI2e5OG2VAXVCbankdww21gYOqDiUy1d70yt754uPThgfohnbhPg0XXwAWgIbh MooAx9ENnJBgaKbhOOVTtYyrikDeVPO5DTdS3l2K/3lheSNX7uF5LmltjgEct+1IWKjq78sWQGR mbioeHNBMe4WUlAels6xkC5XOKZErxprCdm/oWQOSCmSkObJkMn/l6ThdEsGBbgOE6OBPEhOdRw M3T3Y5efI8T1
X-Google-Smtp-Source: AGHT+IHYH4DhMJnvdyJ1XaBnDgIsNrkyvN9vXAYFw/bb24Pf6faDHLQXL4Olw/RUpQetW5OK91iEXQ==
X-Received: by 2002:a17:90b:2b86:b0:2ee:edae:75e with SMTP id 98e67ed59e1d1-2f452e0a44dmr28541052a91.13.1735114442667; Wed, 25 Dec 2024 00:14:02 -0800 (PST)
Received: from smtpclient.apple ([2405:201:400b:7190:edc9:43cc:6398:707f]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-842aba7310bsm8402603a12.1.2024.12.25.00.14.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Dec 2024 00:14:02 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_25DF758D-D266-44D1-BDB0-964AD6E8A3E6"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\))
Message-Id: <F55918B1-39DE-4700-90B0-D0C77342566A@gmail.com>
Date: Wed, 25 Dec 2024 13:43:58 +0530
To: draft-ietf-anima-brski-prm@ietf.org
X-Mailer: Apple Mail (2.3654.120.0.1.15)
Message-ID-Hash: PA6PHGULB3UPA2EBX7O53KLWUAOQH5KT
X-Message-ID-Hash: PA6PHGULB3UPA2EBX7O53KLWUAOQH5KT
X-MailFrom: mjethanandani@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-anima.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: anima@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Anima] AD review of draft-ietf-anima-brski-prm-15
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/-4ZBEHeoaxyW5xJZc86Hc1cnNbE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Owner: <mailto:anima-owner@ietf.org>
List-Post: <mailto:anima@ietf.org>
List-Subscribe: <mailto:anima-join@ietf.org>
List-Unsubscribe: <mailto:anima-leave@ietf.org>

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.

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.

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.

Figures and Diagrams:

The architectural diagrams could be more detailed, especially to clarify the interaction between components (Pledge, Registrar Agent, Registrar).

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.

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.
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.

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].

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"
 * 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"

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.

Document references draft-ietf-netconf-sztp-csr, but that has been published as
RFC9646.

Document references draft-ietf-anima-jws-voucher-10, but -14 is the latest
available revision.

Document references draft-irtf-t2trg-taxonomy-manufacturer-anchors-03, but -04
is the latest available revision.

Document references draft-ietf-anima-brski-ae-12, but -13 is the latest
available revision.

Document references draft-ietf-anima-brski-discovery-04, but -05 is the latest
available revision.

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".

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”.

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.

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.

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”.

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”.

"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".

"Appendix B.", paragraph 8
> request to IETF-voucher-request-prm to to allow better listing of voucher rel
>                                     ^^^^^
Possible typo: you repeated a word.

- The acronym "PRM" is used in the title and throughout the document
  without an initial definition. Please define it upon first
  occurrence.

- References to sections within the document sometimes use "Section"
  with a capital "S" and other times with a lowercase "s." Please use
  it consistently.

- In Section 5.2, the phrase "nomadic connectivity" is misspelled as
  "nomdic connectivity."

- Terms like "bootstrapping phase" and "boot-strapping phase" are used
  interchangeably. Pick one, probably the latter, and apply it
  consistently.

- 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.

- 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.

- 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.

- 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.

- Figures and tables are presented without numbering, making them
  difficult to reference. Number all figures and tables sequentially
  and provide descriptive captions for each.


Mahesh Jethanandani
mjethanandani@gmail.com