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

From: Rene Struik <[email-masked]>
Date: Wed, 17 Sep 2014 19:44:50 -0400

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: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 30 Sep 2014 19:19:51 +0000

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 <[email-masked]<mailto:[email-masked]>> 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: [email-masked]<mailto:[email-masked]> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Oct 2014 08:43:12 +1300

Dean,

It goes without saying that before the proposed WG group adopts
any particular solution, existing solutions have to be reviewed
as part of the decision process. That applies quite generally of
course, not just to this particular functionality.

So I'm agreeing with you that we need to consider
netconf-zerotouch as part of the potential solution set. Whether
it is *the* solution for anima is a discussion for the future.

We (the IETF in general) shouldn't solve the same problem more
than once, if we can avoid it.

Regards
   Brian

On 01/10/2014 08:19, Dean Bogdanovic wrote:
> 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 commun
icate on the local direct neighbor level using existing techniques? (If not, one should explain this in the draft.)
> ------------------------------------------------------------------------
> 
> [email-masked]