Subject: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-asa-guidelines-05: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 18 Jan 2022 18:14:00 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-anima-asa-guidelines-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-asa-guidelines/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 3.1 and 3.2.

(a) (Section 3.1) “… the secure bootstrap process itself may include
special-purpose ASAs that run in a constrained insecure mode.”,

(b) (Section 3.2) “ … the ACP formation process itself may include
special-purpose ASAs that run in a constrained insecure mode.”

What is meant by “special-purpose” (i.e., how is that different than an ASA
that isn’t special purpose) and what are the security properties of a
“constrained insecure mode”?  Is this text saying that the secure bootstrapping
and ACP formation might not always be done securely?

(b) reads like it could be DULL-GRAP (Section 2.5.2 of draft-ietf-anima-grasp)
but it isn’t clear.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 6.  Would the ASA lifecycle presented here need to consider resale,
transfer or decommissioning of equipment on which the ASA runs?  I’m
specifically thinking of the broader considerations discussed in BRSKI.  For
example, should there be primitives to purge the ASA configuration, key
materials, or logs?

** Section 6.1.  Is there any integrity and authenticity checking before the
ASA software is installed?

** Section 6.1.1.
The condition to validate in order to pass to next phase is to ensure
   that [list of ASAs] are well installed on [list of Installation
   Hosts].

What does it mean to be “well installed”?

** Section 6.1.1
   A minimum set of primitives to
   support the installation of ASAs could be: install(list of ASAs,
   Installation_target_Infrastructure, ASA placement function), and
   uninstall (list of ASAs).

Would an explicit primitive for checking if an ASA is already installed be
needed – that is, how does one deal with an install() if the ASA is already
installed?

** Section 6.2.
   First, there is a difference between (1) having a
   piece of code available to run on a host and (2) having an agent
   based on this piece of code running inside the host.

I don’t follow the text for (1).  (1) seems to be roughly the definition of the
previously described installation phase (Section 6.1).  What is the difference
being suggested for this phase?

** -- Section 6.2.3.
The specification of such an
   ASA Instance Mandate is beyond the scope of this document.

It caught my attention that the specification of “ASA Instance Mandate” was
explicitly called out as being out of scope for this document.   No issue with
that.  However, so many of the other terms are also out of scope.  For example,
“Set of ASAs – Resources relations” and “Instantiation_target_parameters”

** Section 8.
  If a newly received or calculated value for a parameter falls
  out of bounds, the corresponding parameter should be either left
  unchanged or restored to a safe value.

Is that safe value likely to be contextual to the environment in which the ASA
is deployed?

** Editorial

-- Section 6.1.1.  Editorial.  Why does “[Installation_target_Infrastructure]
have both hyphens and capitalizes “Infrastructure” while “[ASA of a give type”
and [ASA placement function] doesn’t have hyphens and only capitalized the
first word?

-- Section 6.1.1.  Editorial. A forward reference or earlier definition of
“decoupled mode” would have been helpful.  It is defined in Section 6.2.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Jan 2022 16:02:25 +1300

Roman,

Thanks for the review, responses in line.
On 19-Jan-22 15:14, Roman Danyliw via Datatracker wrote:
...

No, the point is that they are secure *because* only a constrained subset 
of
GRASP is available. It's badly phrased.
  
> (b) reads like it could be DULL-GRAP (Section 2.5.2 of draft-ietf-anima-grasp)

Yes, both are DULL-GRASP use cases in fact and are properly described in
RFC8994 and RFC8995. We clearly need to make these two sentences much less
obscure, as I already replied to Éric. Or we could delete them, since they
are a distraction from the main argument.

That seems like a factor to be considered; maybe just an option during
"uninstall", which we don't describe in detail.

> ASA software is installed?

There certainly should be. We should add a note.

> What does it mean to be “well installed”?

Nothing. We'll delete "well".

> needed – that is, how does one deal with an install() if the ASA is already

Certainly a complete system would have to deal with versioning. We didn't
intend to describe a complete system here (that would be a whole other draft
IMHO) so probably we should clarify early in the section that this is only an
outline.

> being suggested for this phase?

I see your confusion. The sentence you quote might actually be redundant,
and at the minimum it needs to be rephrased.

> “Set of ASAs – Resources relations” and “Instantiation_target_parameters”

OK, we should clarify.
  
> Is that safe value likely to be contextual to the environment in which the ASA

Very possibly. It really is use-case dependent. (E.G. the max RF power output
of a base station might depend on national regulations, so the default value
could not be a factory default.)

> and [ASA placement function] doesn’t have hyphens and only capitalized the

Will aim at consistency.

> “decoupled mode” would have been helpful.  It is defined in Section 6.2.

Ack

Thanks,
      Brian