Re: [dtn] [EXT] Roman Danyliw's Discuss on draft-ietf-dtn-dtnma-10: (with DISCUSS and COMMENT)

["Birrane, Edward J." <[e-mail]>]

Roman,

  Thank you for the review of this document.  I have included replies/recommendations in the text below.   To help with the discussion, I have enumerated discuss points prefaced with EJB_D# and comments prefaced with EJB_C#.

  Please let me know if the recommended actions described below would address the discusses and comments from your review.

-Ed

---
Edward J. Birrane, III, Ph.D. (he/him/his)
Chief Engineer, Space Networking
Space Systems Implementation Branch
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
  

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> ** The text would benefit from a refinement of the explanation of the
> security
> boundary of the DTNMA.
> 
> Consider the following statements:
> (a) Section 1.1 says “Network features such as naming, addressing, routing,
> and
> security are out of scope of the DTNMA.  It is presumed that any operational
> network communicating DTNMA messages would implement these services
> for any
> payloads carried by that network.”
> 
> (b) Section 4.7 says “The DTNMA does not require a specific underlying
> transport protocol, network infrastructure, or network services.  Therefore,
> mechanisms for authentication, authorization, and accounting must be
> present in
> a       standard way at DAs and DMs to provide these functions if the
> underlying network does not.”
> 
> (c) Section 7.3.2.3 says “DAs should ensure, when possible, that externally
> generated data values have the proper syntax (e.g., data type and ranges)
> and
> any required integrity and confidentiality.
> 
> -- Statement-(a) seems to rule out elements of security as being part of
> DTNMA.
>  However, the text subsequently makes various statements about DTNMA
> ensuring
> security properties (e.g., statement-(b) and statement-(c))

EJB_D1: Agree that discussion on security boundaries should be refined.  We recommend correcting the text as follows:  Statement-(a) should be updated to say "communications security" instead of "security" to emphasize that this statement is related to comsec considerations such as those provided by a transport protocol.  Statement-(b) should be updated to refer only to authorization and accounting. Statement-(c) should be refined to remove reference to integrity and confidentiality as it is already covered in prior statements.

EJB_D1: Generally, to make a pass through the document to ensure that any specific referenced to authentication, integrity, security are unambiguously in agreement with Statement-(a).

 
> -- In clarifying this scope, can the distinction between the DTNMA and the
> “operational network communicating DTNMA” or a “DTNMA
> implementation” be
> explained?  Is the operational network part of the architecture? Is an
> implementation an instantiation of the architecture?  I ask because the
> following statements also seem to discuss security properties:
> 
> Section 8.5 says “It is expected that transport protocols used in any DTNMA
> implementation support security services such as integrity and
> confidentiality.”
> 
> Section 12 says “As such, security at the transport layer is expected to
> address the questions of authentication, integrity, and   confidentiality.”


EJB_D2: Agree that these statements introduce scope ambiguity as worded. Recommend correcting the text by removing these statements as they are restatements of not-ambiguous information already present elsewhere in the document. Generally, these statements do not intend to alter the meaning of the statements highlighted in EJB_D1.

 
 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ** Section 1.
>       |  NOTE: These challenges may be caused by physical impairments
>       |  such as long signal propagation and frequent link disruption,
>       |  or by other factors such as quality-of-service prioritization,
>       |  service-level agreements, and other consequences of traffic
>       |  management and scheduling.
> 
> Could these challenges be caused by an active attacker too?

EJB_C1: Agree that these challenges can also be caused by an attacker (as well as misconfiguration). Recommend updating the text to add those to the list in this aside.


> ** Section 1.* What is intent on describing the relationship between DTNA
> and
> BP?  There seem to be multiple slightly different statements.  Specifically:
> 
> -- Section 1.0 says “However, the DTNMA should operate in any environment
> in
> which the Bundle Protocol (BPv7) [RFC9171] is deployed.”
> 
> -- Section 1.1 says “The fact that the DTNMA must operate in any
> environment
> that deploys BP does not mean that the DTNMA requires the use of BP to
> operate.”
> 
> --  Section 4.1 says “The DTNMA must run in every environment in which BP
> bundles may be used, even though the DTNMA does not require the use of
> BP for
> its transport.”
> 
> Is it intentional for the first statement to be weaker statement than the
> second and third.


EJB_C2: Agree that the terminology here needs to be clarified. Section 1.0 is intended to be the strongest statement of the three. Recommend changing the wording in Section 1.0 to "the DTNMA needs to be able to operate...".  Recommend changing the wording of both Sections 1.1 and 4.1 to replace the word "must" with the word "can".  As an informational document there is no intent to use (or imply) normative language here. 

> ** Section 2.  Editorial. Consider harmonizing the implicit definition of DTN
> management from Section 1 with the one used here.
> 
> -- Section 1 says “Device management in these environments must occur
> without
> human interactivity, without system-in-the-loop synchronous function, and
> without requiring a synchronous underlying transport layer.”
> 
> -- Section 2 (here) says “DTN Management: Management that does not
> depend on
> stateful connections, timely data exchange of management messages, or
> closed-loop control.”
> 
> e.g., “system-in-the-loop synchronous function” vs. “closed-loop control”

EJB_C3: Agreed.  Recommend changing the text in Section 2 to adopt the wording from Section 1.


> ** Section 2.
>    *  Data Report Schemas: Named, ordered collection of data names that
>       represent the schema of a Data Report.
> 
> What are “data names”?  I would have expected a data schema to define the
> format and semantics of the fields of a data report.

EJB_C4: Agree that the term "data names" is ambiguous and recommend correcting the text to say "data elements" instead.


> ** Section 3.1
>    *  The existence of external infrastructure, software, systems, or
>       processes such as a Domain Name Service (DNS) or a Certificate
>       Authority (CA) cannot be guaranteed.
> 
> What is “external software”?

EJB_C5: Agreed that this is confusing.  This is supposed to refer to external services. Recommend correcting the text to say "services" instead of "software".

> ** Section 4.1.
>       |  NOTE: The DTNMA must run in every environment in which BP
>       |  bundles may be used, even though the DTNMA does not require the
>       |  use of BP for its transport.
> 
> I don’t understand the constraint/requirement this statement is making.
> What
> governs where “BP may used”?  Couldn’t that be “everywhere” meaning the
> DTNMA
> needs to also run “everywhere”?

EJB_C6: Agree, but believe this would be addressed with the recommended corrections related to the DISCUSSes. 

 
> ** Section 4.4.  This section seems very vague to the degree of not provide
> actionable design guidance. How “efficient” is an encoding seems light it
> might
> depend entirely on the deployment environment.  It also appears that that
> there
> are assumption being made about hardware capabilities (or lack thereof)
> when
> discussion the complexity of encoding or use of compression.

EJB_C7: We believe that there is value in some discussion relating to these concerns even absent specific design guidance, which we would expect to be represented in subsequent, non-informational documents. Recommend keeping this section. 

> ** Section 4.4
>    There is no advantage to minimizing node processing time in a
>    challenged network.
> 
> Is there sometimes a relationship between processing time and power use?
> Isn’t
> power usage relevant in challenged networked?

EJB_C8: Agree that this sentiment is implementation and system specific, and not relevant to the DTNMA itself. Recommend updating the text to remove this paragraph. 

> ** Section 4.4
>       Design strategies for
>       |  compact encodings involve using structured data instead of
>       |  large hash values, reusable, hierarchical data models, and
>       |  exploiting common structures in data models.
> 
> Doesn’t the advice here to not use “large hash values, reusable hierarchical
> data models …” conflict with the guidance in Section 4.2 (“Data models in the
> DTNMA should allow for the construction of both cohesive models and
> hierarchically related models.”)

EJB_C9: The intent of this note is to encourage structured data, hierarchical data models, and common structures and to discourage (only) very large hash values. This is not clear from the use of commas in this sentence. Recommend clarifying the meaning of this note with less ambiguous language.

> ** Section 4.5
> 
>    Elements within the DTNMA should be uniquely identifiable so that
>    they can be individually manipulated.
> 
> -- What is the relationship between then “element” defined here and a
> “managed
> device” used in previous definitions?
> 
> -- Didn’t Section 1.1 says “Network features such as naming ... are out of
> scope of the DTNMA.”

EJB_C10: Agree that the use of the term "element" here is ambiguous. In this context element refers to a data element. Recommend correcting the text to say "Data elements..." instead of "Elements..."   Also recommend a pass through the document to clarify any other ambiguous uses of the term "element".

 
> ** Section 4.5.  Per the algorithm on approximating an associative array
> lookup, I would have benefit from more text that explained why a universal
> ID
> would have helped the situation.

EJB_C11: Agreed that additional text can be added to clarify this example, and recommend adding that text to the example.

> ** Section 4.6.  Is the run-time data definition just a design consideration of
> the schemas being used?

EJB_C12: This text is not meant to imply switching amongst schemas during runtime. The goal here is to dynamically add data elements to the local runtime schemas as needed - such as the definition of new counters, new reports, or new rules. Recommend adding a sentence at the start of this section to clarify. Recommend no change to this section. 

> ** Section 4.7.  I had trouble understanding the thesis of this section.  Can
> the difference between “stand-alone”, “deterministic” and “engine-based”
> behavior be clarified?  For example, what is the difference between the
> engine-based behavior having “configurable behavior” without mobile code
> and
> stand-along operation having “pre-configuration [which] allows DAs to
> operate
> without regular contact with other nodes?

EJC_C13: "Stand-alone", "deterministic" and "engine-based" are intended to describe complementary aspects of DA functions, so there may be some overlap in the descriptions because they work together. For example, "stand-alone operation" with pre-configuration can be achieved with engine-based behavior when the pre-configuration is a pre-configuration of the engine.  Recommend no change to this section. 


> ** Section 4.7
> 
>       |  NOTE: The deterministic automation of the DTNMA can monitor and
>       |  control AI/ML management applications on a managed device.
>       |  Using multiple levels of autonomy is a well-known method to
>       |  balance the flexibility of a highly autonomous system with the
>       |  reduced risk of a deterministic system.
> 
> I can’t tell if this is an aspiration or required design property of a system.
> Can such confidence be asserted generically (i.e., The deterministic
> automation
> of the DTNMA can monitor and control AI/ML management applications on a
> managed
> device)?  I recommend removing this aside.

EJB_C14: This is not intended to be a required design property of the system, and only an observation. Since this is an aside and not necessary for DTNMA in general or the section in particular, recommend removing this aside.

> ** Section 7.3.2.2.
>       The
>       generation of a report is independent of whether there exists
>       any connectivity between a DA and a DM.  It is assumed that
>       reports are queued on an agent pending transmit
>       opportunities.
> 
> What part of the DA is responsible for sending the Reports?
> 
> I observer that Section 7.3.4.2 describing the DM has: “Report Collectors DMs
> receive reports from DAs in an asynchronous manner. Should there be
> symmetry?

EJB_C15: The generation of a report (in this Report Generation section) occurs independent of whether there exists any connectivity between a DA and a DM. It is assumed that the reports, once generated, are provided to some transport function. The use of the term "send" for reports that might be buffered/stored was avoided so as to not imply immediate transmission. Recommend clarifying that the "Report Generator" function generates reports and provides them to whatever local mechanism takes responsibility for their eventual transmission.

> ** Section 7.3.2.
>        DAs should
>        ensure, when possible, that externally generated data values
>        have the proper syntax (e.g., data type and ranges) and any
>        required integrity and confidentiality.
> 
> -- Is this assurance of integrity and confidentiality before it is pushed to
> the DM? -- Are there authenticity checks?

EJB_C16: The use of the term integrity and confidentiality here is not needed. Recommend removing these terms to avoid confusion and updating the sentence to read "..have the proper syntax and semantic constraints (e.g., data type and ranges) and any required authorization."

> ** Section 8.5
>    It is expected that
>    transport protocols used in any DTNMA implementation support security
>    services such as integrity and confidentiality.
> 
> Is authenticity a relevant security property?  I ask because Section 12 says “…
> security at the transport layer is expected to address the questions of
> authentication, integrity, and confidentiality.”?

EJB_C17: Agreed. Recommend updating section 8.5 to match section 12.

> ** Section 9.1
> 
>    Determinism allows for the forensic reconstruction of device behavior
>    as part of debugging or recovery efforts.
> 
> Isn’t determinism also important to ensure predictable behavior?

EJB_C18: Agreed. Recommend updating the text to list this as another benefit.

> ** Section 9.1
> 
>       |  NOTE: The use of predicate logic and a stimulus-response system
>       |  does not conflict with the use of higher-level autonomous
>       |  function or the incorporation of machine learning.  The DTNMA
>       |  recommended autonomy model allows for the use of higher levels
>       |  of autonomous function as moderated and controlled by a more
>       |  deterministic base autonomy system.
> 
> …
>    The DTNMA autonomy model is a rule-based model in which individual
>    rules associate a pre-identified stimulus with a pre-configured
>    response to that stimulus.
> 
> I am having trouble following what multi-tiered autonomy system is being
> referenced here and where that fits in the DTNMA.  Is that a DA or a DM?
> The
> text below the notes seems to make a statement that the DTNMA autonomy
> model is
> rule based.

EJB_C19: The DTNMA may be used to manage both applications and network services on a managed device (from the introduction). This note is meant to address that the use of other autonomy models (outside of the DTNMA) can also be used for the management of application and network services on a managed device. And that the use of such other autonomy models is not, necessarily, a conflict with the rule-based autonomy provided by the DTNMA. Recommend clarifying this point in the aside. 

> ** Section 12.
> 
> -- Would the data validation role played by the DA (Section 7.3.2.3) be
> critical to mention here as this would drive action in the “agent autonomy
> engine”?

EJB_C20: Agree (and this might be resolved by EJB_C16). Recommend updating this text to add that data validation is important here. 

> -- Section 3.2.1 mentions “support a many-to-many association amongst
> managing
> and managed device”.  Is that handled by pre-provisioning or is there some
> kind
> of authorization and authentication model where a managed device can
> always
> determine who is authorized to manage it?

EJB_C21: This informational document does not provide a mechanism for this. Section 7.3.2.2. does mention caveats for multiple managers, and section 8.5 discusses an authorization service but a specific mechanism is not provided.