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

[Rene Struik <[e-mail]>]

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] | Skype: rstruik
cell: [phone] | US: [phone]