Re: [Anima] I-D Action: draft-behringer-anima-autonomic-control-plane-00.txt

[Brian E Carpenter <[e-mail]>]

Hi again,
On 17/02/2015 01:23, Michael Behringer (mbehring) wrote:
> Thanks for your comments Brian! Inline...

Ditto...

> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:[e-mail]]
>> Sent: 16 February 2015 03:54
>> To: Michael Behringer (mbehring); [e-mail]
>> Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-control-
>> plane-00.txt
>>
>> Hi Michael,
>>
>> This may be a bit late but we've been working hard on the GDNP protocol
>> spec...
>>
>>> 3.1. Preconditions
>>>
>>>
>>>    Each autonomic device has a globally unique domain certificate, with
>>>    which it can cryptographically assert its membership of the domain.
>>>    The document [I-D.pritikin-bootstrapping-keyinfrastructures]
>>>    describes how a domain certificate can be automatically and securely
>>>    derived ...
>>
>> One thing we need to agree on is the size of this cert, or rather of its hash,
>> which draft-pritikin calls the  Domain Identity and sets at 160 bits. In the
>> GDNP draft we picked 128 bits and called it Device Certifcate Tag. The good
>> news is that we all agree that it's needed.
> 
> Yes, I think we all agree that certificates are the only way to make devices autonomic - make sure they can talk to each other. A point well worth noting down. 
> 
> Regarding the size of the hash, need to think more, but quick reaction is that a TLV should allow flexibility. 
> 
>>> 3.2. Adjacency Discovery
>>
>> This we can certainly do with the GDNP Discovery and Synchronization
>> mechanisms. Some details TBD of course, but it's a text book application of
>> GDNP.
> 
> This is of course the intention ;-)   
> 
>>>
>>> 3.3. Authenticating Neighbors
>>>
>>>
>>>    Each neighbour in the adjacency table is authenticated.
>>
>> I think this falls right out of Discovery since the discovery response would
>> contain the relevant Domain Identity a.k.a. Device Certifcate Tag and that
>> can be checked with the CA.
> 
> Right, but here the devil is in the detail. We need a security association with the peer device. This association can be established via the discovery protocol, and re-used for subsequent communications, such as the ACP. Or, we could have the ACP establish its own security association. My feeling is that we should establish one single SA and use it for all subsequent operations. We need to cover this point in the reference architecture. 

I think I agree, except that anything can go wrong at any time, so it must
always be possible to recreate the SA. I don't think that changes
whether we use  (D)TLS or IPsec - just keep the channel open unless it
breaks or you run out of resource.
> 
>> Note that draft-ietf-homenet-dncp has a quite complicated "trust verdict"
>> mechanism. I personally don't think that is necessary, but we should
>> probably find out why they included it.
> 
> My current understanding (which could be wrong) is that homenet tries to avoid a single trust anchor, or a single source of truth, which they also call the "god box". Personally, I don't think having a trust anchor in a homenet is a big deal, but opinions vary here. In any case, having a distributed mechanism could be very elegant for some scenarios, so we should at least look at it and consider it (still have to read the draft...). 
> 
> This would be the ultimate in "distribution" if you don't even have a centralised trust anchor. Philosophically I quite like this idea. We need to check the details.  
> 
>>> 3.4. Capability Negotiation
>> ...
>>>    To establish a trusted secure
>>>    communication channel, devices must be able to negotiate with each
>>>    neighbour a set of parameters for establishing the communication
>>>    channel, most notably channel type and security type.
>>
>> I think GDNP is very likely to end up simply using TLS (although that's not
> 
> TLS? Not DTLS? (sorry I haven't read all the mails)

Well, it's an open issue right now; but I am 99% sure we'll need a TLS
mode for cases where the objective is a large data structure. I also have
a feeling that DTLS introduces a significant start-up overhead that
makes the difference compared to TLS start-up very small.

> 
>> what the draft says right now, the arguments from the DNCP team have
>> almost convinced me). In any case, secure channels between GDNP nodes
>> are fundamental, as for the ACP. I have doubts whether we should leave
>> options or choices in this area: choices always end up causing problems
>> later.
> 
> We have a number of architectural options here: 
> - We could use GDNP establish and maintain a security association, say DTLS. And then negotiate a separate channel for the ACP. 
> - Or we could establish with GDNP a security association, and use that same for the ACP. 
> 
> At the end, the ACP essentially *is* a persistant security association between nodes, so I think we could use GDNP to directly establish a secure channel which essentially becomes the ACP if we provide contextual separation with the data plane. Again, this needs to go into the reference architecture. 
>  
>> But if you do want to negotiate the secure channel, GDNP is the protocol for
>> the job ;-).
> 
> Agree, we think the same way. 
> 
>>>       ... using IPv6 link local
>>>       addresses between two adjacent neighbours.  This way, the ACP
>>>       tunnels are independent of correct network wide routing.  They
>>>       also do not require larger than link local scope addresses, which
>>>       would normally need to be configured or maintained.  Each AN node
>>>       MUST support this function.
>>
>> Certainly that will be the fall-back. We expect GDNP to run over routed
>> connections too, but link-local must always work. But as you describe in
>> section 3.7 and 3.8, routed connections using a ULA are also valuable.
>> (The protocol is not restricted to ULA of course, but the ACP use case can
>> certainly have that restriction).
> 
> I *think* we are on the same page. Let me describe this from my point of view, to see whether that's true. 
> 
> To me, GDNP between adjacent nodes should ALWAYS use link local (Probably a "MUST" in the document). Link local has no dependency on correct configuration, so conflicts with what the administrator does are minimal. I feel very strongly about this. I see no reason to NOT use link local. (But happy to be educated). 

We don't state that at the moment, although we do state the inverse:
a link-local address MUST NOT be used in a Divert option, because that
is intended to send you off-link.

There's a slight complication there, which is that a device (router) that
is sending a Divert option needs to know the appropriate routeable address.
We need to figure out how it learns it in the first place. But I agree
that link-local is a safer choice whenever possible.

> Now, we also want to negotiate / discover nodes that are not directly adjacent. For this we need unicast (or multicast, anycast, possibly) to routable addresses. To me, those routable addresses could either be derived automatically, in which case it would likely be ULA, or configured, in which case we'd have ULA or global addresses. 

The GDNP draft now says that a router running GDNP relays discovery messages
to all its interfaces, so that a non-router doesn't need to worry
about this issue.

> 
> Are we on the same page? (And apologies if your draft mentions this, haven't read the last two versions yet, sigh...)

We're pretty close, I think, but there's work to be done...

   Brian

>  
>> Bottom line: I see no primary difficulty in using GDNP both to help build the
>> ACP and to exploit it. The Domain Identity/Device Certifcate Tag issue
>> needs to be resolved but that should be easy.
> 
> Agree.
> 
> Michael
>  
>> Regards
>>     Brian
>> On 12/02/2015 08:12, Michael Behringer (mbehring) wrote:
>>> We are planning an upgrade, but it'll take some time. I suggest you review
>> now, and we include your comments in the next version.
>>>
>>> Michael
>>>
>>>> -----Original Message-----
>>>> From: Anima [mailto:[e-mail]] On Behalf Of Brian E
>>>> Carpenter
>>>> Sent: 29 January 2015 21:57
>>>> To: [e-mail]
>>>> Subject: Re: [Anima] I-D Action:
>>>> draft-behringer-anima-autonomic-control-
>>>> plane-00.txt
>>>>
>>>> Hi authors of -autonomic-control-plane,
>>>>
>>>> I was thinking of reviewing this draft as a potential application of
>>>> GDNP, but before I do that, are you planning an update soon?
>>>>
>>>>     Brian
>>>>
>>>>
>>>> On 04/11/2014 10:36, Brian E Carpenter wrote:
>>>>> Hi,
>>>>>
>>>>> This draft seems fairly clear to me, though I assume it will evolve
>>>>> as other aspects of anima become clear. The proposal to use a ULA
>>>>> prefix (section 3.7) seems good, since it decouples the ACP from all
>>>>> external addressing considerations and will work from a pure
>>>>> factory-reset condition. However, it does raise a question (which
>>>>> also came up in homenet recently). What happens if the network
>>>>> partitions? The ACP will automatically partition too, but it will
>>>>> presumably keep the same
>>>>> /48 ULA prefix everywhere. Does the partitioned network retain the
>>>>> same domain ID in both parts? What happends in the part that doesn't
>>>>> include the trust anchor? What happens if the network recombines -
>>>>> will there be a risk of clashing subnets created during the partition?
>>>>>
>>>>> Also what happens if two previously unrelated networks combine?
>>>>>
>>>>>    Brian
>>>>>
>>>>
>>>> _______________________________________________
>>>> Anima mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/anima
>>>