Skip to main content

A Reference Model for Autonomic Networking
RFC 8993


(Ignas Bagdonas)

No Objection

(Adam Roach)
(Suresh Krishnan)

Note: This ballot was opened for revision 08 and is now closed.

Ignas Bagdonas Former IESG member
Yes (for -08)

Adam Roach Former IESG member
No Objection
No Objection (for -08)

Alissa Cooper Former IESG member
No Objection
No Objection (2018-10-25 for -08)
Since draft-ietf-anima-bootstrapping-keyinfra is a normative reference in this document, IDevID seems like it should be as well. That is, it seems to be used in a normative way in the same manner as the other normative references in this document. If the document were not going to have any normative references, then I think IDevID could be informative.
Ben Campbell Former IESG member
No Objection
No Objection (2018-10-24 for -08)
Thanks for the work on this. I just have one editorial comment:

- Several sections describe themselves as being for "informational purposes". Given that this is an informational document, isn't that true of all sections?
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2018-10-26 for -08)
Removing my Discuss since the issue is addressed in the latest editor's copy.
For posterity, the discuss point was:

Section 9.2 says:

   An autonomic network consists of autonomic devices that form a
   distributed self-managing system.  Devices within a domain share a
   common trust anchor and thus implicitly trust each other.  [...]

This seems to be a fundamental misstatement of how
trust anchors work.  Sharing a trust anchor means that you are willing to
trust the same entity, the holder of the private key for that trust anchor.
It does not imply any relationship between the two entiteis that trust the
trust anchor.

To be clear,  I think that the authors do understand the actual trust
and security situation here, and the rest of the subsection makes sense; I
just think that this text needs to be changed to make the situation clear
to the reader in an accurate way.

and the original COMMENT (also preserved for posterity):

Section 5

I think it would be good to explicitly mention that in order to provide the
autonomic nature, trust is extremely coarse-grained, in that a device is
either in the PKI, in which case it is (essentially) fully trusted and
authorized for all actions, or it is not in the PKI and totally untrusted.

Section 9.1

I think it's better to say that packets have confidentiality protection
than to say that they are encrypted.

I would also be reluctant to speculate too much about the possibilities for
traffic analysis; as is often said, "attacks can only get better; they
never get worse".
Deborah Brungard Former IESG member
No Objection
No Objection (2018-10-24 for -08)
In discussing the Autonomic Control Plane (section 4.6), it says "is implemented as an overlay network".
"Overlay" in routing documents (e.g. GMPLS) refers to an abstraction of the underlying data layer.
The rtgdir reviewer (Chris) was also confused on the use of "overlay". Is your intention for the
control plane to be independent of the topology of the data plane layer? For GMPLS, where the control
plane and data plane are clearly separated, the control and data planes are said to be "decoupled"
(control plane neighbors may not necessarily be data plane neighbors). Suggest not to use "overlay" if
your intention is for it to be decoupled. If the intention is for it to reflect an (abstracted) connectivity of
the data plane layer than could use '"overlay" though it would be helpful to define what is meant.

Please review Chris's other comments.
Eric Rescorla Former IESG member
No Objection
No Objection (2018-10-24 for -08)
Rich version of this review at:

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

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.
Mirja K├╝hlewind Former IESG member
No Objection
No Objection (2018-10-25 for -08)
One comment: I'm just wondering if there is any insider (or outsider) attack where an attacker node could disconnect all or some other nodes, or at least overload the network such that is would be unusable. Would be nice to see some more discussion about this in the security considerations section!
Spencer Dawkins Former IESG member
No Objection
No Objection (2018-10-24 for -08)
I'm confused here ... 

  This document describes a first, simple, implementable phase of an
   Autonomic Networking solution.  It is expected that the experience
   from this phase will be used in defining updated and extended
   specifications over time.  Some topics are considered architecturally
   in this document, but are not yet reflected in the implementation
   specifications.  They are marked with an (*).

This is true now, but when this document is approved, will it be published immediately (in which case, this is "truth decay", because it becomes less true in the unchanging RFC every time a topic is reflected in implementation specifications), or will it be held until all the (*)s are stable?
Suresh Krishnan Former IESG member
No Objection
No Objection (for -08)