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

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 20 Jun 2014 12:14:47 +0000

The draft we just posted makes another good use case for an autonomic function, and we'd like to suggest it for the agenda of the UCAN BoF. 

In a nutshell: Every autonomic node creates a secure channel to all its neighbours, based on link local addressing. Those channels are kept in a different context (VRF), and thus automatically create an overlay network. The thing to note is that this overlay network doesn't depend on config or (configured) addressing, and is therefore not affected by many common config or routing errors. 

It is a classical autonomic function, because every node must act independently for this "virtual out of band" channel to come up. A good example for a self-managing function.

We'd love to get feedback on this draft. 
Michael

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 20 June 2014 11:55
> To: [email-masked]
> Subject: I-D Action: draft-behringer-autonomic-control-plane-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>         Title           : An Autonomic Control Plane
>         Authors         : Michael H. Behringer
>                           Steinthor Bjarnason
>                           Balaji BL
>                           Toerless Eckert
> 	Filename        : draft-behringer-autonomic-control-plane-00.txt
> 	Pages           : 10
> 	Date            : 2014-06-20
> 
> Abstract:
>    In certain scenarios, for example when bootstrapping a network, it is
>    desirable to automatically bring up a secure, routed control plane,
>    which is independent of device configurations and global routing
>    table.  This document describes an approach for an "Autonomic Control
>    Plane", which can be used as a "virtual out of band channel" - a
>    self-managing overlay network, which is independent of configuration,
>    addressing and routing on the data plane.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-behringer-autonomic-control-plane/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-behringer-autonomic-control-plane-00
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Jun 2014 07:40:14 +1200

Michael,

I've only had time for a quick glance so far (it's 07:40 Saturday
for me) but this seems closer to solution space than to use cases.

More when it gets to the top of my reading list...

Regards
   Brian

On 21/06/2014 00:14, Michael Behringer (mbehring) wrote:
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 23 Jun 2014 05:54:46 +0000

Well, yes, it also describes the solution (frankly, given that this is completely new, I think we must describe how it works for it to be understood. 

At the same time, it is a use case, and the three use cases are described in the doc. The communications is also described. 

Everybody, please have a look, and let me know whether we should 
1) submit a pure use case draft for this (which would be quite overlapping or
2) add more of the template info in this draft or 
3) whether it's "good enough" for the discusstion. 

Michael

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 20 June 2014 21:40
> To: Michael Behringer (mbehring)
> Cc: [email-masked]
> Subject: Re: [Anima] FW: I-D Action: draft-behringer-autonomic-control-
> plane-00.txt
> 
> Michael,
> 
> I've only had time for a quick glance so far (it's 07:40 Saturday for me) but
> this seems closer to solution space than to use cases.
> 
> > The draft we just posted makes another good use case for an autonomic
> function, and we'd like to suggest it for the agenda of the UCAN BoF.
> >
> > In a nutshell: Every autonomic node creates a secure channel to all its
> neighbours, based on link local addressing. Those channels are kept in a
> different context (VRF), and thus automatically create an overlay network.
> The thing to note is that this overlay network doesn't depend on config or
> (configured) addressing, and is therefore not affected by many common
> config or routing errors.
> >
> > It is a classical autonomic function, because every node must act
> independently for this "virtual out of band" channel to come up. A good
> example for a self-managing function.
> >
> >> From: I-D-Announce [mailto:[email-masked]] On Behalf
> >> Of [email-masked]
> >> Sent: 20 June 2014 11:55

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 23 Jun 2014 08:08:32 +0000

Hi, Michael,

After read through this draft, I have fully of questions for the solution feasibility. There are a lot of design details missing. I believe it is because you were trying to describe the solution in a very abstract way in order to fit into an use case style document.

Therefore, I would suggest you to submit two separated drafts: a pure use case draft for this and another solution draft with an overall picture and much more design details. As we agreed, we should not stop in use cases stage for long, so your potential solution could also be discussion objects.

A couple of high-level design questions: authentication on a new device and domain establish. How a new device validate its discovered neighbor is trusted giving that offline authentication mechanism are very expensive? How and who is set up the domain boundary of the autonomic network in the ACP use case?

Best regards,

Sheng

>From: Anima [mailto:[email-masked]] On Behalf Of Michael
>Behringer (mbehring)
>Sent: Monday, June 23, 2014 1:55 PM
>To: Brian E Carpenter
>Cc: [email-masked]
>Subject: Re: [Anima] FW: I-D Action:
>draft-behringer-autonomic-control-plane-00.txt
>
>Well, yes, it also describes the solution (frankly, given that this is completely
>new, I think we must describe how it works for it to be understood.
>
>At the same time, it is a use case, and the three use cases are described in the
>doc. The communications is also described.
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 23 Jun 2014 08:49:04 +0000

Hi Sheng, 

To your questions: Essentially we have two bits: 

- http://tools.ietf.org/html/draft-pritikin-bootstrapping-keyinfrastructures describes how devices in a domain get a domain certificate, securely, and zero-touch. Those domain certificates are now used for devices to authenticate each other. And 
- http://tools.ietf.org/html/draft-behringer-autonomic-control-plane-00 uses the domain certificates to secure its interactions, and to form the autonomic control plane. Section 3.1 tries to explain that we need the above draft for this one. 

The only centralised bit in the solution is a "registrar" component, which checks that devices are indeed part of the domain (based on serial number or vendor certificate), and hands out the domain certificates. So this is a truly autonomic solution - as distributed as possible. 

Now, I agree, this draft isn't written with the use case template (sorry we had started this one a long time ago). We can of course do a separate use case draft, but frankly, I'd prefer if we can keep the info in one place. 

From the use case template, we already have in the ACP draft: 
- intro
- problem statement
- benefits (this is in section 6 "use cases for the ACP")
- user experience (section 7)
- The "Analysis of Parameters and Information Involved" is contained in section 3. 

There is missing: 
- comparison with current solutions: But I claim there is really nothing comparable today, so this section doesn't make too much sense. 

So I'd argue while the template isn't strictly followed, the content is there. 

But if you feel strongly that we should also have a separate use case draft, I'm happy to produce one. Would like to avoid spending the cycles though unless really needed. :-)  Please let us know!

Michael

> From: Sheng Jiang [mailto:[email-masked]]
> Sent: 23 June 2014 10:09
> Subject: RE: [Anima] FW: I-D Action: draft-behringer-autonomic-control-
> plane-00.txt
> 
> Hi, Michael,
> 
> After read through this draft, I have fully of questions for the solution
> feasibility. There are a lot of design details missing. I believe it is because
> you were trying to describe the solution in a very abstract way in order to fit
> into an use case style document.
> 
> Therefore, I would suggest you to submit two separated drafts: a pure use
> case draft for this and another solution draft with an overall picture and
> much more design details. As we agreed, we should not stop in use cases
> stage for long, so your potential solution could also be discussion objects.
> 
> A couple of high-level design questions: authentication on a new device
> and domain establish. How a new device validate its discovered neighbor is
> trusted giving that offline authentication mechanism are very expensive?
> How and who is set up the domain boundary of the autonomic network in
> the ACP use case?
> 
> Best regards,
> 
> Sheng
> 
> >Well, yes, it also describes the solution (frankly, given that this is
> >completely new, I think we must describe how it works for it to be
> understood.
> >
> >At the same time, it is a use case, and the three use cases are
> >described in the doc. The communications is also described.
> >
> >> I've only had time for a quick glance so far (it's 07:40 Saturday for
> >> me) but this seems closer to solution space than to use cases.
> >>
> >> neighbours, based on link local addressing. Those channels are kept
> >> in a different context (VRF), and thus automatically create an overlay
> network.
> >> independently for this "virtual out of band" channel to come up. A
> >> good example for a self-managing function.
> >> >
> >> >> From: I-D-Announce [mailto:[email-masked]] On
> >> >> Behalf Of [email-masked]
> >> >> Sent: 20 June 2014 11:55
> >> >> Subject: I-D Action:
> >> >> https://datatracker.ietf.org/doc/draft-behringer-autonomic-control
> >> >> -pl
> >> >> ane/
> >> >>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 23 Jun 2014 10:32:50 -0700

Just trying to catch up with the anima process - do we have a list
of candidate draft - obviously i primarily have no track of the non-cisco
drafts. Wanted to check what the set of use-case drafts is.

Any wiki for anima listing drafts ?

Thanks
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jun 2014 08:22:26 +1200

Toerless,

At the moment there is a reading list in the wiki entry for the
UCAN BOF. As we seem to be receiving several drafts at the moment,
I will update the wiki in a day or two.

Michael and I will discuss the BOF agenda soon of course. We
probably won't have time for every use case to be presented,
and certainly not in detail.

Regards
   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 24 Jun 2014 01:24:18 +0000

Hi, Michael,

Thanks for your reply and explanation. Personally, I am fine to have the current form as an use case document. My point is the mechanisms mentioned in this draft are scattered piece by piece. It would be better that you have another dedicated solution document to describe the ACP solution as a whole.

Sheng

>From: Michael Behringer (mbehring) [mailto:[email-masked]]
>Sent: Monday, June 23, 2014 4:49 PM
>To: Sheng Jiang
>Cc: [email-masked]
>Subject: RE: [Anima] FW: I-D Action:
>- http://tools.ietf.org/html/draft-pritikin-bootstrapping-keyinfrastructures
>describes how devices in a domain get a domain certificate, securely, and
>zero-touch. Those domain certificates are now used for devices to
>authenticate each other. And
>- http://tools.ietf.org/html/draft-behringer-autonomic-control-plane-00 uses
>the domain certificates to secure its interactions, and to form the autonomic
>control plane. Section 3.1 tries to explain that we need the above draft for
>this one.
>
>The only centralised bit in the solution is a "registrar" component, which
>checks that devices are indeed part of the domain (based on serial number or
>vendor certificate), and hands out the domain certificates. So this is a truly
>autonomic solution - as distributed as possible.
>
>Now, I agree, this draft isn't written with the use case template (sorry we had
>started this one a long time ago). We can of course do a separate use case
>draft, but frankly, I'd prefer if we can keep the info in one place.
>
>- comparison with current solutions: But I claim there is really nothing
>comparable today, so this section doesn't make too much sense.
>
>But if you feel strongly that we should also have a separate use case draft, I'm
>happy to produce one. Would like to avoid spending the cycles though unless
>really needed. :-)  Please let us know!
>
>Michael
>
>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 23 Jun 2014 20:58:16 -0700

Sheng,

The elements that where contributed as separate drafts are also useable by
themselves without necessarily having to be compounded into the ACP.
They are more like lower layer modules.

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Jun 2014 17:17:47 +1200

BOF Chair hat on: Please think about how you can separate
out the use case items from the solution space items. These
will belong in two completely separate parts of the agenda.

BOF Chair hat off, and in solution space:

You suggest one option is to establish a "secure IP tunnel"
e.g. using IPsec.

1. It isn't clear whether you want to use a tunnel for secrecy
or just for authentication. That needs to be stated.

2. IPsec would require a whole bunch of key management complexity.
There are ways to avoid that (although it's impossible to avoid
some sort of certificate infrastructure, I think).

Your other option is L2 separation. I'm not sure that can be
applied everywhere, and doesn't it imply a fully bridged network?

Regards
   Brian Carpenter

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 28 Jun 2014 13:12:38 -0700

Thanks, Brian, 
inline...

> will belong in two completely separate parts of the agenda.

Thats fine. Wouldn't be aproblem at all to present these two
aspects separately in Toronto.

Will check with the other authors if/how we can improve the draft
before IETF, not sure. Its the vacation time...

> or just for authentication. That needs to be stated.

Right. In fact, the goal was to express that there are two layers
to the channel building: security and separation from data plane.
Any combination of one or more available mechanisms is a candidate
option. Something like MacSec for example would provide both
very low layer separatation AND security (but may have short term the
most product support challenges).

Wrt. to security: IMHO, you MUST have authentication, and secrecy
(encryption) would be on by default and disabling it must be
a well controllable operation (so it can not happen unintentional).
Unfortunately operators must be required to disable encryption to match
legal requirements.

> some sort of certificate infrastructure, I think).

Example ? 

"I am not a security expert, but..." ((c) layman society),

my impression is that the operational complexity is 95% based
on using public key certificates - whatever protocol you
choose, IPsec, (d)TLS, MacSec or whatever else supports PKI.
And there does not seems to be a way around PKI it if you want
"real security" ((c) security experts).

Given multiple choices with PKI support, i'd still pick the 
one that best matches other requirements. Thats for example why
we gave the example of IPsec - its widely supported in network equipment.

> applied everywhere, and doesn't it imply a fully bridged network?

Hmm.. this comment makes me think that you may not have read this
as we intended to: The channel is always between two adjacent
AN devices. If you have a large L2 network consisting all of
AN devices, then each one still has a separate channel to each of
its direct neighbors. Which would be the same if this network 
was purely a routed network.

In routers, its usually quite easy to have a separate L2 tag for
a separate L3 context - eg: in cisco routers we call this
a "routed subinterface". The complexities in other existing type
of devices vary. But when you know the requirement upfront in new
devices its IMHO always easy to design support for this.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 29 Jun 2014 08:41:34 +1200

>> some sort of certificate infrastructure, I think).

Well, I didn't mean to suggest that we can avoid PKI within
the AN domain; there doesn't seem to be any way out of that,
as you say below.

> "I am not a security expert, but..." ((c) layman society),

...ditto.
> choose, IPsec, (d)TLS, MacSec or whatever else supports PKI.

...my impression is that IPsec/IKEv2 brings more complexity
than the other approaches (including the kind of homebrew we
describe in draft-jiang-config-negotiation-protocol).

> we gave the example of IPsec - its widely supported in network equipment.

Sure, but it isn't the only candidate.

> was purely a routed network.

OK. But that means you require perfect congruence between the
AN topology and the L2 topology, doesn't it?

> devices its IMHO always easy to design support for this.

OK, but in the standards context this needs to be vendor-independent.

   Brian