Hi Toerless,
On 09/07/2016 09:38, Toerless Eckert wrote:
> 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.
Yes, I agree with that. That's why I have no problem with mDNS/DNSSD
being REQUIRED for bootstrap. But that does not exclude GRASP Discovery.
> 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 ?
I didn't try to write exact normative text yet, and the phrase "mandatory
to implement" is actually ambiguous (does it mean "mandatory to write the
code" or "mandatory to switch on"?). But I think I lean towards saying that
any device that supports GRASP MUST use GRASP Discovery for bootstrap,
and any device that doesn't support GRASP MUST use mDNS/DNSSD for bootstrap.
Therefore proxies must respond to both, to allow mixed scenarios.
I don't especially like this but I think it is realistic and doesn't add
significantly to software footprints. Non-AN devices don't need any GRASP
code and AN devices will have GRASP code anyway, and are very likely to have
DNS code for other reasons. It also means that the "market" can naturally
choose the best solution.
> 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.
The issue with genuinely separate instances is that they turn out to need
common data. In my Python-infected brain, they need to share things such as:
ASA_registry (and its lock)
objective_registry (and its lock)
discovery_cache (and its lock)
session_id_cache (and its lock)
flood_cache (and its lock)
FIFO queues for pending discovery operations
To be clear: we need a node-wide ASA registry so that we can guarantee
only one instance of a given ASA is active; we need a node-wide objective
registry to guarantee that only one ASA is managing a given objective (or
alternatively, to allow coordinated management by multiple ASAs); we need
a node-wide session_ID cache to guarantee no clashes of session_IDs. Then
it's much more efficient to share the discovery cache and queues and the
flood cache.
Given that amount of shared state, being hammered by separate threads
for each active ASA plus some internal threads for the GRASP kernel
itself, I can't visualize how to make separate instances provide genuine
isolation. (Of course, you could run genuinely separate instances in one
node but then each one would need its own IP address too.)
(Full disclosure: I run tests with my prototype by invoking separate
Python instances in one node, and they happily talk to each other even
with the same IP address, but there's a little bit of fakery to prevent
instance 1 discovering itself as well as discovering instances 2 and 3...)
> 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.
I certainly can't answer for mDNS and probably nobody can answer yet for
DNSSD. For GRASP, discovery *only* responds with a locator (address, protocol,
port).
If both Bob and Dos reply to GRASP discovery, Alice gets to choose.
If she chooses Dos, we can't help her ;-).
Regards
Brian
>
>>> 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
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
