Inline On Sat, Jul 09, 2016 at 05:25:10AM +1200, Brian E Carpenter wrote: > Hi, > > I have one big issue with this version, and a few other comments below. > > > 5.2. Neighbor discovery via mDNS/DNS-SD > > > > Autonomic devices use DNS-SD/mDNS to discover the IPv6 link-local > > address of autonomic neighbors across L2 adjacencies. The result is > > stored in the AN Adjacency Table, see Section 5.1.2. > > Why? We have carefully designed GRASP discovery so that it could do this. > While I understand that bootstrap wants to use mDNS/DNSSD to cover the case > of non-AN devices, the ACP by definition is only active in AN devices which > will all support GRASP by definition. > > There are two arguments hidden in the change log that seem spurious to me: > > > Bootstrap > > protocol team decided to go with mDNS to discover bootstrap proxy, > > and ACP should be consistent with this. > > Why? ACP should also be consistent with the rest of Anima. That's > a magical argument, not a technical one. > > > ... b) Using GRASP both for the > > insecure neighbor discovery and secure ACP operatations raises the > > risk of introducing security issues through implementation issues/ > > non-isolation between those two instances of GRASP. > > Firstly, as mentioned again below, there may indeed be no isolation > because the implementation may use internal modes, not separate > instances. But the argument is empty: the fact that discovery requests > are public (unsecured link-local multicast) doesn't make GRASP itself > vulnerable. Discovery responses can be secured by GRASP/TLS as soon > as bootstrap has occurred. > > I think this is the completely wrong approach for Anima. > (As I said in another message, making mDNS/DNSSD mandatory-to-implement > for bootstrap is reasonable, but bootstrap needs to support > GRASP discovery as well, to allow "100 pure Anima" deployments.)
I hope that we have all the folks in Berlin in the room to get to better rough consensus on this. I was just writing into this version of the ACP draft what seemed to be best aligned with the choices the current bootstrap draft has made, but: a) I did vote for GRASP in the bootstrap meetings but was the only one. b) I always wanted to make sure that bootstrap can be adopted by non-anima solutions that wouldn't use ACP. mDNS might be an easier sell there. c) Interpreting your text above seems to point to the option that the bootstrap draft could say that bootstrap used for an anima solution must use Grasp, and used outside of an anima solution should support mDNS ... does that sound like a good compromise ? d) My preference of isolation is based on concepts i understand. I don't think that you need "separate protocols" for isolation. I understand how "instances" create very clear isolation independent of the protocol choosen. I am still not clear about your "mode" concept, hopefully i can "grasp" that in berlin. e) The more complex the protocol is, the more attack vector i fear (FUD) it may have. Even though the discovery needed for anima is simple, mDNS is quite feature rich, and if the argument is to share a pre-existing mDNS library, then that makes me worried (admittedly FUD!). Simple example: Alice wants to discover bootstrap proxy, Bob is bootstrap proxy, but Dos (3rd device on Lan), responds with misleading responses about Bobs services. How well would a randomn "pre-existing" mDNS library be able to ignore Dos. How well could we specify Grasp to do this. > > anima.acp+FD99:B02D:8EC3:0:200:0:6400:[email protected] > > > > The ACP address MUST be specified in its canonical form, as specified > > in [RFC5952], to allow for easy textual comparisons. > > RFC5952 requires lower-case, so your example is wrong and should be > anima.acp+fd99:b02d:8ec3:0:200:0:6400:[email protected] Haha. We did it again. Michael must also have looked at some Cisco IOS output. But you're now awarded the golden metal as the RFC5952 defender ;-) > > 5.5.5. ACP Security Profiles > > > > A baseline autonomic device MUST support IPsec and SHOULD support > > GRASP/TLS > > It's the GRASP spec that says that a GRASP implementation MUST > support TLS when there is no ACP. And every autonomic device > MUST support GRASP. So I think this should say > > A baseline autonomic device MUST support IPsec and GRASP So my thinking was: -> Negotiation of ACP between two neighbors: In many cases, devices will only support one security option. That makes the approach of simply probing the security option the most lightweight one. Thats why i wrote (already in the prior version of ACP draft), that ACP channel negotiation via TLS/GRASP was optional and primarily required when you need a more intelligent negotiation outcome than "probe channel options, each option has priority. Highest priority option that works wins". -> The main reason to make that negotiation optional is that we haven't yet brainstormed IMHO any interesting negotiation choices that are more complex, and unless we have those, we couldn't even define the GRASP messaging for the negotiation. Thats why i felt it was better to make it this way, so we could have any more intelligent ACP channel negotiation via GRASP done in a separate draft when we've gollected some more complex negotiation elements. I am not sure how soon we'd need those. I think we'd only need those when wee start seeing more complex security channel options with parameters to negotiate. > > ... and dTLS. A constrained autonomic device MUST support > > dTLS. > > Hmm. I think we need to talk about dTLS. I find it hard to believe > that a node incapable of supporting TLS will ever be an autonomic node. > Also, if dTLS is a MUST for some nodes and a SHOULD for others, > we don't have guaranteed connectivity. CoAP devices supposedly will not have dTLS because they do not need TCP. Carsten explained to me why they choose not to use TCP. The ACP text shuold have good explanations why we do IMHO not need any-to-eny connectivity. Aka: I will not connect a sensor to a service provider core-router. [ The port on that core router costs $50,000, you do not want to waste it on a $5 sensor]. Aka: its quite useful to consider protocol profiles and have devices support a subset of profiles that they need to talk to neighbors. Enterprise edge-switches would likely be the ones with both some "IoT" profile (dTLS) and some "basline" profile (TLS). > > Autonomic devices need to specify in documentation the set of secure > > ACP mechanisms they suppport. > > That doesn't help anybody. Autonomic nodes need to interoperate in > plug and play mode without any human needing to consult documentation > or check consistency. Security has to deploy itself with no intervention. See above on why i think that any-to-any connectivity isn't even a requirement. Yes, its a very nice vision, but when it comes at the cost of having to implement a "lowest-common-denominator" protocol stack thats undesired dead weight on many devices, then the vision becomes undesirable IMHO. > > 5.6. GRASP instance details > > > > Received GRASP packets are assigned to an instance of GRASP by the > > context they are received on: > > > > o GRASP packets received on an ACP (virtual) interfaces are assigned > > to the ACP instance of GRASP > > > > o GRASP packets received inside a TLS connection established for > > GRASP/TLS ACP negotiation are assigned to a separate instance of > > GRASP for that negotiation. > > Just to repeat what I said a while back, this might not be how it's > implemented. There might equally be a single instance of GRASP in a > node but with several modes (insecure/ACP/TLS) that apply to individual > sessions. Sessions are distinguished explicitly in the GRASP protocol, > as well as by port number. Even if the implementation chooses to > launch separate instances of GRASP (rather than just a single multi-threaded > instance) there have to be common data structures shared between them. For instances, i don't think that's true. Ideally, different instanes are different processes with totally independent data memory (code shared of course). I also don't see off the top of my head any savings through sharing data memory across the GRASP instances we're talking about. Cheers Toerless > > TBD: The Details of the GRASP objective/packet formats still need to > > be defined. Eg: Need to define an allocation for the objective of > > "Autonomic Node". > > Yes. And its primary application would be ACP neighbor discovery, which > is why we don't need mDNS/DNSSD. > > Brian > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima -- --- Toerless Eckert, [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
