« Return to Thread: do component managers need to authenticate researchers?
Re: do component managers need to authenticate researchers?
by Jeff Chase
::
Rate this Message:
I would like to ask a clarifying question. It seems to be implicit in
this proposal and supporting material that the AM is viewed as the
switch element itself (or other substrate component). If so, then
simplicity for the AM control protocol would be a dominating design
concern, since the protocol must be supported by the components/aggregates.
Is my interpretation correct?
An alternative is to place one or more stateful management servers in
the aggregate's domain, and give each one control over some set of
components/aggregates within that domain. In Cluster D (Orca) we call
each aggregate's management server its controlling "authority" (e.g., a
site authority or domain authority). The authority acts on behalf of
the aggregate's owner, and represents the aggregate externally, i.e., it
serves the AM role in the control plane protocol. The interface between
the aggregate/component and its authority can be quite simple. For
example, the component could maintain an SSL connection with its
authority, instead of with the CH as proposed here. Or the interface
could be customized for different components/aggregates, since it is not
invoked from outside of the aggregate's domain. It could use HMACs or
whatever instead of SSL.
I think the authority can play the role of the "AM Security Connection
Point (AM-SCP)", the alternative suggested by Steve Schwab. Leigh
Stoller's concern about a central point of failure applies to the
authority as well, but you can partition the set of
components/aggregates across as many authority servers as you want, and
if an authority fails, then it only affects the components it directly
controls. The authority offloads all the nasty
authentication/authorization stuff from the components and aggregates,
and in general, decouples components/aggregates from having to
understand the control plane protocols. The authority may be complex,
but that is not so bad, because it is largely an off-the-shelf code with
some plugins specific to the components/aggregate types that it
controls. The biggest downside is that the resource provider needs a
server to run it on.
This approach seems to me to be preferable to having the CH mediate all
communication between the researcher tools and components/aggregates, as
proposed here. It meets the goal of the proposal as I understand it
(easy integration of new component types?) with only some of the
drawbacks.
Jeff
Aaron Falk wrote:
> Several folks from Cluster B and the GPO met a few weeks ago to discuss
> how to network switches would be integrated into this cluster. Guido
> Appenzeller, from the Enterprise GENI project. had some thoughts on
> changes to the conceptual design's authentication approach that are
> worth repeating here and possibly discussing further. (Slides, minutes,
> other reading can be found at [1]. In particular, see slides 41-50 of [2].)
>
> To illustrate the issue, let's take the case of a researcher who wants
> to contact an aggregate manager (AM) to make a resource reservation.
> Notionally, a researcher would send this request and include signed
> credentials that would give him authority to perform this task. The
> aggregate manager would verify the credentials were signed by an entity
> the AM trusted.
>
> The proposal on the table is for a simpler approach. The AM maintains
> an SSL connection to the clearinghouse (CH). Researcher credentials are
> sent to the AM by way of the clearinghouse and the validates the
> credentials before forwarding the request to the AM. This removes
> burden of validating the credentials from the AM at the expense of
> forcing requests to pass through the clearinghouse.
>
> There is a fundamental change here in the need for a GENI-wide PKI is
> removed and the crypto functions in the AM are reduced to maintaining an
> SSL connection. Also, the aggregate manager's control plane API becomes
> much simpler, e.g., roles and credentials added many calls and options
> to the PlanetLab Slice-Federated Architecture. However, this changes
> the message flow in GENI in a significant way, making the clearinghouse
> a waypoint for control plane communications between researches and AMs.
>
> >From a near-term, implementation perspective, this seems like a
> advantageous change. A complex, not-well-understood function
> (researcher credential authentication) has been moved out of the
> development path of aggregates and their managers. However, I'd like to
> understand what the costs are of this design.
>
> Thanks,
>
> --aaron
>
> ps. Cluster B is going to add a prototype interface of this design. In
> fact, a PLC geniwrapper initial patch is already available at [3].
>
> pps. There was also an interesting discussion of the benefits of
> SOAP/XSDL as compared to Pyton/XML-RPC and the patch above represents an
> XSDL implementation of a control plane API.
>
> [1] http://groups.geni.net/geni/wiki/ClusterB
> [2]
> http://groups.geni.net/geni/attachment/wiki/ClusterB/Enterprise%20Geni.pdf
> [3] http://www.openflowswitch.org/wk/index.php/GENILight
>
>
>
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
this proposal and supporting material that the AM is viewed as the
switch element itself (or other substrate component). If so, then
simplicity for the AM control protocol would be a dominating design
concern, since the protocol must be supported by the components/aggregates.
Is my interpretation correct?
An alternative is to place one or more stateful management servers in
the aggregate's domain, and give each one control over some set of
components/aggregates within that domain. In Cluster D (Orca) we call
each aggregate's management server its controlling "authority" (e.g., a
site authority or domain authority). The authority acts on behalf of
the aggregate's owner, and represents the aggregate externally, i.e., it
serves the AM role in the control plane protocol. The interface between
the aggregate/component and its authority can be quite simple. For
example, the component could maintain an SSL connection with its
authority, instead of with the CH as proposed here. Or the interface
could be customized for different components/aggregates, since it is not
invoked from outside of the aggregate's domain. It could use HMACs or
whatever instead of SSL.
I think the authority can play the role of the "AM Security Connection
Point (AM-SCP)", the alternative suggested by Steve Schwab. Leigh
Stoller's concern about a central point of failure applies to the
authority as well, but you can partition the set of
components/aggregates across as many authority servers as you want, and
if an authority fails, then it only affects the components it directly
controls. The authority offloads all the nasty
authentication/authorization stuff from the components and aggregates,
and in general, decouples components/aggregates from having to
understand the control plane protocols. The authority may be complex,
but that is not so bad, because it is largely an off-the-shelf code with
some plugins specific to the components/aggregate types that it
controls. The biggest downside is that the resource provider needs a
server to run it on.
This approach seems to me to be preferable to having the CH mediate all
communication between the researcher tools and components/aggregates, as
proposed here. It meets the goal of the proposal as I understand it
(easy integration of new component types?) with only some of the
drawbacks.
Jeff
Aaron Falk wrote:
> Several folks from Cluster B and the GPO met a few weeks ago to discuss
> how to network switches would be integrated into this cluster. Guido
> Appenzeller, from the Enterprise GENI project. had some thoughts on
> changes to the conceptual design's authentication approach that are
> worth repeating here and possibly discussing further. (Slides, minutes,
> other reading can be found at [1]. In particular, see slides 41-50 of [2].)
>
> To illustrate the issue, let's take the case of a researcher who wants
> to contact an aggregate manager (AM) to make a resource reservation.
> Notionally, a researcher would send this request and include signed
> credentials that would give him authority to perform this task. The
> aggregate manager would verify the credentials were signed by an entity
> the AM trusted.
>
> The proposal on the table is for a simpler approach. The AM maintains
> an SSL connection to the clearinghouse (CH). Researcher credentials are
> sent to the AM by way of the clearinghouse and the validates the
> credentials before forwarding the request to the AM. This removes
> burden of validating the credentials from the AM at the expense of
> forcing requests to pass through the clearinghouse.
>
> There is a fundamental change here in the need for a GENI-wide PKI is
> removed and the crypto functions in the AM are reduced to maintaining an
> SSL connection. Also, the aggregate manager's control plane API becomes
> much simpler, e.g., roles and credentials added many calls and options
> to the PlanetLab Slice-Federated Architecture. However, this changes
> the message flow in GENI in a significant way, making the clearinghouse
> a waypoint for control plane communications between researches and AMs.
>
> >From a near-term, implementation perspective, this seems like a
> advantageous change. A complex, not-well-understood function
> (researcher credential authentication) has been moved out of the
> development path of aggregates and their managers. However, I'd like to
> understand what the costs are of this design.
>
> Thanks,
>
> --aaron
>
> ps. Cluster B is going to add a prototype interface of this design. In
> fact, a PLC geniwrapper initial patch is already available at [3].
>
> pps. There was also an interesting discussion of the benefits of
> SOAP/XSDL as compared to Pyton/XML-RPC and the patch above represents an
> XSDL implementation of a control plane API.
>
> [1] http://groups.geni.net/geni/wiki/ClusterB
> [2]
> http://groups.geni.net/geni/attachment/wiki/ClusterB/Enterprise%20Geni.pdf
> [3] http://www.openflowswitch.org/wk/index.php/GENILight
>
>
>
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
« Return to Thread: do component managers need to authenticate researchers?
| Free embeddable forum powered by Nabble | Forum Help |
