ANIMA WG, You may have noticed the new version of the ACP draft, which I posted last week (links below).
I’ve now incorporated all “to dos” I had noted. Most comments came from a review from MCR on 30 Nov (see anima list). I have addressed most of them. The ones that I have NOT addressed are below. Some I think we shouldn’t address (adds too much complications), some need more discussion. I have started to add “EDNOTES” into the document to mark places where we need more work. Would like feedback on the new version, and comments on all below topics. Michael Not addressed from Michael Richardson's comments: -- I have heard some say that they would want to enable the ACP on interfaces which were marked Admin Down, with maybe even some kind of auto-negotiate (or auto-guess based upon energy detection) of lambdas. Is it worth saying something in section 4 about this? MB: I think this complicates matters too much – suggest to ignore for now. -- ==== The domain certificate (LDevID) of an autonomic node MUST contain ANIMA specific information, specifically the domain name, and its ACP address with the zone-ID set to zero. This information MUST be encoded in the LDevID in the subjectAltName / rfc822Name field in the following way: anima.acp+<ACP address>@<domain> An example: anima.acp+FD99:B02D:8EC3:0:200:0:6400:[email protected] This puts some pretty clear and pretty strong requirements onto the Registrar, which I think belongs in the bootstrap document. We don't really have a place for this. I will start a new thread about this part. MB: OK, but I leave it for now also in ACP draft. -- 5.1.2: please move this elsewhere, as the table has not yet been defined, and you are already making exceptions to it: Where the next autonomic device is not directly adjacent, the information in the adjacency table can be supplemented by configuration. For example, the node-ID and IP address could be configured. This also seems like an pre-mature optimization: The adjacency table MAY contain information about the validity and trust of the adjacent autonomic node's certificate. However, subsequent steps MUST always start with authenticating the peer. MB: Disagree here, I think we need to cover that, and I don’t see a better place. -- It's true that a full mesh of ACP channels will be built: we ideally need to create some metrix for RPL to use to pick parents. It would be desireable to be aware of the L2 fabric. MB: RPL parameters still need to be addressed. --- You are, I think suggesting having the ANswitchX block forwarding of the ALL_GRASP_NEIGHBOR mcast group. I'm not sure I like this solution. One possible solution to the large number of channels is not to create the IPsec CHILD SA unless needed. This would be possible if the IKEv2 deamon was also the RPL routing daemon, and we did RPL over the IKEv2 layer. Also really sick layer violations :-) MB: This still needs discussion; no change so far. -- 5.2.2: Unfortunately, they [CDP? mDNS?] will also terminate their messages if they do not support the ACP and would then inhibit ACP neighbor discovery Can you explain this? I don't understand what you are saying from the text. Are you saying that an L2 switch that spoke LLDP, but didn't speak ACP would eat the LLDP rather than forward it, and in this case, we want to forward it. (A switch which didn't speak LLDP would just forward it) MB: Re-worded the sentence; please check! -- 5.4: From the use-cases it is clear that not all type of autonomic devices can or need to connect directly to each other or are able to support or prefer all possible mechanisms. For example, code space limited IoT devices may only support dTLS (because that code exists already I claim that any "IoT" device that is "big enough" to participate meaningfully in the ACP is also big enough to support the common protocols other than DTLS. The ACP should be connected lighting controllers, not light bulbs. As for MacSEC vs IPsec, it is my understanding that MacSEC does have a key management protocol defined for it by the IEEE, so really the common situation is that one supports IKEv2 to negotiate if one supports IPsec or MacSEC. As for the two stage process, I don't want to do this. I want to just use IKEv2, and I claim that there will be no people who will say, "I can not live with this". (Of course, some may have other preferences, but preferences does not equal rough consensus) ...Alice must be able to simultaneously act as a responder in parallel for all of them - so that she can respond to any order in which Bob wants to prefer... it's this part that I think is too complex and error prone to code. MB: Not addressed, not clear what needs to change. -- 5.5.3. ACP via dTLS So, it's UDP and then... ? GRE inside UDP? (there is a draft tsvwg-gre-in-udp-encap-19) When Alice and Bob successfully establish the GRASP/TSL session, they will initially negotiate the channel mechanism to use. Yeah, no. Tons of code with no benefit. Who is actually asking for these options? MB: Left it for now, needs discussion. -- 5.5.5. ACP Security Profiles A baseline autonomic device MUST support IPsec and SHOULD support GRASP/TLS and dTLS. A constrained autonomic device MUST support dTLS. if we want to do something for constrained devices, then we should say that they always initiate, that they should join as RPL leafs (so no forwarding of packets), and that they the LWIG version of IKEv2 should be supported, and maybe the diet-ESP mechanisms. We should also be clear if we are trying to support constrained devices, constrained networks, or challenged networks. MB: Left for now. -- I would like V to be at least three bits, maybe 8 bits. In the bootstrap proxy IPIP mechanism, we need to allocate an ACP address for each insecure L2-domain ("port") so that traffic from the Registrar (which inside the IPIP header is v6LL) to get back to the correct link-layer. MB: Needs discussion, not changed yet. -- I have mixed feelings about the 48-bit Registrar ID. I know why you did it, and why you'd want to use 48-bits. (It took two reads to realize it was the Registar's MAC, not the enrolled node's MAC address). So the diagram is really: 48 3 13 48 15 1 +-------------+-+--------+-------------+----------+---+ | hash(domain)|T| ZoneID | Registar ID |Device Num| V | +-------------+-+--------+-------------+----------+---+ Since we never care about the /64 boundary in RPL, since we pass around /128 routes in the ACP, do we care if we've placed the Registar ID here? Clearly it is nice because we have ZoneID as a /64. I'm thinking that I would like to instead do something like: 48 2 46 32 16 +-------------+-+------------+----------+-------------+ | hash(domain)|T| Registar ID|Device Num| V | +-------------+-+------------+----------+-------------+ Where RegistarID is still MAC address derived, with the G and U bits removed, and we now have 2^32 space for devices (I think 2^16 might be too small if one includes CPE devices in the CPE, and one has some churn over a decade+ of CPE devices). There is now 16 bits available to do things, and we can pass /114 routes around in RPL, btw. I'm open as to whether V remains as a specified bit, or if "physical" machine is just V=0x0000. If we need ZoneID, then I suggest that we can easily get it by having different Registrar IDs for each zone. If you want them in different /64s then just construct the RegistarID to be unique in the upper 14 bits. MB: This needs more discussion. The above proposal adds up to 144 bits, which doesn’t fit into an IPv6 address ;-) I added an EDNOTE in the draft for now. -- 5.8.4: If a device learns through an autonomic method or through configuration that it is part of a zone, it MUST also respond to its ACP address with that zone number. In this case the ACP loopback is I don't like this, because it seriously breaks up the aggregation that might otherwise be possible. I don't want explicit ZoneID, I'd rather go with the Note: in 5.8.4, or use the RegistrarID. MB: Disagree here. Aggregation is possible, because the device must listen to both. -- 5.10: When we establish multiple ACP channels RPL (or any other routing protocol!) will need to have some metrics to pick among them. I'm not sure what we can provide here, at the least, we should prefer shorter paths to longer ones. MB: Our pre-standard implementation treats all ACP links equal, and let’s RPL do its work. No metrics are required. -- If an autonomic node decides to have a limit on how many channels it sets up, or how many it will setup with a particular peer, it SHOULD indicate a clear "thanks, I'm full" message in the ACP channel negotiation protocol (i.e. an IKEv2 Notification). MB: Suggest to leave that for later optimisations. It will lead to incomplete overlays and open a set of new questions. For the first phase we should just state “one link --> one ACP channel”. -- -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: 12 January 2017 18:34 To: Michael Behringer (mbehring) <[email protected]>; [email protected]; Toerless Eckert <[email protected]>; Steinthor Bjarnason <[email protected]>; Michael Behringer (mbehring) <[email protected]> Subject: New Version Notification for draft-ietf-anima-autonomic-control-plane-05.txt A new version of I-D, draft-ietf-anima-autonomic-control-plane-05.txt has been successfully submitted by Michael H. Behringer and posted to the IETF repository. Name: draft-ietf-anima-autonomic-control-plane Revision: 05 Title: An Autonomic Control Plane Document date: 2017-01-11 Group: anima Pages: 34 URL: https://www.ietf.org/internet-drafts/draft-ietf-anima-autonomic-control-plane-05.txt Status: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ Htmlized: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-05 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-05 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines an "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out of band channel" for OAM communications over a network that is not configured, or mis-configured. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
