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

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 11 Feb 2015 19:12:49 +0000

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Feb 2015 15:53:41 +1300

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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 16 Feb 2015 12:23:43 +0000

Thanks for your comments Brian! Inline...

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 16 February 2015 03:54
> To: Michael Behringer (mbehring); [email-masked]
> 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. 

> mechanisms. Some details TBD of course, but it's a text book application of
> GDNP.

This is of course the intention ;-)   

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

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

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

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

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

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. 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Feb 2015 08:06:05 +1300

Hi again,
> Thanks for your comments Brian! Inline...

Ditto...

> 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 communica…

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

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

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 cou…

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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 17 Feb 2015 07:47:23 +0000

> Sent: 16 February 2015 20:06
[...]
> >> 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.
> 
> 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.

Of course. Which protocol to use is a detail, I think. The question is how many SAs we want between peers, and of course we need some keepalive mechanism, and re-establishment if the session goes down. I think we're in sync. 

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

That is a point we need to discuss in more detail. My feeling is that DTLS is more appropriate, especially when we start routing packets through this infrastructure within the ACP, but this clearly needs more thinking (on my side at least ;-) . That's probably also a good discussion to have in Dallas. 

[...]

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

OK, need to read the latest version of GDNP first before I can comment here :-) 
 
> > 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...)
> 

I agree.

Michael
[...]

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 19 Feb 2015 17:27:23 +0000

This will be addressed in the next version, probably out tomorrow. Bottom line: partitions and merges should not cause an issue. 

Michael

> Sent: 03 November 2014 22:37
> To: [email-masked]
> 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?
>