Subject: [Anima] What we want to achieve - personal view.

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Sun, 24 Aug 2014 20:41:58 +0000

It is fairly clear that the charter isn't good enough yet, we had too many comments about this. Can we take a step back, look at the big picture, see whether we agree on that level, and THEN dive back down to writing something down? 

Here is how I would phrase it, informally. Train of thought: 

1) Independent processes: Networks today have a number of processes that run distributed, and do things on their own. The admin monitors, and takes care of exceptions, but by and large these processes run on their own in the network. (I call that "autonomic", but the term itself has raised discussions, so let's leave that discussion for later, to stay focused). Examples are all the IGPs, VRRP, etc. 

2) Lack of common infrastructure: All those processes run independently of each other. Each of them has its own way to communicate, manage policy (if applicable), secure itself, etc. This is where I am coming from: I used to work in infrastructure security, and the fact that you have to secure each protocol independently, each with its own key scheme, algorithms, etc is a major pain in operating networks today. This is the security angle, but other angles exist, for example monitoring, reporting, general policy, etc. 

The above to me is the problem statement. Why is that a problem that needs fixing? Because the operational cost of securing a network is a problem. And when opex is reduced, security suffers. Others may chime in with similar stories from their area of expertise, but I think it's a pretty generic issue. 

The goal then is: 

3) Finding common infrastructure: Assume we accept for a moment that the lack of common functions across a network is an issue, can this be simplified? Can we define one, simple way to manage for example the key material for all the protocols, in one go? We tried to find a solution and came up with draft-pritikin-bootstrapping-keyinfrastructures; that draft describes how to securely bootstrap a key infrastructure, which can then be used to secure ALL protocols through the lifetime of the network (ie not one-off), largely without admin involvement. Again, this is the security angle; I think this is a use case in itself, but other cases exist. 

Now, if this work simplifies just a single aspect of networking (such as security), we'd have made progress, and IMO it would be worthwhile. If we can simplify several components of networking in this way, and if we do this in a coherent way, then we have the potential to really create a largely "self-managing" network. But frankly, I prefer the bottom up approach, let's tackle one function at a time, small steps. Of course, having an overall goal in mind. 

Now, does this train of thought make sense at all? Dimitri? Rene? Others?  

Michael

---

From: Leo Dorrendorf <[email-masked]>
Date: Mon, 25 Aug 2014 09:10:42 +0000

Hi Michael,

My interest is in security bootstrapping. Since ACE decided they would not include it in the current scope, I have been following the discussion here. 

I believe that solving the security bootstrapping problem would be valuable for autonomous networks, especially in the setting of the Internet of Things. I also agree with your baseline assumptions - a single security infrastructure can secure all further communications, with little to no admin involvement. 

It would be great if Anima addressed these issues.

Best regards,
Leo Dorrendorf

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Michael Behringer (mbehring)
Sent: Sunday, August 24, 2014 11:42 PM
To: [email-masked]
Subject: [Anima] What we want to achieve - personal view.

The goal then is: 

Michael

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Mon, 25 Aug 2014 10:06:09 +0000

One could sum'up 1) and 2) by stating processes operate independently on different views/partial information and by different means where human/off-line control compensates for these "limits".
More importantly these processes have been designed to realize objectives which are sometimes difficult to combine, reconcile, etc. again human/off-line control compensates for these "limits". This motivates the introduction of intent/high level objectives to help sync'ing these processes and coordinate their actions (justifying in turn distribution) such that the sum of existing "protocols" functionality moves beyond the sum of their individual capability.

Finding cases which would benefit from the latter in the "security domain" you mention includes anomaly/attack detection, intrusion detection, etc. and related re-configuration. Automation can be motivated by the fact that automata/programs are more proficient in realizing systematic and exhaustive tasks than humans. Adaptation as anomalies and attacks are constantly detected,  Autonomy as each event has its specifics which translates into different local actions and Abstraction to enable coordination between heterogeneous equipment. I often refer to the 4A principle (and pretty sure similar can be found).  

This lead to a key question/alternative when it comes to the realization challenge of "finding common infrastructure" (this term needs to be somehow revisited as we deal with logic of control/management): 

i) assuming underlying functionality/protocols already exist, this artifact would be required to ensure the coordination of existing function with the possible addition of sources of information (monitoring, etc.) such as the sum of existing "protocols" functionality moves beyond the sum of their individual capability to achieve higher level objectives. The main challenge becomes then to determine if a layout comprising agents and discovery/negotiation/interaction among them would enable achieving this objective.

ii) assuming underlying functionality/protocols don't, there is an architectural question moving well beyond AN, would you incorporate these new functionality/protocol in the AN framework itself ? this leads to a large list of questions such as how to keep commonality among different functions (as they are by definition serving different purposes), how to ensure it doesn't yield yet another approach (as basically this leads to consider low level objectives as the same level than other protocols do/should do nowadays), how to ensure that the first type of function that will be considered won't drive the whole architecture and make it unusable by others, etc. 

The whole point is: if the goal is to work from a bottom-up approach, with incremental steps it seems advisable to start from cases covering i) before ii) as the questions ii) raises is at least one order of complexity higher. One would still have sufficient level of uncertainty to disambiguate to make the work attractive enough. On the other hand, this could be the mean to trial/consolidate the (ongoing) design on mature/stable functionality before moving to the next level of complexity. 

Thanks,
-d.

> Sent: Sunday, August 24, 2014 10:42 PM
> To: [email-masked]
> It is fairly clear that the charter isn't good enough yet, we had too many
> comments about this. Can we take a step back, look at the big picture, see
> whether we agree on that level, and THEN dive back down to writing
> something down?
> 
> 1) Independent processes: Networks today have a number of processes that
> run distributed, and do things on their own. The admin monitors, and takes
> care of exceptions, but by and large these processes run on their own in
> the network. (I call that "autonomic", but the term itself has raised
> discussions, so let's leave that discussion for later, to stay focused).
> Examples are all the IGPs, VRRP, etc.
> 
> 2) Lack of common infrastructure: All those processes run independently of
> each other. Each of them has its own way to communicate, manage policy (if
> applicable), secure itself, etc. This is where I am coming from: I used to
> work in infrastructure security, and the fact that you have to secure each
> protocol independently, each with its own key scheme, algorithms, etc is a
> major pain in operating networks today. This is the security angle, but
> other angles exist, for example monitoring, reporting, general policy,
> etc.
> 
> The above to me is the problem statement. Why is that a problem that needs
> fixing? Because the operational cost of securing a network is a problem.
> And when opex is reduced, security suffers. Others may chime in with
> similar stories from their area of expertise, but I think it's a pretty
> generic issue.
> 
> The goal then is:
> 
> 3) Finding common infrastructure: Assume we accept for a moment that the
> lack of common functions across a network is an issue, can this be
> simplified? Can we define one, simple way to manage for example the key
> material for all the protocols, in one go? We tried to find a solution and
> came up with draft-pritikin-bootstrapping-keyinfrastructures; that draft
> describes how to securely bootstrap a key infrastructure, which can then
> be used to secure ALL protocols through the lifetime of the network (ie
> not one-off), largely without admin involvement. Again, this is the
> security angle; I think this is a use case in itself, but other cases
> exist.
> 
> Now, if this work simplifies just a single aspect of networking (such as
> security), we'd have made progress, and IMO it would be worthwhile. If we
> can simplify several components of networking in this way, and if we do
> this in a coherent way, then we have the potential to really create a
> largely "self-managing" network. But frankly, I prefer the bottom up
> approach, let's tackle one function at a time, small steps. Of course,
> having an overall goal in mind.
>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 25 Aug 2014 06:31:07 -0700

Thanks Dimitri,

Your thoughts are very much appreciated. I am new to the challenge of creating
a WG in the ops area. Do you have prior experience ? How would you suggest to
translate your considerations into charter text modifications ? 

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 28 Aug 2014 00:15:47 -0700

Michael,

This again looks like good analysis, but i wonder if we also need
to restate the operator visible problems that ultimately lead to
these conclusions better represented in the charter.

The list of problems and target solutions or ANIMA the way i see
it is as follows: This could be separated into a list of problems
and another list of solution areas:

- Manual labour intensive device/network bootstrap
  -> want secure zero touch bootstrap.

- Fragile, config dependent, insecure NOC and/or SDN OAM connectivity
  -> want secure, zero touch, reliable OAM connectivity for NOC/SDN

- High cost/risk in operating rich set of network services due to siloed,
  inconsistent re-implementation of common communications/security functions.
  -> want security, consistency though common functions

- Expensive, per-device orchestration needed due to lack of
  network wide OAM interface to services (intent).
  -> want in-network services with network wide intent/reporting
     interface to NOC.

- Lack of in-network control-loops for services outsources dynamic
  services adaptation to NOC - scale, performance, availability issues.
  -> Want common infrastructure components to self-orchestrate
     in network control loops. Want to build limited set of such
     self orchestrating services/agents.

Cheers
    Toerless

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Aug 2014 07:49:25 +1200

> these conclusions better represented in the charter.

Agreed, that aspect of the problem statement is missing in the charter.
I promised during the call yesterday to make the next update of the
charter with this point and some others, and also to check back through
the numerous emails to see if all the issues have been picked up.
This will take a day or two

Regards
   Brian