Note: This ballot was opened for revision 08 and is now closed.
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.
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?
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.
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?
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".
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!
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.