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.

> 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.

> 
> 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.

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.

> 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 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.

But if you do want to negotiate the secure channel, GDNP is the
protocol for the job ;-).

>       ... 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).

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.

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:anima-bounces@ietf.org] On Behalf Of Brian E
>> Carpenter
>> Sent: 29 January 2015 21:57
>> To: anima@ietf.org
>> 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
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> 