Subject: [Anima] Domains

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Jun 2015 08:32:08 +1200

Hi,

I want to raise a point about the reference model that the authors of
draft-behringer-anima-reference-model didn't settle before version -02
came out a few days ago. There's placeholder text in the draft about
Sub-Domains and Cross-Domain Functionality. I suggested that we
should also list "Overlapping Domains" as a topic. In other words,
regions of a network could be considered to be in two different
domains simultaneously. The question is whether we want our model
to include that possibility? It certainly has implications for security.

An example would be some sort of resource that needed to be shared
between two otherwise separate domains; that resource could be considered
to be in both domains.

So I can see three possible models, shown in the folowing ASCII art:

-------------------------------------------
|           Shared Resource               |
|                                         |
| ------------------   ------------------ |
| | Subddomain1    |   | Subddomain2    | |
| |                |   |                | |
| |                |   |                | |
| ------------------   ------------------ |
|                                         |
-------------------------------------------

1. Shared resource in outer domain

 ------------------   ------------------
 |   Domain1      |   |   Domain2      |
 |                |   |                |
 |         Shared |   |                |
 |       Resource<|xxx|>               |
 ------------------   ------------------

2. Shared resource in one domain, with cross-domain access

 ----------------------
 |   Domain1    ------|------------------
 |              | Shared    Domain2     |
 |              |Resource               |
 |              |     |                 |
 ---------------|------                 |
                -------------------------

3. Shared resource in domain overlap

Regards
    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 14 Jun 2015 14:06:32 -0700

First of all, i think it's not clear to me how we exactly define
"resource", so i think we should do that first, so that we talk
about the same thing.

Maybe we can start with use-cases and then try to explain how we would
solve them, then the right pictures of your model would IMHO evolve:

Mergers/Aquisitions/splits/sale of nodes

Lets say we wanted to solve this at the cert level:
Mechanisms required to make this seamless/online:

   a) establish 2nd cert
   b) change 2nd cert to primary (owner cert)
   c) delete 2nd cert
   - establish AN neighboring to all neighbors with either 1st or 2nd cert.

Merger would then be done as follow:

Network wide:
1. establish buying companies cert on all aquired companies
   AN devices - using the registrar of that aquired company, because
   only that will be trusted. At the end of this, you've got
   contiguous AN connectivity.

2. change 2nd cert to primary, still with intent/authorization from
   aquired company. After this step, there is only one primary
   intent/autohrization - the one of the aquiring company.

3. delete aquired company certs.
   
A problem with this is likely that cheap TPM hardware can only deal
with one cert, so the 2ndary certs need to be done in SW, which
than raises questions of online protection. And b) is a critical
operation.

I think we won't be able to get around the complex "cert in SW"
linking back to a primary cert in HW to protect it, because we certainly
want to solve "autonomic VM on an autonomic Host". The VMs could of
course be in a different autonomic domain and would have to trust the host,
so the host would want to protect the VMs certs in the same way as his own
2ndary certs. 

cheers
    Toerless

On Mon, Jun 15, 2015 at 08:32:08AM +1200, Brian E Carpenter wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Jun 2015 13:21:48 +1200

Hi Toerless,
> "resource", so i think we should do that first, so that we talk

I was trying to be a bit more generic, but let's say that in the AN
context, I mean an entity that is capable of being authenticated
and authorised for AN purposes. Most times that would mean an ASA or
a device capable of containing an ASA.

> solve them, then the right pictures of your model would IMHO evolve:

One use case is what people were calling a bandwidth broker some years
ago. If it's trying to allocate bandwidth across carrier-to-carrier
boundaries, it could (IMHO) be modelled with any of my three diagrams.

>    - establish AN neighboring to all neighbors with either 1st or 2nd cert.

Hmm. That's a very ambitious use case. Will we really see people coding
up an ASA for this? (There is presumably a trivial break-before-make
solution: disconnect the nodes in question, reconnect them to their new
network, and normal AN bootstrap will then follow. But doing it make-
before-break with business continuity is a very different question.)

> so the host would want to protect the VMs certs in the same way as his own

In general, for VMs and tenant systems, we're going to need some sort
of nested "Russian dolls" arrangement, but I assume that would be in
the "sub-domains" model.

Rgds
   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 14 Jun 2015 20:25:06 -0700

> boundaries, it could (IMHO) be modelled with any of my three diagrams.

OK, thats a good use-case, i just fail to see how we would map
this to the term (shared) resource).

The agents on both sides, SP/Enterprise would have to establish
mutual trust, which could easily be based on some ceremonies that
permit the other sides cert or better CA to be used for authentication.

> before-break with business continuity is a very different question.)

Right.

> of nested "Russian dolls" arrangement, but I assume that would be in

Well, i think i understand how a host can provide virtual Cert storage,
and how doing that would be similar to managing secondary Cert storage
for its own use. I have not seen an explanation of a "sub-domain" model.

We can put some additional info into the cert (eg: into subject name),
and require certain cert/SN properties for authorization, but i am
not sure about the generic model.

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 15 Jun 2015 12:54:48 +0000

Brain, 

Yes, this is a recurring question, and needs to be better explained. The same question came up in Homenet a couple of years back, and this is how I answered it: In short, every autonomic entity has A SINGLE owner, and thus a single domain. 

Let's first define what we're talking about: I specifically state "autonomic entity" above. I.e., something that can negotiate on its own. That's what we're concerned with here. Specifically, a queue in a router is NOT an autonomic entity. Therefore, even if several different domains use it, this has to be managed by the autonomic entity (the router), which negotiates bits and pieces for different domains. But the negotiator is the router, an autonomic entity, and that one has only one domain. 

1. I claim for every autonomic entity out there, there is one single administrative "owner". The one who has root access, enable, short, the full admin rights. 

Example: Take the homenet CPE. There is a managed services model, where the SP maintains the CPE, there is the case where the homenet owner is controlling the CPE. Inside the home network, there may be a device that is owned by a utility, which maybe uses your network to communicate with sensors, or uses your Internet connection to call home. You may have some influence on the device settings, but the utility is the administrative owner. 

2. The owner of the autonomic entity can grant some rights to other people. 

In your bandwidth broker example, there is still ONE autonomic entity who has full admin rights over a device (with all its queues, etc). This entity grants rights to another domain to use a certain amount of buffering, whatever, on the device. A special case of that: 

3. A device, owned by domain A, can run a container / VM / other virtualization concept that belongs to domain B. 

Then you get to a case where there is the base hardware which is owned by one domain, and say VMs running on top belonging to another domain. That is supported, and we should have clear boundaries in this case. 

4. Domain A can grant rights to for example a VM of domain B. 

Example, on my home CPE, I run a container that belongs to the utility; i give that access to my Internet connection, possibly to a specific SSID, whatever. 

Clean separation, clean authorization of rights. 

Looking at your pictures, I think all three show a "resource" as *not* being an autonomic entity, but as a sub-part of an autonomic entity, example was the link between two domains. This is where the confusion is coming from. If we agree that we're talking about the domain of an *autonomic entity*, then the picture is different, and hopefully clearer. Then it's up to the autonomic entities (and possibly domains) that share a non-autonomic entity to negotiate its usage. 

Does that make sense? 
Michael

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: 14 June 2015 22:32
> To: Anima WG
> Subject: [Anima] Domains
> 
> Hi,
> 
> I want to raise a point about the reference model that the authors of draft-
> behringer-anima-reference-model didn't settle before version -02 came out
> a few days ago. There's placeholder text in the draft about Sub-Domains and
> Cross-Domain Functionality. I suggested that we should also list
> "Overlapping Domains" as a topic. In other words, regions of a network
> could be considered to be in two different domains simultaneously. The
> question is whether we want our model to include that possibility? It
> certainly has implications for security.
> 
> between two otherwise separate domains; that resource could be
> considered to be in both domains.
>

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 15 Jun 2015 16:17:00 +0200

Dear Michael, Brian, all,

I share and support Michael's explanation... and would add to it another 
level of "decoupling" : decoupling between the autonomic entity and its 
execution "host".

In summary we would have:
     -An autonomic entity controlling one or more resources. Example: a 
load balancing optimization autonomic function controlling several routers.
     -The same autonomic entity executing over 'x'. 'x' could be one / 
part / all of the above routers' OS ; a NMS ; one or several VMs on 
remote computer(s).

Here we are touching at two models: the coupling model and the 
deployment model.
-The coupling model is whether the autonomic entity, its executing 
host(s) and the resource(s) are more or less coupled/integrated:
     . the load balancing optimization autonomic function runs on the OS 
of the routers it controls ; or
     . the load balancing optimization autonomic function runs on the OS 
of a computer and uses appropriate commands to effect control on the 
remote routers.

-The deployment model is intrinsically linked to the 
capabilities/limitations of the coupling model and autonomic components 
designs but is also primarily concerned by how the autonomic networks is 
deployed: more or less centralized/distributed/mix and is dictated by 
other reasons/constraints such as cost, efficiency...

As we are in the process of documenting ANIMA's reference model, I think 
we should describe (even briefly) the different setups and be more 
specific if we face behaviors / situations we wish to avoid or on the 
contrary wish to enforce.
I don't think it is necessary to go into all the details of the coupling 
model, as it is/should be available in other references/WGs/SDOs (e.g. 
IaaS, PaaS and variations of...)

On the resource aspect, we need the assumptions on how it is "shared" in 
the first place (model and interfaces)(as per Michael's message: 
"autonomic entities (and possibly domains) that share a non-autonomic 
entity to negotiate its usage".
In order to operate properly, the autonomic network(s)/functions will 
have to know (Intent) the resources they are supposed to control, how 
they can access them (esp. if decoupled) and the extent of their usage 
rights over these resources. This is also key for the conflict / 
coordination aspects.
If we don't (and I'm sure we don't) want autonomic networks to be static 
(configuration-wise), then we will have to cater for these aspects to be 
exchanged / discovered / negotiated (dynamically) among the 
participating peers.

Finally, it would be nice to clarify the domain "boundary" or dimension: 
is it technology, administrative, topology...?

HTH, best regards, Laurent.

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 15 Jun 2015 08:58:22 -0700

Thanks, Laurent

Do you have specific thoughts on what you described as "behaviors /
situations we wish to avoid or on the contrary wish to enforce" ?

>From my side: I think i have already expressed in the past that i
think ASA and AFs should be deployable dynamically - like applications,
independently of each other (of course, as required with appropriate
dependency resolution like in applications as well).

So it would be good if we had language in the reference model to reflect that.

Eg: Right now we have the constrained/unconstrained AN Nodes. Unconstrained
is just full ANI, but does not specify requirements against ASAs. Constrained,
we didn't define yet.

So maybe more consistently:
   Dynamic ASA       (AN Node)  - can dynamically install ASA
   Constrained ASA   (AN Node)  - Eg: ASA are bundled with underlying OS. Constrained
                                  should just be a superset and we can define
                                  more sspecific terms, like "No custom ASA" or the like
   Full ANI          (AN Node)  - Replaces term "Unconstrained AN Node"
                                  -> Unconstrained ANI can still have constrained ASA.
                                  -> "Unconstrained" seems a bad word choice for ANI
                                     because the implications of the reference model
                                     is that the ANI has a defined functionality,
                                     and that means its never "unconstrained", so
                                     an implementation can at best do "full". This
                                     is IMHO different from ASA, which the reference
                                     model does not constrain in what they could do.
   Constrained ANI   (AN Node)  - Replaces term "Constrained AN Node"

Cheers
    Toerless

On Mon, Jun 15, 2015 at 04:17:00PM +0200, Laurent Ciavaglia wrote:
> >Yes, this is a recurring question, and needs to be better explained. The 
> >same question came up in Homenet a couple of years back, and this is how I 
> >answered it: In short, every autonomic entity has A SINGLE owner, and thus 
> >a single domain.
> >
> >Let's first define what we're talking about: I specifically state 
> >"autonomic entity" above. I.e., something that can negotiate on its own. 
> >That's what we're concerned with here. Specifically, a queue in a router 
> >is NOT an autonomic entity. Therefore, even if several different domains 
> >use it, this has to be managed by the autonomic entity (the router), which 
> >negotiates bits and pieces for different domains. But the negotiator is 
> >the router, an autonomic entity, and that one has only one domain.
> >
> >1. I claim for every autonomic entity out there, there is one single 
> >administrative "owner". The one who has root access, enable, short, the 
> >full admin rights.
> >
> >Example: Take the homenet CPE. There is a managed services model, where 
> >the SP maintains the CPE, there is the case where the homenet owner is 
> >controlling the CPE. Inside the home network, there may be a device that 
> >is owned by a utility, which maybe uses your network to communicate with 
> >sensors, or uses your Internet connection to call home. You may have some 
> >influence on the device settings, but the utility is the administrative 
> >owner.
> >
> >In your bandwidth broker example, there is still ONE autonomic entity who 
> >has full admin rights over a device (with all its queues, etc). This 
> >entity grants rights to another domain to use a certain amount of 
> >buffering, whatever, on the device. A special case of that:
> >
> >3. A device, owned by domain A, can run a container / VM / other 
> >virtualization concept that belongs to domain B.
> >
> >Then you get to a case where there is the base hardware which is owned by 
> >one domain, and say VMs running on top belonging to another domain. That 
> >is supported, and we should have clear boundaries in this case.
> >
> >Example, on my home CPE, I run a container that belongs to the utility; i 
> >give that access to my Internet connection, possibly to a specific SSID, 
> >whatever.
> >
> >Looking at your pictures, I think all three show a "resource" as *not* 
> >being an autonomic entity, but as a sub-part of an autonomic entity, 
> >example was the link between two domains. This is where the confusion is 
> >coming from. If we agree that we're talking about the domain of an 
> >*autonomic entity*, then the picture is different, and hopefully clearer. 
> >Then it's up to the autonomic entities (and possibly domains) that share a 
> >non-autonomic entity to negotiate its usage.
> >
> >Does that make sense?
> >Michael
> >
> >
> >
> >>draft-

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Jun 2015 08:29:26 +1200

Michael (and I've also read Laurent's and Toerless's messages),

> Yes, this is a recurring question, and needs to be better explained. The same question came up in Homenet a couple of years back, and this is how I answered it: In short, every autonomic entity has…

We do need to be sure first what a "domain" is. An administrative boundary is not
necessarily the same as a trust boundary. I can well imagine an entity that is
in a given admin domain being trusted both in that domain and in another domain.
In that sense, trust domains  might overlap when admin domains cannot overlap.

Also I'm pretty sure that domains can contain domains, both in the admin view
and in the trust view. But the nesting might not be the same.

Please note, I don't have a fixed opinion here, I just want clarity in our model
and terminology.

     Brian

> .

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 16 Jun 2015 08:12:14 +0000

This is a good discussion, you bring up some very good points. Toerless is already one step further, let me first understand how your statements and my understanding match.
Coupling: The way I see it: The ANI *is* coupled with the node and its OS. Yes, there are two variants (constrained ANI and "full" ANI), let's leave that out for now. But, do you agree that the *infrastructure* is the property of a node. It does NOT move, it is actually coupled to the node.
When you talk about decoupling, in my mind that is true for the ASAs. Those should be completely de-coupled, and this is in line with Toerless' thinking: You can run an ASA anywhere, possibly move it around, instantiate it only for a certain time frame, etc.
Do we agree on that? Then, we need to bring into the reference model essentially those statements: "ANI - coupled to a node", and "ASA - decoupled". (And, you're right - that needs to be mentioned!)
Then, let me re-phrase the load balancing example in my words, to see whether I got it: The  loadbalancing intelligence is an ASA, as such it is not coupled to any OS, and can run anywhere. And yes, it can control resources on 1) other AN nodes and 2) non-AN resources, which isn't reflected in the model yet either.
Are we in sync?
To the "boundary" discussion: are you referring to a particular section in the reference model? Not quite clear what you mean here.
Michael

From: Laurent Ciavaglia [mailto:[email-masked]]
Sent: 15 June 2015 16:17
To: Michael Behringer (mbehring); Brian E Carpenter; Anima WG
Subject: Re: [Anima] Domains

I share and support Michael's explanation... and would add to it another level of "decoupling" : decoupling between the autonomic entity and its execution "host".

In summary we would have:
    -An autonomic entity controlling one or more resources. Example: a load balancing optimization autonomic function controlling several routers.
    -The same autonomic entity executing over 'x'. 'x' could be one / part / all of the above routers' OS ; a NMS ; one or several VMs on remote computer(s).

Here we are touching at two models: the coupling model and the deployment model.
-The coupling model is whether the autonomic entity, its executing host(s) and the resource(s) are more or less coupled/integrated:
    . the load balancing optimization autonomic function runs on the OS of the routers it controls ; or
    . the load balancing optimization autonomic function runs on the OS of a computer and uses appropriate commands to effect control on the remote routers.

-The deployment model is intrinsically linked to the capabilities/limitations of the coupling model and autonomic components designs but is also primarily concerned by how the autonomic networks is deployed: more or less centralized/distributed/mix and is dictated by other reasons/constraints such as cost, efficiency...

As we are in the process of documenting ANIMA's reference model, I think we should describe (even briefly) the different setups and be more specific if we face behaviors / situations we wish to avoid or on the contrary wish to enforce.
I don't think it is necessary to go into all the details of the coupling model, as it is/should be available in other references/WGs/SDOs (e.g. IaaS, PaaS and variations of...)

On the resource aspect, we need the assumptions on how it is "shared" in the first place (model and interfaces)(as per Michael's message: "autonomic entities (and possibly domains) that share a non-autonomic entity to negotiate its usage".
In order to operate properly, the autonomic network(s)/functions will have to know (Intent) the resources they are supposed to control, how they can access them (esp. if decoupled) and the extent of their usage rights over these resources. This is also key for the conflict / coordination aspects.
If we don't (and I'm sure we don't) want autonomic networks to be static (configuration-wise), then we will have to cater for these aspects to be exchanged / discovered / negotiated (dynamically) among the participating peers.

Finally, it would be nice to clarify the domain "boundary" or dimension: is it technology, administrative, topology...?

Brain,

Does that make sense?

Michael

-----Original Message-----

Carpenter

Sent: 14 June 2015 22:32

To: Anima WG

Subject: [Anima] Domains

Hi,

|           Shared Resource               |

|                                         |

| |                |   |                | |

| |                |   |                | |

|                                         |

 |   Domain1      |   |   Domain2      |

 |                |   |                |

 |         Shared |   |                |

 |       Resource<|xxx|>               |

 ----------------------

 |              | Shared    Domain2     |

 |              |Resource               |

 |              |     |                 |

 ---------------|------                 |

Regards

    Brian

Anima mailing list

[email-masked]<mailto:[email-masked]>

Anima mailing list

[email-masked]<mailto:[email-masked]>

--

Laurent Ciavaglia
Secure Cloud Networking

phone: +33 160 402 636
email: [email-masked]<mailto:[email-masked]>
linkedin: laurentciavaglia<http://fr.linkedin.com/in/laurentciavaglia/>
address: Route de Villejust | 91620 Nozay | France

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 16 Jun 2015 08:20:23 +0000

>    Constrained ANI   (AN Node)  - Replaces term "Constrained AN Node"

Toerless, 

I'm with you on the ANI. We have full and constrained, and constrained may not be able to "host" all ASAs. So far so good. 

On the ASA, to me "bundled with OS" may be an implementation choice, but not the architectural reference. In the reference doc, I prefer we add "de-coupled from node OS and its ANI" (as suggested by Laurent). 

I'm not sure it makes sense to talk about "constrained ASAs". A resource may be constrained, a user is not. To me, the ANI is a resource, and an ASA is a user of that resource. So maybe we should simply say "a constrained ANI may not be able to run all ASAs" and leave it there? 

Michael

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 16 Jun 2015 08:39:24 +0000

Brian, 

Yes, that needs to be made more clear. 

To me: 
- Administrative domain: All nodes under one administrative control, ex: "example.domain.com". Surely, that has been defined before somewhere and we can leverage that definition? The BGP autonomous system comes to mind. That should be easy. 

Trust is harder, in fact, "trust" is maybe the wrong term. This is really all about authentication and authorization, and maybe we should use those terms for clarity. 

Authentication: an AN node can authenticate all other nodes under the same PKI root. That includes sub-domains for example. But, if I have the root CA cert of another domain, and have decided (policy decision!) to trust that, I can also authenticate other domains. This is all just about knowing who I talk to, nothing more. This is the simple part. 

Now, once I know who I talk to, there are different implications, and those will be partly policy driven, partly defaults. 

Key question is: Authorized to do what? A node can authorize another node to: 
- join the ACP
- negotiate parameters for protocol X. 
- receive intent from. 
- ... 

We need to define a reasonable default authorization scheme, and, going by discussions I've had with operators so far, I think we will need to allow for customization via Intent. 

Example: There is example.com and subdomain.example.com. Should the ACP establish across both? I have heard both customer requirements: 1) Yes, I want one big ACP to manage everything in a flat management hierarchy
2) No, I want the ACP for example.com separate from the ACP for subdomain.example.com. 

Work to be done here... We need to define a good default behaviour, with the hope that there will be minimal exceptions required... 

Michael

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 15 June 2015 22:29
> To: Michael Behringer (mbehring); Anima WG
> We do need to be sure first what a "domain" is. An administrative boundary
> is not necessarily the same as a trust boundary. I can well imagine an entity
> that is in a given admin domain being trusted both in that domain and in
> another domain.
> Also I'm pretty sure that domains can contain domains, both in the admin
> view and in the trust view. But the nesting might not be the same.
> 
> Please note, I don't have a fixed opinion here, I just want clarity in our
> model and terminology.
> 
>      Brian
> 
> >
> > Let's first define what we're talking about: I specifically state "autonomic
> entity" above. I.e., something that can negotiate on its own. That's what
> we're concerned with here. Specifically, a queue in a router is NOT an
> autonomic entity. Therefore, even if several different domains use it, this
> has to be managed by the autonomic entity (the router), which negotiates
> bits and pieces for different domains. But the negotiator is the router, an
> autonomic entity, and that one has only one domain.
> >
> administrative "owner". The one who has root access, enable, short, the full
> admin rights.
> >
> > Example: Take the homenet CPE. There is a managed services model,
> where the SP maintains the CPE, there is the case where the homenet
> owner is controlling the CPE. Inside the home network, there may be a
> device that is owned by a utility, which maybe uses your network to
> communicate with sensors, or uses your Internet connection to call home.
> You may have some influence on the device settings, but the utility is the
> administrative owner.
> >
> > In your bandwidth broker example, there is still ONE autonomic entity
> who has full admin rights over a device (with all its queues, etc). This entity
> grants rights to another domain to use a certain amount of buffering,
> whatever, on the device. A special case of that:
> >
> > Then you get to a case where there is the base hardware which is owned
> by one domain, and say VMs running on top belonging to another domain.
> That is supported, and we should have clear boundaries in this case.
> >
> > Looking at your pictures, I think all three show a "resource" as *not* being
> an autonomic entity, but as a sub-part of an autonomic entity, example was
> the link between two domains. This is where the confusion is coming from.
> If we agree that we're talking about the domain of an *autonomic entity*,
> then the picture is different, and hopefully clearer. Then it's up to the
> autonomic entities (and possibly domains) that share a non-autonomic
> entity to negotiate its usage.
> >
> > Does that make sense?
> > Michael
> >
> >
> >
> >> draft- behringer-anima-reference-model didn't settle before version
> >> -02 came out a few days ago. There's placeholder text in the draft
> >> about Sub-Domains and Cross-Domain Functionality. I suggested that we
> >> domains simultaneously. The question is whether we want our model to
> >> include that possibility? It certainly has implications for security.
> >>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Jun 2015 14:27:41 +1200

> - Administrative domain: All nodes under one administrative control, ex: "example.domain.com". Surely, that has been defined before somewhere and we can leverage that definition? The BGP autonomous…

When is anything ever easy?...

In fact the definition in RFC 1136 is amazingly good still:

     Administrative Domain (AD)

         "A collection of End Systems, Intermediate Systems, and
         subnetworks operated by a single organization or administrative
         authority.  The components which make up the domain are assumed
         to interoperate with a significant degree of mutual trust among
         themselves, but interoperate with other Administrative Domains
         in a mutually suspicious manner" [1].

and it's actually a quotation from ISO/TR 9575, 1989 :-).

> Trust is harder, in fact, "trust" is maybe the wrong term. This is really all about authentication and authorization, and maybe we should use those terms for clarity. 

Well, there's a sequence: I claim an identity, you authenticate that
identity, then you check the authorized capabilities for that identity, and then
you trust me (but only for those specific capabilities).

At an abstract level this is all old news, I guess. It just gets complicated
when authorization and capabilities cross domain boundaries. (I actually
worked on that a bit for grid computing a decade ago; I don't really think
it's relevant but we did publish something, which IBM has charmingly stuck
behind a paywall: http://dx.doi.org/10.1147/sj.434.0689 .)

     Brian

---

From: John Strassner <[email-masked]>
Date: Tue, 23 Jun 2015 21:37:40 -0700

Hi Brian and Michael,

I have three quick comments.

> ...

This is a good start, but imho it is missing a key ingredient: policy.
(Note: if intent means "declarative interface" and not "declarative
policy", as I hypothesized in my last email, then it is missing that as
well).

Alternatively, we could do what I did in DEN-ng: define the concept of a
Domain, subclass to AdministrativeDomain, and subclass this to get a
PolicyDomain. This has the advantage of not altering the semantics of
RFC1136, but rather refining them to include policy-based management. This
also helps with federating domains.

> Trust is harder, in fact, "trust" is maybe the wrong term. This is really
all about authentication and authorization, and maybe we should use those
terms for clarity.

Agreed! Trust comes after authentication and authorization. More
specifically, third-party trust defines a third party that vouches for the
trustworthiness of other parties that want to trust each other, but have no
formal relationship to establish that trust. I guess we could also work in
the concept of direct trust (i.e., when entities from separate domains that
do not have cross-certified exchange keying information are required to
trust each other) as well.

>you trust me (but only for those specific capabilities).

Nicely stated. For me, autonomic nodes advertise capabilities and needs;
both could possibly have constraints. Capabilities define what functions
the node can do (or help do, if it can't complete the function); needs are
what the node needs help in doing. This enables nodes to work together,
sharing their functionality, to accomplish mutually beneficial goals
(and/or beneficial for the community).

regards,
John

On Tue, Jun 16, 2015 at 7:27 PM, Brian E Carpenter <
[email-masked]> wrote:

> > - Administrative domain: All nodes under one administrative control, ex:
> "example.domain.com". Surely, that has been defined before somewhere and
> we can leverage that definition? The BGP autonomous system comes to mind.
> That should be easy.
>
> > Trust is harder, in fact, "trust" is maybe the wrong term. This is
> really all about authentication and authorization, and maybe we should use
> those terms for clarity.
>
> > Authentication: an AN node can authenticate all other nodes under the
> same PKI root. That includes sub-domains for example. But, if I have the
> root CA cert of another domain, and have decided (policy decision!) to
> trust that, I can also authenticate other domains. This is all just about
> knowing who I talk to, nothing more. This is the simple part.
> >
> > Now, once I know who I talk to, there are different implications, and
> those will be partly policy driven, partly defaults.
> >
> > We need to define a reasonable default authorization scheme, and, going
> by discussions I've had with operators so far, I think we will need to
> allow for customization via Intent.
> >
> > Example: There is example.com and subdomain.example.com. Should the ACP
> establish across both? I have heard both customer requirements: 1) Yes, I
> want one big ACP to manage everything in a flat management hierarchy
> > Work to be done here... We need to define a good default behaviour, with
> the hope that there will be minimal exceptions required...
> >
> > Michael
> >
> "autonomic
> full
> being

-- 
regards,
John