clearinghouses (or not)

[David Irwin-3]

> I think the overall point here is that SAs *could* be bundled with
> either CHs or AMs (in our implementation, we bundle them with AMs), but
> that it offers valuable flexibility for the architecture to not *require*
> that it be bundled with either one, since bundling with the CH implies
> more centralization that some of us are comfortable with, and bundling
> with the AM implies that accounts somehow go with resources, which is
> not necessarily desirable either.

I mostly agree here, with one caveat.  I would say that a GENI control
framework architecture should *require* the flexibility to do both
(even in the same deployment at different principals at different
times).

-David

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Robert P Ricci]

Thus spake David Irwin on Fri, Apr 17, 2009 at 01:54:58PM -0400:

> > A slice-name is a global identifier. So, I'm not sure I quite follow
> > your comment about instituions having to establish relationships with
> > every user. If you have some resources I want to use, I approach you
> > with a valid slice name that has been signed by some SA. You look at my
> > request and decide if you want to give me anything, and you very well
> > might look at which SA my slice was created by in making that decision.
> > (In our implementation, every member of the federation is given a list
> > of trusted SAs by the clearinghouse, but this is clearly not the only
> > possible design/policy.)
>
> I was assuming that each Institution runs its own Slice Authority (as
> per Larry's last email in this thread).  I was assuming that this
> Slice Authority only controlled slice names at that institution (and
> not at other institutions, since that would impinge on their own
> ability to control their local policies).  Your comments indicate that
> any institutions SA could apply a policy for creating/naming slices
> that other SAs must (always) conform to.

I don't see this as an issue of policies between different SAs - no SA
is bound by the policy of any other SA. Each SA is creating slice names
independently. The place where the SA's policy might interact with
another entity's policy is with an AM/CM. If an AM knows something (or
doesn't know anything) about a particular SA's policy for slice
creation, it might decide not to give any resources, to give limited
resources, etc. to slices from that SA. (Of course, the AM could have
plenty of other inputs into its policy decision, such as the identity of
the user, etc.)

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[John Wroclawski]

At 11:08 PM -0400 4/16/09, David Irwin wrote:

>
>This is a point that underlies Orca's approach----we put nearly all of
>the discussed functionality (in some form) in our Clearinghouse
>because we can always have multiple Clearinghouses or combine AMs with
>their own Clearinghouse (so the AM takes on its functions) in
>different ways to effectively produce a different "bundle" of
>functions.  Taking the opposite approach---by putting few functions in
>a Clearinghouse initially---may make composing/bundling these
>functions in different ways later on more difficult.
>
>-David

Hi David,

I don't quite understand this argument.

It seems to me there are three separate ideas tied up in the concept
of a clearinghouse as most people are using the word:

1) decoupling - the ability to "disconnect" some functions from the
AM and move them to somewhere else.

2) centralization - the provision of those functions for multiple AMs
in a centralized manner, at one point in the system, rather than in a
distributed way.

3) bundling - tying together several functions in one place.

I agree that the "decoupling" idea is helpful to making composition
or bundling of functions in different ways later on easier. But the
assumptions about centralization and bundling that are also implied
in the current definition seem to work in the opposite direction.

I think what you're saying is that your vision of a clearinghouse is
heavily centered on the decoupling goal, and not so much on the
others - you argue that once functions are decoupled you can easily
move them around, and although you don't mention debundling different
functions into different places, perhaps you're considering it. But
I'm not sure that this definition is completely consistent with how
others are thinking about the word. Am I missing something?

Thanks,
John





_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Aaron Falk]

Larry Peterson wrote:

> Comments inline...
>
> On Fri, Apr 17, 2009 at 9:51 AM, Aaron Falk <falk@...> wrote:
>> On Thu, Apr 16, 2009 at 6:25 PM, Aaron Falk <falk@...> wrote:
>>> Thank you Larry for starting an interesting thread.  You and Rob have
>>> listed several candidate functions for Clearinghouses that don't really
>>> match the clearinghouse functions that Chip described at GEC4 (slide
>>> 15-21 of [1]).  Those functions really revolve around accountability:
>>>
>>>    1. User log-in.  A place for a user to create an account; it needs
>>>    to be capable of validating there is an organization accountable for
>>>    their actions.  It's not clear whether this validation is included
>>>    in the credential manager you mentioned.
>>>
>>>    2. Transaction Logging.  A reliable record of all resources a user
>>>    consumed.  Needed to determine accountability if something bad
>>> happens.
>>>
>>>    3. An ability to enforce global policies.
>>>
>>
>> Larry-
>>
>> In your SFA doc, you define a slice authority to be a principal
>> "responsible for the behavior of a set of slices, vouching for the
>> researchers running experiments in each slice and taking appropriate
>> action should the slice misbehave."  Would you agree that this is
>> roughly analogous to clearinghouse functions 1. and 2. as I've described
>> them?
>
> So what value-added does the clearinghouse provide? My point is that
> the SFA lays out a set of "functions". (We've since identified some new
> "sub-functions" because some people imagine building a widget with less
> functionality than the SFA prescribes, and so want to off-load the missing
> piece to someone else.) As I said before, a clearinghouse is a collection
> these functions -- you choose to bundle functions 1 and 2... the next guy
> chooses to bundle 1, 2, and 3. Bundling is fine, but it's an exercise in
> managing the implementation task (usually by simplifying it in some way).
> It's not prescribing anything architectural.

So, we're building prototypes, right?  "Multiple, competing control
frameworks..."  I think we should be give preference to trying to
understand what the requirements are and what designs can meet them.
IMO, GENI could easily include 100's of aggregates and 1000's of
researchers and I'm trying to understand various approaches to access
control, logging, and global policy is and whether they can accommodate
that kind of scale.  For me, the clearinghouse has been helpful for
reasoning about what functions GENI requires and I have described three
functions that I think are needed.  For each of the functions we can
argue that a) it isn't required, b) we don't need to worry about it now,
or c) there's a design that provides them.   They are bundled in the
clearinghouse because, IMO, they are hard to distribute in a scalable
way and so are natural candidates for centralization.  However, I'm not
wedded to centralizing them, especially if it can be shown that there
are robust approaches for distributed implementation.   It would
particularly helpful to me if you could map SFA functions (or any other)
to them so I can understand how they are achieved.

>> Larry Peterson wrote:
>>> I don't think those are the right functions.
>>>
>>> 1) A place for a user to "log in" -- that's what we have
>>> registries for. You just need to get your university's
>>> authority (PI in PlanetLab-speak) to vouch for you.
>>> Then you acquire the credential(s) you need and
>>> you're off and running.
>> I don't think we should require every university to run a slice
>> authority to be able to participate in GENI.  As the value of the
>> resources that can be acquired in GENI grows, the need for
>> accountability will grow.  There will be policies for what it takes to
>> acquire a GENI log-in (who is vouching for the PI?  what fidelity of
>> out-of-band ID verification is needed?).  This will add to the burden of
>> running a slice authority.
>
> Yes, every university should have a slice authority -- I can't know
> whether to approve Joe Random Student's slice; only you do. That
> does not mean every university runs their own registry, which
> records trust relationships created by slice authorities. In our version,
> PLC runs a registry on behalf of all US universities and PLE runs a
> registry on behalf of all European universities. If one day MIT asks
> to run their own sub-registry, we ought to be able to support that, but
> we don't require it.

OK, this helps.  The SFA says the slice authority is a principal.  But
it's also software, right?  How is an SA bootstrapped?  I.e., who
vouches for the person running the slice authority? Do you expect that
every slice gets reviewed by the person running the SA?  Do you think
there is a key management challenge given the numbers I mentioned above
(1000's of researchers, 100's of aggregates)?  If a particular aggregate
or federation has a policy that applies to, say, US persons.  How might
an SA-minted researcher identity include that as an authoritative attribute?

>>> 2) Transaction logging -- implies a global "red button".
>>> I don't think you have that feature in a truly
>>> federated world. At the end of the day, each
>>> aggregate has to protect itself.
>> I think transaction logging and 'red button' represent two functions,
>> although the latter depends on the former.  Logging gives you a way to
>> figure out what happened after the fact.  If there is an attack launched
>> from GENI resources (deliberate or inadvertent) we should be able to
>> figure out who was accountable for those resources at the time.   Are
>> opposed to collecting any logs of resource utilization?  If not, where
>> do you think they should be?  Do you oppose having a single
>> "authoritative" log?
>
> There is an audit mechanism at the lowest level. It maps network
> activity to slice. It's then a matter of figuring out globally where a
> a bad slice exists. If we do not assume a single centralized slice
> manager -- which I think is the case -- then we do not have a "root"
> from which we can find all aggregates/components hosting that
> slice, so the burden falls to aggregates to watch out for their own
> interests.

That approach seems only to assume a) misbehavior is associated with
network activity (and there are other ways a slice can go out of control
- think wireless) and b) a packet includes sufficient addressing that it
is possible to map it to a slice (packet from lower-layers experiments
might not).  Finally, it requires network reachability to consult the
mechanism and in the worst cases this might not be available.  So, I see
this as a useful tool but not sufficient.

>
> This is a non-trivial discussion that we've had on various phone
> calls. It's difficult to summarize in this context, but in summary,
> unless we mandate a single GENI root/clearinghouse with a big
> red button, and I hope we don't because it negates the advantages
> of federation, then we have to develop other mechanisms by
> which bad slices are squashed.

Nevertheless, I think the question of what does one do about slices that
are out of control is important enough that it shouldn't be punted to
later.  If a centralization approach is the only way to accomplish it,
we should at least prototype one to understand the tradeoffs.

>
>> W.r.t. the 'red button' function, again, as the value of GENI resources
>> grows, the damage that can be done will grow and the need to shutdown
>> slices will grow.  I didn't think you were opposed to that.  I'm not
>> suggesting that the mechanism needs to be centralized, just reliable.
>> (It seems to me that a transaction log would be useful for such
>> mechanisms but perhaps I'm wrong.)  There's the open question of who can
>> request a slice to be shutdown and I don't think we have a sufficient
>> understanding of operations yet to say.  If there is GENI-wide
>> 'meta-operations', it seems to me that they might become aware of slices
>> that need to be shutdown and should probably have that ability.  While
>> it's still too early to say, I think we shouldn't design that out of the
>> system.
>
> I think there's likely some sort of inter-NOC, and humans are involved.
> I don't think I'm ever going to be willing to give you the credential
> to shut
> down a slice on my aggregate. Slices do go bad, but the more common
> scenario is that alarmists throw tantrums about slices without just cause.
>
>>> 3) Global allocation policy -- to the extent anything
>>> is global, then yes, you need something like this.
>>> It corresponds to one of the functions I named
>>> earlier (Resource Manager... I forget which number
>>> I gave it). But again, I think allocation rights originate
>>> with the owner of the aggregate; they may or may
>>> not delegate to a global entity.
>> I think we are in agreement then.  I don't think we've wrapped our heads
>> around the implications of global policy yet but it does seem to me that
>> a consenting aggregate should be able to grant a researcher something
>> that is beyond the 'global' policy.
>
> I agree we don't understand this yet. I do think there are two different
> perspectives (starting points), though. One is based on the presumption
> of a global policy -- it focuses on how we achieve it. The other is based
> on the presumption of aggregate autonomy -- it focuses on mechanisms
> to support peering, should consenting aggregates have incentive to do
> so. I tend to come at this from the latter perspective.

Regardless of perspective,  I am trying to learn whether your SFA is
capable of implementing a policies requiring some global knowledge.
Again, given that we are building prototypes now, it would be good to
understand what it would take to provide that capability.

--aaron



_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[David Irwin-3]

> I don't quite understand this argument.

It actually sounds like you do understand my argument.  Comments below.

> It seems to me there are three separate ideas tied up in the concept of a
> clearinghouse as most people are using the word:
>
> 1) decoupling - the ability to "disconnect" some functions from the AM and
> move them to somewhere else.
>
> 2) centralization - the provision of those functions for multiple AMs in a
> centralized manner, at one point in the system, rather than in a distributed
> way.
>
> 3) bundling - tying together several functions in one place.
>
> I agree that the "decoupling" idea is helpful to making composition or
> bundling of functions in different ways later on easier. But the assumptions
> about centralization and bundling that are also implied in the current
> definition seem to work in the opposite direction.
>
> I think what you're saying is that your vision of a clearinghouse is heavily
> centered on the decoupling goal, and not so much on the others - you argue
> that once functions are decoupled you can easily move them around, and
> although you don't mention debundling different functions into different
> places, perhaps you're considering it. But I'm not sure that this definition
> is completely consistent with how others are thinking about the word. Am I
> missing something?

Yes,  if you get decoupling of functions right, then you can move
these functions around.  As a result, you get the other two ideas you
mention for free (depending on how you shift functions to the
Clearinghouse and away from the AM/CM).   To be clear, I see the merit
in all three of your ideas as it relates to a Clearinghouse's
functions.

However, when people have discussions about Clearinghouses, Slice
Authorities, Slice Managers, Aggregate/Component Managers, etc., they
seem to really be discussing how certain functions are divided up
between them.  My view is that all divisions of functions are useful
and have value (depending on the tradeoffs you want to make and the
scenarios you want to support).  I'd prefer not to preclude any
scenarios.

The goal should then be to decouple functions as much as possible, so
you can support different compositions of functions in the principals
at different times.  In Orca, this assignment of function is fluid.
As one example, the system can organize itself such that AMs reserve
control of their resource/access policies, or it can organize itself
such that all AMs delegate to one or more trusted Clearinghouses.  It
could also do one or the other at different periods of time.

-David

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Ted Faber]

On Fri, Apr 17, 2009 at 10:31:53AM -0600, Robert P Ricci wrote:
> In my interpretation, an SA is a thing that has the ability to create
> new slice names. So, a user walks up to an SA, says "I want to create a
> slice", and that SA makes some policy decision about whether it's going
> to let them. If the SA decides to make a new slice name for the user, it
> bears some responsibility for what happens in that slice. An SA "vouches
> for" a slice by giving it a name.

Creating the slice/experiment as a first class object (with a name) is
one of the primary things fedd does on TIED as well.  It does roll the
creation of the esperiment/slice in with the creation of the name, but
these are separable.

--
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG


_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[John Wroclawski]

At 11:34 AM -0600 4/17/09, Robert P Ricci wrote:
>  Similarly, in Emulab, every experiment is
>associated with a "project", so I know I can talk to the person who's
>registered as the head of the project that experiment is a part of if I
>have any issues with the experiment. The TIED project uses the same
>structure, as far as I know, as Emulab, since that's what it's built on.

well, just for the record, this is true today but in terms of access
control, etc, we're heading in the direction of a richer model based
on attribute logic. This is somewhat relevant because

a) various places in this discussion where people have written "we
delegate x to y" (say, "we delegate authorization to a
clearinghouse") are handled transparently - aka "just work" - within
the logic, and

b) it could potentially break the simple "talk to the head of the
project" model if you let it. But on the other hand it offers a much
more flexible version of "who the blazes said that was a good idea,
anyway?".

We -are- now getting close to some interesting policy issues of who
gets to know what, which I think have some room for growth in the
current story. but that's a bit beyond the technical question at hand
here.

john

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Robert P Ricci]

Thus spake Aaron Falk on Fri, Apr 17, 2009 at 03:38:34PM -0400:

> > Yes, every university should have a slice authority -- I can't know
> > whether to approve Joe Random Student's slice; only you do. That
> > does not mean every university runs their own registry, which
> > records trust relationships created by slice authorities. In our version,
> > PLC runs a registry on behalf of all US universities and PLE runs a
> > registry on behalf of all European universities. If one day MIT asks
> > to run their own sub-registry, we ought to be able to support that, but
> > we don't require it.
>
> OK, this helps.  The SFA says the slice authority is a principal.  But
> it's also software, right?

Yeah, this confusion has existed for a long time - I like to think of it
as the code that's acting on behalf of a (particular) principal.

> How is an SA bootstrapped?  I.e., who
> vouches for the person running the slice authority?

I think this boils down to how each CF chooses to establish federation.
In our model, new SAs are accepted into the federation by the entity
running the federation, which everyone has agreed to trust.
I could imagine that other CFs might choose to have members of the
federation come up with pairwise agreements to accept each others' SAs,
to have a "root" SA that authorizes other SA, or to come up with even
more complex schemes.

> Do you expect that
> every slice gets reviewed by the person running the SA?  Do you think
> there is a key management challenge given the numbers I mentioned above
> (1000's of researchers, 100's of aggregates)?

I expect that this is not specified by the architecture. The point of
the SA is to encapsulate this policy. In the PlanetLab model as it
stands today, yes, because the PI has to make the slice her/himself. In
the Emulab model as it stands today, no, because the project leader can
delegate creation rights to members of the project.

An entity trying to decide if it's going to trust an SA might use the
policy in use at the SA to decide whether or not to trust it. DETER
might decide to only trust SAs that have some kind of vetting process
for slices (like it does today for experiments), Emulab might be willing
to trust SAs with looser policies.

The main think I like about the SA abstraction is that it allows for a
large number of decisions about where to place SAs and what their
policies for issuing slice names can be.

> If a particular aggregate
> or federation has a policy that applies to, say, US persons.
> How might
> an SA-minted researcher identity include that as an authoritative attribute?

I see this as a separate statement - sounds like TIED is working on a
way to say things like this, and we've considered the idea that some
credentials may be simply assertions like this - there's some authority
that can hand out "is a US person" credentials, which the user could
present if talking to any entity that might behave differently for US
persons. (Of course, this only works for positive assertions, not
negative ones.)

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Ted Faber]

On Fri, Apr 17, 2009 at 11:34:46AM -0600, Robert P Ricci wrote:

> To be a little more concrete - in PlanetLab, every slice is associated
> with a 'site', so I know if the slice utah_robsbadslice is sending
> apparent attack traffic, hogging resources, or whatever, I can talk to
> Utah to complain about it. (I could talk to the slice's creator too, but
> if s/he's behaving badly, I need to be able to talk to whoever has taken
> responsibility for her/him). Similarly, in Emulab, every experiment is
> associated with a "project", so I know I can talk to the person who's
> registered as the head of the project that experiment is a part of if I
> have any issues with the experiment. The TIED project uses the same
> structure, as far as I know, as Emulab, since that's what it's built on.
> I believe ORBIT has some kind of similar structure, and I don't know
> about ORCA.

I see John's talked a little about the authorization model, but there's
one more sublety to the TIED world, even under the current model, that
may be interesting.  The following is how it works today.

Who one could talk to about a misbehaving experiment depends on who one
is and what action they want to take.  When a federated experiment is
created in TIED, the federator (fedd) requests access from the federants
based on a global name and attribute space.  Right now the attributes in
that space are <testbed, project, user> - extended from the Emulab model
- but they're a separate space from the local federants' project space.
When a federant grants access it maps the incoming sub-experiment into
its local <project, user> space.  Within that local space there may be a
bunch of relevant data about the real-world generator of that project
that is local to the federant.  On the other side the federator may have
a collection of real world information about the creator of the
federated experiment.  Access to those local stores of information are
controlled by their respective owners.

To be concrete about it, consider an experimenter creating a federated
experiment across two testbeds, T1 and T2, using a federator located at
T3.  The experimenter makes the request to T3, and gives a global
credential to identify themselves (this is an X.509 cert that's acting
as one of our global names (a fedid) - more at
http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#AccessControl ).  Based
on that name the fedd at T3 can assert to the other testbeds that, for
example, this is user "faber" in the projects "federators" and
"operators" on testbed "T3."

Let T1 be a very loosely controlled testbed that allocates resources for
federated experiments out of its "loose_federation" project with a generic
user with no real world identification attached.  Any T3 user is allowed
access to that group and the T3 fedd need only tell the T1 testbed that a
T3 user is requesting resources and T1 will return the information
necessary to allocate an experiment in that project on T1.

Let T2 only allow experimenters with the "operators" project attribute
asserted on T3 to allocate resources and those resources are mapped to
its "tracable_federation" project.  That T2 project has the real world
information of a responsible T3 principal associated with it.  This
exchange of information was done out of band as a prerequisite for
federation.

A more diligent testbed might map the global user identity to a local
user identity as well.  Similarly, based on which attributes the T3 fedd
was able to assert, the local testbed may pick the local project from a
set with different information and rights attached - e.g., operators can
allocate more nodes.

Because our experimenter has the relevant attributes (and assuming the
resources are available and allocated) the T3 fedd will be able to
create a federated experiment, which it will name and associate with the
experimenter.

Notice that based on the global attributes (testbed and operator),
sub-experiments are associated with differnet local projects
(loose_federation and tracable_federation) on each testbed.

Now if the experiment begins doing bad things, the T1 and T2 admins have
access to different information.  The T1 admins only know something in
the "loose_federation" project is acting up.  They can take action on
their sub-part or make a request to the T3 fedd for more information
about the experiment or the experimenter (though that interface isn't
yet available) or to terminate the experiment as a whole (that one is).
Exactly how the fedd will react to those requests is dependent on the
agreements between T1 and T3, but the T1 admins can always shut down
their sub-experiment.

On T2 the situation is somewhat different.  Because they gathered
information as a prerequisite to federation (not to instantiating this
experiment in particular, though), they have more local information to
work with as far as who they can talk to.  All the options of contacting
the T3 fedd are also open, as are the options of unilateral action on
their own resources.

This setup allows the testbeds to make their own decisions about how
much information they need as federation prerequisites and what range of
accountability they require.

--
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG


_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Max Ott-2]

My head is spinning after reading the entire thread in one go. I  
wonder if we can agree on some basic functional blocks we need to make  
this work and on which we can build on to allow for more and more  
complex scenarios.

In the simplest case we have experimenters wanting resources which are  
managed by aggregates (I know that's already an assumption but I  
didn't see much opposition to that).

There needs to be some mechanism to discover which aggregates can  
provide a set of  resources (I specifically don't require a list of  
available resources. However we need a mechanism to describe  
resources  - the requirements for that may differ between different  
actors )

There needs to be a mechanism for requesting resources from  
aggregates. At this stage someone needs to decide:
        a) Is the requester 'allowed' to make the request. Basically is there  
some kind of 'link' between the aggregate and the requester which for  
most of our facilities includes some kind of legal agreement and some  
delegation model.
        b) should the request be granted. Basically a resource allocation  
decision based on some policy.

As this decision has some lasting effects we need some kind of entity  
to represent this session. I assume this is the famous 'slice'  which  
seems to be mean different things to different people. Not sure if it  
is really much more than a handle for different entities to hang  
different things onto it. But it seem to have acquired some mythical  
status by now :)

What else do we need?

* A way for an experimenter to be notified when a resource is  
available, how to access it, manage and control it, or  is misbehaving  
(e.g. dying), or is being taken away (because we have to give a demo  
to someone important :)

* A way to add or remove resources from the session (alright it's  
called a slice around here)

- A way for somebody else to complain that a certain resource seems to  
be doing something bad

* The famous 'red shining button' to shutdown all resources belonging  
to a slice within an aggregate (as long as presenting the right  
credentials and like Larry I'm arguing for this to be a aggregate  
level issue)

* A way to investigate the state of an aggregate and its resources and  
infrastructure (given the right credentials) - this is not fundamental  
(but IMHO essential)

----

Anything else fundamentally missing? I'm basically interested in  
clearly separating control flows, from trust chains, from policy based  
decision points.

After after all we need to make it as painless as possible for  
experimenters to find the resources the need for their experiments as  
well as for aggregate owners to feel comfortable to join a federated  
world (and their lawyers to let them).

Cheers,

-max






_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[David Irwin-3]

Hi Max,

>From the thread, I think there actually was a general agreement on a
group of functional building blocks (of course, there were a couple of
sub-threads debating different things), that correspond more or less
to what you describe.  The primary debate from my perspective seemed
to be over how these functions get divided up between the different
principals in GENI (Clearinghouse, AM, etc.).   I won't rehash the
debate (lest I risk heating this thread up again).

-David

On Mon, Apr 20, 2009 at 9:36 AM, Max Ott <max.ott@...> wrote:

> My head is spinning after reading the entire thread in one go. I
> wonder if we can agree on some basic functional blocks we need to make
> this work and on which we can build on to allow for more and more
> complex scenarios.
>
> In the simplest case we have experimenters wanting resources which are
> managed by aggregates (I know that's already an assumption but I
> didn't see much opposition to that).
>
> There needs to be some mechanism to discover which aggregates can
> provide a set of  resources (I specifically don't require a list of
> available resources. However we need a mechanism to describe
> resources  - the requirements for that may differ between different
> actors )
>
> There needs to be a mechanism for requesting resources from
> aggregates. At this stage someone needs to decide:
>        a) Is the requester 'allowed' to make the request. Basically is there
> some kind of 'link' between the aggregate and the requester which for
> most of our facilities includes some kind of legal agreement and some
> delegation model.
>        b) should the request be granted. Basically a resource allocation
> decision based on some policy.
>
> As this decision has some lasting effects we need some kind of entity
> to represent this session. I assume this is the famous 'slice'  which
> seems to be mean different things to different people. Not sure if it
> is really much more than a handle for different entities to hang
> different things onto it. But it seem to have acquired some mythical
> status by now :)
>
> What else do we need?
>
> * A way for an experimenter to be notified when a resource is
> available, how to access it, manage and control it, or  is misbehaving
> (e.g. dying), or is being taken away (because we have to give a demo
> to someone important :)
>
> * A way to add or remove resources from the session (alright it's
> called a slice around here)
>
> - A way for somebody else to complain that a certain resource seems to
> be doing something bad
>
> * The famous 'red shining button' to shutdown all resources belonging
> to a slice within an aggregate (as long as presenting the right
> credentials and like Larry I'm arguing for this to be a aggregate
> level issue)
>
> * A way to investigate the state of an aggregate and its resources and
> infrastructure (given the right credentials) - this is not fundamental
> (but IMHO essential)
>
> ----
>
> Anything else fundamentally missing? I'm basically interested in
> clearly separating control flows, from trust chains, from policy based
> decision points.
>
> After after all we need to make it as painless as possible for
> experimenters to find the resources the need for their experiments as
> well as for aggregate owners to feel comfortable to join a federated
> world (and their lawyers to let them).
>
> Cheers,
>
> -max
>
>
>
>
>
>
> _______________________________________________
> control-wg mailing list
> control-wg@...
> http://lists.geni.net/mailman/listinfo/control-wg
>

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Aaron Falk]

Ted-

This is quite interesting and gives me a much better idea of what TIED
is trying to accomplish but left me with several questions (inline).

Ted Faber wrote:

>
> I see John's talked a little about the authorization model, but there's
> one more sublety to the TIED world, even under the current model, that
> may be interesting.  The following is how it works today.
>
> Who one could talk to about a misbehaving experiment depends on who one
> is and what action they want to take.  When a federated experiment is
> created in TIED, the federator (fedd) requests access from the federants
> based on a global name and attribute space.  Right now the attributes in
> that space are <testbed, project, user> - extended from the Emulab model
> - but they're a separate space from the local federants' project space.
> When a federant grants access it maps the incoming sub-experiment into
> its local <project, user> space.  Within that local space there may be a
> bunch of relevant data about the real-world generator of that project
> that is local to the federant.  

The "real-world generator of that project" is the researcher.  (Right?)
How does the federant get this information?  The researcher's access is
via the federator.  (Right?)  Suppose a federant is interested in the
attribute that states whether a user is staff, student, or faculty.  How
does it learn that about a user?

> On the other side the federator may have
> a collection of real world information about the creator of the
> federated experiment.  Access to those local stores of information are
> controlled by their respective owners.
>  
> To be concrete about it, consider an experimenter creating a federated
> experiment across two testbeds, T1 and T2, using a federator located at
> T3.  The experimenter makes the request to T3, and gives a global
> credential to identify themselves (this is an X.509 cert that's acting
> as one of our global names (a fedid) - more at
> http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#AccessControl ).  Based
> on that name the fedd at T3 can assert to the other testbeds that, for
> example, this is user "faber" in the projects "federators" and
> "operators" on testbed "T3."
>
> Let T1 be a very loosely controlled testbed that allocates resources for
> federated experiments out of its "loose_federation" project with a generic
> user with no real world identification attached.  Any T3 user is allowed
> access to that group and the T3 fedd need only tell the T1 testbed that a
> T3 user is requesting resources and T1 will return the information
> necessary to allocate an experiment in that project on T1.
>
> Let T2 only allow experimenters with the "operators" project attribute
> asserted on T3 to allocate resources and those resources are mapped to
> its "tracable_federation" project.  That T2 project has the real world
> information of a responsible T3 principal associated with it.  This
> exchange of information was done out of band as a prerequisite for
> federation.
>  

Does this require that every institution with users run fedd?  If so, I
think that I understand how to answer my question above by creating
'projects' for staff, students, and staff (since that distinction is
important to me).  But it seems that having a small and useful (albeit
extensible) set of attributes defined early will be important since it
sounds like every federator needs to understand every attribute required
by a federant.  (Right?)  It seems there is some risk that this could
become unmanageable if federants were inventing lots of new attributes
(say, with poorly defined or overlapping definitions).

> A more diligent testbed might map the global user identity to a local
> user identity as well.  Similarly, based on which attributes the T3 fedd
> was able to assert, the local testbed may pick the local project from a
> set with different information and rights attached - e.g., operators can
> allocate more nodes.
>
> Because our experimenter has the relevant attributes (and assuming the
> resources are available and allocated) the T3 fedd will be able to
> create a federated experiment, which it will name and associate with the
> experimenter.
>
> Notice that based on the global attributes (testbed and operator),
> sub-experiments are associated with differnet local projects
> (loose_federation and tracable_federation) on each testbed.
>  

I don't quite get this.  "Loose federation" and "traceable federation"
seem like authorization policies, not projects.  I think you are using
'project' in a new way.  Can you give a definition? (Or just clarify?)

> Now if the experiment begins doing bad things, the T1 and T2 admins have
> access to different information.  The T1 admins only know something in
> the "loose_federation" project is acting up. They can take action on
> their sub-part or make a request to the T3 fedd for more information
> about the experiment or the experimenter (though that interface isn't
> yet available) or to terminate the experiment as a whole (that one is).
> Exactly how the fedd will react to those requests is dependent on the
> agreements between T1 and T3, but the T1 admins can always shut down
> their sub-experiment.
>
> On T2 the situation is somewhat different.  Because they gathered
> information as a prerequisite to federation (not to instantiating this
> experiment in particular, though), they have more local information to
> work with as far as who they can talk to.  

Meaning, they know more about the identity of the user?  Or do you mean
something else?

> All the options of contacting
> the T3 fedd are also open, as are the options of unilateral action on
> their own resources.
>
> This setup allows the testbeds to make their own decisions about how
> much information they need as federation prerequisites and what range of
> accountability they require.
>  

So, this sounds quite interesting and cool.  Nevertheless, if every
institution runs a fedd, I'm concerned about the number of agreements
involved.  Seems like this flexibility could make it hard to grow the
number of institutions who can use GENI or to have "most" components
available to "most" users.  Am I missing something?

--aaron

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

[Ted Faber]

On Mon, Apr 20, 2009 at 10:55:24AM -0400, Aaron Falk wrote:
> Ted-
>
> This is quite interesting and gives me a much better idea of what TIED
> is trying to accomplish but left me with several questions (inline).

Let me also point you to
http://fedd.isi.deterlab.net/trac
particularly
http://fedd.isi.deterlab.net/trac/wiki/FeddAbout
and
http://fedd.isi.deterlab.net/trac/wiki/FeddPubs

Those go into more detail than these messages can.  Of course, TIED and
the DFA are moving targets and I'm happy to clarify.

>
> Ted Faber wrote:
> >
> > I see John's talked a little about the authorization model, but there's
> > one more sublety to the TIED world, even under the current model, that
> > may be interesting.  The following is how it works today.
> >
> > Who one could talk to about a misbehaving experiment depends on who one
> > is and what action they want to take.  When a federated experiment is
> > created in TIED, the federator (fedd) requests access from the federants
> > based on a global name and attribute space.  Right now the attributes in
> > that space are <testbed, project, user> - extended from the Emulab model
> > - but they're a separate space from the local federants' project space.
> > When a federant grants access it maps the incoming sub-experiment into
> > its local <project, user> space.  Within that local space there may be a
> > bunch of relevant data about the real-world generator of that project
> > that is local to the federant.  
>
> The "real-world generator of that project" is the researcher.  (Right?)

Yep.

> How does the federant get this information?  The researcher's access is
> via the federator.  (Right?)  Suppose a federant is interested in the
> attribute that states whether a user is staff, student, or faculty.  How
> does it learn that about a user?

Federators and federants can agree on the meaning of certain attributes.
In the current <testbed, project, user> layout the kind of attributes
you're thinking of could be encoded as projects.  Don't get too caught
up in the "project" name.  A "testbed" in this name space is a
federating entity, a "project" is a group of users that share an
attribute, and a "user" is an individual.  The names are an artifact of
generalizing the Emulab namespace (and probably my limited understanding
of that name space).

So if federating entity A trusts federating entity B to identify faculty
members by putting them in a "faculty" group, that's how the
communication above happens.  Note that the entity asserting that a user
is a faculty person does not need to be associated with a physical
groups of resources.  Some central GENI site could do that coordination,
even if it's not managing a testbed (or running Emulab software).
That's to say that fedd will run on your desktop for the purpose of
getting resources from other testbeds and coordinating experiments.  I
think that's to say it can act as a slice manager.

Our plans to got to ABAC are motivated by that system being able to
express more complex authorization relations.  Under the simple system
above, scaling is limted by the number of "testbeds" a given resource
allocator trusts.  ABAC lets me split that up more by saying testbed A
trusts facility F to certify faculty-asserting testbeds.  Testbed A
trusts the faculty "group" (or attribute) from any testbed that facility
F trusts.  That delegation improves scalability, and is only one ABAC
example.

>
> > On the other side the federator may have
> > a collection of real world information about the creator of the
> > federated experiment.  Access to those local stores of information are
> > controlled by their respective owners.
> >  
> > To be concrete about it, consider an experimenter creating a federated
> > experiment across two testbeds, T1 and T2, using a federator located at
> > T3.  The experimenter makes the request to T3, and gives a global
> > credential to identify themselves (this is an X.509 cert that's acting
> > as one of our global names (a fedid) - more at
> > http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#AccessControl ).  Based
> > on that name the fedd at T3 can assert to the other testbeds that, for
> > example, this is user "faber" in the projects "federators" and
> > "operators" on testbed "T3."
> >
> > Let T1 be a very loosely controlled testbed that allocates resources for
> > federated experiments out of its "loose_federation" project with a generic
> > user with no real world identification attached.  Any T3 user is allowed
> > access to that group and the T3 fedd need only tell the T1 testbed that a
> > T3 user is requesting resources and T1 will return the information
> > necessary to allocate an experiment in that project on T1.
> >
> > Let T2 only allow experimenters with the "operators" project attribute
> > asserted on T3 to allocate resources and those resources are mapped to
> > its "tracable_federation" project.  That T2 project has the real world
> > information of a responsible T3 principal associated with it.  This
> > exchange of information was done out of band as a prerequisite for
> > federation.
> >  
>
> Does this require that every institution with users run fedd?  If so, I
> think that I understand how to answer my question above by creating
> 'projects' for staff, students, and staff (since that distinction is
> important to me).

To work with TIED you have to support fedd's interfaces.  We don't much
care if you run our code.  The interface definitions are here:
http://fedd.isi.deterlab.net/trac/browser/fedd/trunk/wsdl
There are comments, etc. there and the papers help understand it as
well, but I'm happy to work through the details with people.

>                    But it seems that having a small and useful (albeit
> extensible) set of attributes defined early will be important since it
> sounds like every federator needs to understand every attribute required
> by a federant.  (Right?)

If a federant requires an attribute a federator has never heard of in
order to grant access, well, there's an obvious problem there.  But it's
possible for a federator and federant to carry on successful
negotiations when the federator knows a subset of the attributes that
the federant understands.

It seems reasonable to me that testbeds/federants would grant some basic
resource allocation to users with minimal information.  That might not
be the way it happens in practice.

>                           It seems there is some risk that this could
> become unmanageable if federants were inventing lots of new attributes
> (say, with poorly defined or overlapping definitions).

This is possible, of course; I think it's somewhat unlikely.

The purpose of attributes are to allow resource sharing.  I think people
motivated to share resources will come up with sets of vaild, meaningful
attributes and will arrive at de facto standards.  I also think the GPO
and the working groups provide a place for discussions on those
standards.

Notice that the set of attributes that most providers understand when
asserted (the attribute ontology) is different from the trust in those
assertions.  Those need to be separated, at least architecturally.  I
mention it because InCommon merges the two.

>
> > A more diligent testbed might map the global user identity to a local
> > user identity as well.  Similarly, based on which attributes the T3 fedd
> > was able to assert, the local testbed may pick the local project from a
> > set with different information and rights attached - e.g., operators can
> > allocate more nodes.
> >
> > Because our experimenter has the relevant attributes (and assuming the
> > resources are available and allocated) the T3 fedd will be able to
> > create a federated experiment, which it will name and associate with the
> > experimenter.
> >
> > Notice that based on the global attributes (testbed and operator),
> > sub-experiments are associated with differnet local projects
> > (loose_federation and tracable_federation) on each testbed.
> >  
>
> I don't quite get this.  "Loose federation" and "traceable federation"
> seem like authorization policies, not projects.  I think you are using
> 'project' in a new way.  Can you give a definition? (Or just clarify?)

"Loose_federation" and "traceable_federation" are  Emulab groups on the
local testbeds the names are supposed to be illustrative, but nothing
else.  I could have called them "fred" and "ethel" but I was hoping to
make things easier to follow.  (Apparently that didn't work out...)

In Emulab, a user's right to allocate resources is bound to their
membership in a project (and groups within that project, but I'm
simiplifying here).  Because a federator doesn't know the local
allocation policies and permissions in detail and the local federant
similarly needn't know the global policies. there's a step where we
shift from the federator saying "here's what you wanted to know about
this user" into the local testbed saying "this user has the following
rights in my world".  Mapping from the global name/attribute space into
a local Emulab project is how we implement that mapping now.

Alos associated with a project is a set of data about the person who was
given the rights to that project (phone #, e-mail address, etc.).  In
addition to binding the rights to the user, it binds the contact
information.  See below.

>
> > Now if the experiment begins doing bad things, the T1 and T2 admins have
> > access to different information.  The T1 admins only know something in
> > the "loose_federation" project is acting up. They can take action on
> > their sub-part or make a request to the T3 fedd for more information
> > about the experiment or the experimenter (though that interface isn't
> > yet available) or to terminate the experiment as a whole (that one is).
> > Exactly how the fedd will react to those requests is dependent on the
> > agreements between T1 and T3, but the T1 admins can always shut down
> > their sub-experiment.
> >
> > On T2 the situation is somewhat different.  Because they gathered
> > information as a prerequisite to federation (not to instantiating this
> > experiment in particular, though), they have more local information to
> > work with as far as who they can talk to.  
>
> Meaning, they know more about the identity of the user?  Or do you mean
> something else?

T2 may have gotten infromation about the particular users that they'll
allow on.  More likely, they got enough information to track down a
particular user in the event of a problem.  For example, a tightly run
textbed might get the name and phone of every student who would
federate; a more relaxed testbed might get the phone number of a
responsible member from each research team; a more relaxed one might get
the phone number of the folks running the federator.

This is another spot where it helps to understand the Emulab model a
little, to get our intuition.  An Emulab project has a leader (think
research PI) who can add access to other users (think graduate
researchers).  The testbed operators (DETER, Emulab) set rules about
what kind of information a project leader must provide and how well it's
vetted.  Similarly, the information for each user is vetted by the PI
(and made available to testbed operators).

If an experiment goes awry on DETER (which is the testbed I heve
experience with), we tend to try to contact the user who started the
experiment firts, and if that fails, talk to the project leader.  We
understand that user information may be less vetted that leader
information (which we vet ourselves, pretty carefully).  The trade off
is that we don't have to be involved with the hundreds of user
authorizations, but when an experiment goes awry we may not have
immediate access to the person who started it (though we have a
connection to someone who does have access to them).

It's the same game in the federated world.  The more information a
federant requires for a given allocation, the more directly they can
address misbehavior, but the more interactions there need to be when
federating.

Our point isn't to take a position on whether federants should gather a
lot of information or a little.  Our architecture allows both, and we'll
let the players decide.

>
> > All the options of contacting
> > the T3 fedd are also open, as are the options of unilateral action on
> > their own resources.
> >
> > This setup allows the testbeds to make their own decisions about how
> > much information they need as federation prerequisites and what range of
> > accountability they require.
> >  
>
> So, this sounds quite interesting and cool.  Nevertheless, if every
> institution runs a fedd, I'm concerned about the number of agreements
> involved.  Seems like this flexibility could make it hard to grow the
> number of institutions who can use GENI or to have "most" components
> available to "most" users.  Am I missing something?

You have the limits of the current implementation clear.  That's why I'm
quick to point out the shift to ABAC, which will scale better.

--
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG


_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg