Re: [Anima] review of draft-behringer-autonomic-control-plane-00

[Dean Bogdanovic <[e-mail]>]

Rene,

I have another comment to your very detailed review of that draft. This is first bullet in section 6


Secure bootstrap of new devices without requiring any
      configuration.  As explained in Section 3<https://tools.ietf.org/html/draft-behringer-autonomic-control-plane-00#section-3>, a new device will
      automatically be bootstrapped in a secure fashion and be deployed
      with a domain certificate.  This will happen without any
      configuration, allowing a new device to be shipped directly to the
      end-user location without the need for any pre-provisioning.

How is this different from draft-kwatsen-netconf-zerotouch-01?

The zero-touch allows device to be shipped directly from vendor and deployed into the network without any human intervention, except to be installed and wired.

I'm in support of creating autonomic networks, but we have to see what existing mechanisms can be used to that goal and if they need improvements. Would not recommend doing everything from scratch.

Dean

On Sep 17, 2014, at 7:44 PM, Rene Struik <[e-mail]<mailto:[e-mail]>> wrote:

Dear colleagues:

Please find below my initial comments on draft-behringer-autonomic-control-plane-00

1. Summary:
The draft discusses a mechanism for networking that presumably can operate in parallel to ordinary network operation and is able to operate without configuration.

2. General comments:
a) The idea of autonomic control plane relies on group membership notions evidenced by a so-called domain certificate. It is unclear what the ramifications of this approach are, in terms of provisioning, coordination, and pre-planning cost, and in terms of deployment flexibility of devices throughout their lifetime. The notion could possibly work with quite static networks; however, the comparison with other mechanisms for implementing group membership notions require consideration. It is hard to see how this notion could work with more dynamic topologies or where flexible deployment is required. Certificate management aspects (e.g., key validity, revocation) also require lots of attention, as well as manufacturing aspects (should certs be generated during manufacturing) {since one should know where a device will be deployed before issuing the cert}.
b) The autonomic control plane concept seems to require adoption of the concepts in another draft (draft-pritikin-bootstrapping-keyinfrastructures-00) to work.

3. Specific comments:

Section 1:
1) Third para (bottom of p. 1): It would help to elaborate on what "independent of configuration, addressing and routing problems" means. Does this mean one wishes the "autonomic contorl plane" (ACP) protocol to be independent of routing addressing schemes that may be topology-dependent and independent of any routing tables? Please elaborate.
2) First para of p. 2: While the cross-referencing to another draft with common authors (draft-pritikin-bootstrapping-keyinfrastructures-00) is given seemingly simply "as an example", it seems hard to evaluate this draft on its own merits without considering that other cross-referenced draft at the same time. This complicates the review and makes the task of seeing whether certain designs all have to be used simultaneously or not at all, or whether these cover modules that are largely independent arduous. I would prefer untangling of lots of the nmrg drafts, which now
often cross-reference each other. To reach an informed opinion, I had to read them all, rather than being able to read these as drafts that mostly stood on their own. I feel this discourages inviting comments from the community at large.
3) The idea of the autonomic control plane seems to be to similar to the "dry run" option expressed in draft-jiang-config-negotiation-ps-03 (see my general review remark #b on that draft), in the sense that one can run the ACP network in an otherwise operational network. This does sound more like a logical flow separation issue, where the operational network and the "ACP network" version run in "different colors". This could be realized if one could have more than one instantiation of a protocol running at the same time, with logical separation being provided by color coding messaging and configuration data. I can see how this could be realized if one deals with direct neighbors in the "ACP color" (since then routing is effectively non-existent), but had trouble to understand if one wishes to communicate with a more remote "ACP node" (or, more precisely, a node that allows ACP-instantiated traffic). At the same time, at the local non-routing level, can't one already communicate on the local direct neighbor level using existing techniques? (If not, one should explain this in the draft.)

Section 2:
4) First bullet: replace "bootstrapping of a device today" by "bootstrapping of a device today typically" (after all, not all existing networks today require execution of network formation in a carefully preplanned order and with lots of coordination [lots of well-designed sensor networks can form in virtually any order, almost without human intervention]).
5) First bullet: do I have to (sadly) conclude there is absolutely no IETF protocol out there where where network formation can happen in a more organic manner? {sorry - I do not know all the zillions of RFCs by heart.} After all, even if a joining device has to authenticate to the network, any public-key based authenticated key agreement scheme can run over any channel (secured or not), so having UDP and a network sink seems to suffice (can't one use DTLS, here?). This makes me wonder (if my sad conclusion actually does hold) what this bottleneck is: addressing scheme, authorization issues, pure insanity? The current draft, unfortunately, does not elaborate on the current show-stoppers, except to suggest that one somehow needs console access. It would be extremely beneficial to give this more elaborate insight. {This makes me wonder how the internet recovers if one blows part of the network away and tries to reform what is left ("survivability", "failure recovery").}
6) Third bullet: add full-stop at the end of the first line.

Section 3:
7) Section 3.2, second para: replace "an globally" by "a globally".
8) Section 3.2, second para: one should add some verbiage re privacy implications of the adjacency discovery mechanism. (Note: on a more general note, it is hard to find any reference to privacy considerations, tracking, traceability, anonymity in any of the nmrg-related drafts.)
9) Section 3.2, bulletized list: I wonder how any automatic mechanism may derive any notion of "trust" and validity hereof. This should be clarified.(Or, does one simply imply that whatever has a certificate issued by a specific CA is automatically "trusted"??)
10) Section 3.3: this section seems to assume that devices that have a "domain" certificate issued by the same CA are to be mutually trusted. While one can indeed use this (very coarse-grained) mechanism for evidencing membership of the same group ("domain"), this is not a priori provide for autonomic networking, at least not without carefully articulating first how these should be issued, what preplanning and coordination this requires and what the impact is on flexibility of deployment. This should then be compared with alternatives, such as the use of group keys in the example of a network with a network manager who keeps a repository of device identifiers and provides triage on network access via, e.g., a white list.
11) Section 3.3: if one where to use domain identities, these could also be realized via attribute certs, rather than device certs. This would have the advantage of separating the CA role from the domain-mapping role (which could be implemented more locally).
12) Section 3.3: domain certificate validation by itself does not establish group membership (since any device can send this publicly known string); use of the private key (aka "key possession") is required too. I suggest making this more clear in the draft.
13) Section 3.3, p. 5 (last bullet): if checking whether a certificate is invalid or expired requires 3rd party assistance (e.g., to implement OCSP, CRL, or securely synchronize time) this protocol may no longer be autonomic. By group membership depend on CA-issued "domain" certificates, one almost automatically forces this scenario, unless one ignores key validity lifetime issues and issues certs with "eternal life".
14) Section 3.4: one should define the concept of GRE tunnels. Moreover, wouldn't one loose potential interoperability and invite configuration issues by suggesting a plethora of options for establishing and maintaining a secure channel here (IPSec, "GRE tunnels", etc.)?
15) Section 3.5: if one does not wish to depend on link configured addresses, can't one use cryptographically generated addresses instead?
16) Section 3.5: as already said before (see remark #3), it is unclear how routing over more than one hop is realized.
17) Section 3.5: one should explain what 802.1q tags are and which useful functions these could provide in the context of ACP networking.
18) Section 3.6: The main benefit of having an ACP networking options (for "emergency" purposes) seems to be that one does not necessarily need to use lots of configuration that, while useful for routing of ordinary traffic, does not really matter too much for non-throughput/non-time latency optimized communications, such as for network diagnostics by qualified personnel. If correct, I would suggest some verbiage explaining this philosophy in more detail. (Even if incorrect, I would still suggest to add more explanation here.)
19) Section 3.7: It is unclear why one needs another address in ACP context: the "domain" is already in the domain certificate; why can't one use a cryptographically generated address? Why does one need to have the same prefix for all domain devices (since ACP networking is defined from scratch and no routing approach is defined, there does not seem to be any need to stick to IPv6 address formats with 64-bit prefixes (which, again, codifies topology dependent information!).
20) Section 3.8: it is unclear who/what has domain control for propagation of routing information.
21) Section 3.8, top of p. 7: it would be good to add some more background as to why RPL as a routing protocol would be a suitable candidate for autonomic networking, what the dependency is on the addressing scheme suggested in Section 3.7 and whether, e.g., different instantiations of RPL can run at the same time (this would be of interest should one wish to use ACP concept in a constrained network setting that already uses RPL for ordinary networking). As an aside: the RPL specification [RFC 6550] does not include key management functionality, so it would be of interest to see whether what this draft proposes can fill in part of this void...

Section 4:
22) First bullet: it would help to have some insight in case of anomalies, such as "what happens if tables are full".
23) Third bullet: this raises the question as to scope and lifecycle aspects of domain certificates (see also remark #13).

Section 5:
24) second line: replace "been authenticated" by "authenticated" (i.e., remove the second occurrence of "been").
25) second para: one should add some verbiage that denial of service attacks are still possible, since any device can present whichever certificate (a public string) to any other device. See also remark #12 above.
26) third para: the use of link local addresses prevents scalability of ACP beyond a specific topology.
27) third para: the use of domain certificates necessitates re-issuance of certificates once a domain changes.
28) third para: Any device can spoof a link-local address, thereby still presenting the potential to execute attacks (use tunnel to compromised domain node and then inject traffic with seemingly okay looking link-local address, etc., etc.)

Section 6:
29) first bullet: As already said, the use of domain certificates to evidence group membership has some hidden cost that should be elaborated upon in greater detail, in terms of preplanning, coordination, etc. See also remark #10 above.
30) first bullet: the suggestion that the use of domain certificates allows shipment of devices without any need for pre-provisioning seems, unfortunately, incorrect. Au contraire: one needs to decide in which domain a new device should be deployed prior to shipping, issue a certificate for that domain, install this into the device, all prior to shipment. In addition, if one wishes to deploy the shipped device with another domain (i.e., one changes one's mind), one has to re-issue a cert for the new domain. With device certs that are not domain specific, one can simply populate a white list table locally at the network manager and use this white list to arbitrage network access.

Section 7:
31) first sentence: the ACP design heavily depends on a CA that can issue domain-specific certificates and, essentially, administers the network

--
email: [e-mail]<mailto:[e-mail]> | Skype: rstruik
cell: [phone] | US: [phone]

_______________________________________________
Anima mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/anima