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

["Michael Behringer (mbehring)" <[e-mail]>]

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: 16 February 2015 20:06
> To: Michael Behringer (mbehring); [e-mail]
> Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-control-
> plane-00.txt
[...]
> >>>    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.

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. 

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

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

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...)
> 
> We're pretty close, I think, but there's work to be done...

I agree.

Michael
[...]