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

["Michael Behringer (mbehring)" <[e-mail]>]

Rene, 

Apologies, when I posted draft-behringer-anima-autonomic-control-plane I overlooked this mail, so your suggestions are not yet in this version. I'll take them on in the next version. 

Michael

> -----Original Message-----
> From: Anima [mailto:[e-mail]] On Behalf Of Rene Struik
> Sent: 18 September 2014 01:45
> To: [e-mail]
> Subject: [Anima] review of draft-behringer-autonomic-control-plane-00
> 
> 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]
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima