Subject: [Anima] Eric Rescorla's No Objection on draft-ietf-anima-reference-model-08: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2018 06:40:26 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-anima-reference-model-08: No Objection

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

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

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

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3602

COMMENTS
S 2.
>      +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
>      :                Autonomic Networking Infrastructure               :
>      +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
>      +--------+   :    +--------+   :    +--------+   :        +--------+
>      | Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n |
>      +--------+   :    +--------+   :    +--------+   :        +--------+

This diagram is kind of hard to follow. You say ASAs are instantiated
on nodes, but these ASAs don't seem to be attached to any particular
nodes.

S 4.3.
>   
>   4.3.  Discovery
>   
>      Traditionally, most of the information a node requires is provided
>      through configuration or northbound interfaces.  An autonomic
>      function should rely on such northbound interfaces minimally or not

is "northbound" a synonym for "configuration"?

S 6.1.
>      Thus we can distinguish at least three classes of ASAs:
>   
>      o  Simple ASAs with a small footprint that could run anywhere.
>   
>      o  Complex, possibly multi-threaded ASAs that have a significant
>         resource requirement and will only run on selected nodes.

This is kind of nitpicking but there are plenty of languages where
multithreading is natural even in simple programs (e.g., Rust or to
some extent Go).

S 6.1.
>      components.  Also, they may be coded in a variety of programming
>      languages, in particular including languages that support object
>      constructs as well as traditional variables and structures.  The APIs
>      should be designed with these factors in mind.
>   
>      It must be possible to run ASAs as non-privileged (user space)

You probably don't want parentheses here. non-privileged and user
space are different thigns.

S 6.1.
>      negotiation failures must be treated as routine, with the ASA
>      retrying the failed operation, preferably with an exponential back-
>      off in the case of persistent errors.  When multiple threads are
>      started within an ASA, these threads must be monitored for failures
>      and hangups, and appropriate action taken.  Attention must be given
>      to garbage collection, so that ASAs never run out of resources.

Hmm.... This is PL nitpickery again, but many languages don't have
garbage collection. Perhaps you mean "memory management"

S 9.1.
>   
>      Here, we assume that all systems involved in an autonomic network are
>      secured and operated according to best current practices.  These
>      protection methods comprise traditional security implementation and
>      operation methods (such as code security, strong randomization
>      algorithms, strong passwords, etc.) as well as mechanisms specific to

"randomization" is a term of art here that means that the algorithms
are randomized (as in randomized hashing) not that you generate strong
random numbers.

S 9.1.
>      valuable information about network configuration, security
>      precautions in use, individual users, and their traffic patterns.  If
>      encrypted, AN messages might still reveal some information via
>      traffic analysis, but this would be quite limited (for example, this
>      would be highly unlikely to reveal any specific information about
>      user traffic).

Don't bet on this. Traffic analysis is very powerful.

S 9.2.
>         AN or other protocols.  Also this is a generic threat that applies
>         to all network solutions.
>   
>      The above threats are in principle comparable to other solutions: In
>      the presence of design, implementation or operational errors,
>      security is no longer guaranteed.  However, the distributed nature of

This isn't obvious to me. The issue here is that control of one non-
privileged device might let you affect others. That wouldn't be true
of centrally managed systems.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Oct 2018 11:15:27 +1300

Thanks Eric, all good points. On one bit that I drafted:
On 2018-10-25 02:40, Eric Rescorla wrote:
...
> multithreading is natural even in simple programs (e.g., Rust or to

True. I wrote the GRASP prototype in multithreaded Python, but low end
nodes might well run a subset and only have a C/C++ run time. We're
not trying to be categorical here, just to show there's a range of
possibilities.

     Brian