GENI Engineering Conference 13 Session The GENI Federation Software Architecture

1. GENI Engineering Conference 13 SessionThe GENI Federation Software Architecture Marshall Brinn, GPO Rob Ricci, University of Utah March 14, 2012

2. GENI Architecture Team • At GEC12, the GENI Architecture Team was constituted to: • Define the software architecture of the GENI federation • Document the architecture for the broader GENI community • Ensure that GENI software implementations and deployments are interoperable and comply with this architecture • The Architecture Team has been meeting (by teleconference) bi-weekly since GEC12. • We have focused on an initial critical set of architectural decisions, many of which are reflected in this presentation • At a meeting yesterday, we agreed in principle (pending last edits) to the first version (V1.0) of the GENI Federation Software Architecture document. GENI Architecture Team Co-chairs: Rob Ricci, University of Utah Marshall Brinn, GENI Project Office (GPO) Voting members: Nick Bastin, Stanford University Jeff Chase, Duke University Max Ott, NICTA Larry Peterson, Princeton UniversityChip Elliott, GPO

3. Architecture Context • Obviously, this is not the first time people have tried to describe an architecture for GENI • Our current approach builds on many these approaches • Including SFA, and materials from the GENI Planning Group, and the Control Framework Working Group • The architecture has evolved as the scope and focus of the program has evolved • We’ve gained more experience in deploying and integrating resources, and supporting experimenters • We’ve placed more emphasis on details of federation, trust, interoperability

4. The GENI Federation Software Architecture Document V1.0 This presentation covers the high-level concepts in the document. The document will be available on the GENI website shortly, and contains much more detail than is provided here. This is only V1.0, the first deliverable in an ongoing process of definition and refinement.

5. Scope • The term GENI has come to mean many things in different contexts: • GENI is, first, a vision for providing and managing highly scalable programmable dynamic computation topologies from a broad range of heterogeneous resources. • GENI is also the name of the NSF program and community of researchers, campuses, architects, and developers working to bring the GENI vision to fruition. • GENI is a software architecture defining interfaces by which such topologies are managed and used and such resources are federated. • GENI is the name of a specific federation (“the GENI Federation”), built under the GENI program, which represents an implementation and deployment of the GENI architecture on a specific set of hardware resources and a set of policies for administering those resources in the context of that federation. This presentation and associated document describes the GENI software architecture in general as well as the GENI Federation in specific.

6. GENI Vision: An architecture-specific rendering GENI is a deeply programmableinfrastructure suite for performing computer science experimentation at scale. • Infrastructure suite: Provides transparent access to a federation of sliceable and shareable resources in custom topologies • Deeply Programmable: Allows programmatic configuration and control of all aspect of a computation network (computation, storage, communications) • At Scale: Allows support for extremely large, distributed experimental topologies, distributed across 100-200 campuses with realistic traffic loads or real traffic from users who ‘opt in’

7. The GENI Federation Architecture A federation is a set of agreements among people or organizations, representing the policies and terms under which they will trust, collaborate, share resources or engage in other common activities. A federation architectureis a set of constructs and services that codify and enforce those agreements. • The GENI software architecture seeks to mediate the requirements of a set of different (human) principals: • Management authorities that own computation and network resources at a campus, test-bed, regional or backbone and are willing to contribute to the GENI federation for use subject to policies they set. • IT Staff who manage the operations of these resources. • Experimenters1 who wish to make use of federation resources for deploying experiments, services or applications. 1The consumers of GENI resources may also include researchers, students, application developers, service providers and opt-in users, but the main focus of the GENI federation, and this presentation, is experimenters.

8. Architecture Services: Motivation Aggregate Manager: I want to protect my resources Experimenter: I want deeply programmable resource topologies Authentication: Trusted 3rd parties vouch for all participants Authorization: All participants conform to essential standards Accountability: Any misbehavior can be identified and stopped. Autonomy: Ultimate allocation decisions reside with Aggregate. Aggregate Manager API Federation Services API

9. GENI Federation Schematic Experimenter: I want deeply programmable resource topologies AM Requests Aggregate Experimenter Tool AM Responses

10. GENI Federation Schematic Experimenter: I want deeply programmable resource topologies • Aggregate Manager: • I want to protect my resources: • Authentication Identity Provider (IdP) Certified Identity AM Requests Aggregate Experimenter Tool AM Responses

11. GENI Federation Schematic Experimenter: I want deeply programmable resource topologies • Aggregate Manager: • I want to protect my resources: • Authentication • Authorization Identity Provider (IdP) Credential Provider (SA) Certified Identity Rights to Resources AM Requests AM Requests Aggregate Experimenter Tool AuthZ Services AM Responses AM Responses

12. GENI Federation Schematic Experimenter: I want deeply programmable resource topologies • Aggregate Manager: • I want to protect my resources: • Authentication • Authorization • Accountability Identity Provider (IdP) Credential Provider (SA) GMOC Certified Identity Rights to Resources Forensics Data Requests and Responses AM Requests AM Requests Aggregate Experimenter Tool Logging Services AuthZ Services AM Responses AM Responses

13. GENI and Standardized API’s Much as we developed the AM API to support standardized Aggregate Services, this year will be devoted to support standardized Federation Services • GENI aggregates provide a range of innovative, powerful control frameworks: ORCA, PlanetLab, ProtoGENI • They are interoperable, providing the AM API • Each provides its own authentication, authorization and accountability (AAA) services • Others may come as GENI evolves and federates with new aggregates, frameworks, other federations. • These may or may not provide their own AAA services The GENI Federation seeks to provide open and interoperable AAA services across GENI to support “one-stop” help, forensics, shutdown capabilities to the GMOC

14. Architecture Details: Outline • Aggregate Services • Federation Services • Federation Deployment Configurations • Trust Relationships

15. Architecture Details: Aggregate Services Some Definitions: An aggregate represents a resource or set of resources that can be offered for inclusion in some customer specified topology. These typically fall into the broad categories of Computation, Communication and Storage resources. A sliver is a (real or virtual) resource group provided by the aggregate via the “Aggregate Manager” (AM) API. A slice is a collection of slivers gathered for a common purpose that are configured into a topology on which to deploy experiments or applications in some degree of isolation from other slices. Slices may contain slivers from a single aggregate or may span across multiple aggregates. In the latter case, an operation called stitching is required to coordinate shared constraints such as common services or network constraints (e.g. VLAN ID’s).

16. Aggregate Manager (AM) API Summary • The essential service types provided by an aggregate are: • Directory services: Listing resources available (e.g. listResources) • Reservation services: Pre-allocating resources by gaining a ticket that can be redeemed in the future for a resource. • Allocation services: Requesting a sliver or list of slivers from an aggregate manager to be placed into a slice. • Sliver services: Requesting changes to a sliver’s state (modifying its current life-cycle stage, e.g.) The architecture document does not include details at the level of APIs; rather, it is intended to guide the development of those APIs. The AM API is defined in greater detail at http://groups.geni.net/geni/wiki/GAPI_AM_API. Note that the current AM API (Version 2) requires changes to support all of these services.

17. Architecture Details: Federation Services Authentication Services: Establishing trusted, common identity and credentials among participants in GENI interactions. Authorization Services: Enforcing allowed/prohibited actions within GENI based on experimenter credentials and federation policy. Accountability Services: Providing support for forensics and analytics by logging all (successful and failed) interactions among experimenters, aggregates and other services. In the GENI Federation, we refer to this collection of services as the Clearinghouse.

18. Federation Services: Accountability • The federation provides a series of services for managing the credentials of entities trusted by GENI. • Identity Providers (IdPs) providing certificates and PKI key materials to people, registering them with the GENI federation. • A Project Authority asserts the existence of projects and the roles of members (e.g. PI, Experimenter). • Slice Authorities providing experimenters with slice credentials by which to invoke AM API calls on federation aggregates. • A Service Registry provides experimenters with a ‘yellow pages’ of URL’s of all trusted services of different kinds. In particular, the list of all available aggregate managers trusted by GENI (possibly satisfying particular search criteria) is provided. • A Portal provides web-based authentication and access to the authorized Clearinghouse services and other GENI tools, providing a per-session repository for user certificates and credentials for the user’s convenience.

19. Federation Services:Authorization [1] • Trust Policy is set of statements from which allowable actions may be inferred from the attributes of a principal. • These statements are credentials (assertions about a principal signed by a trusted authority) regarding possession or delegation of rights and privileges or delegations of rights and privileges, or e.g. a principle’s role with respect to a particular project, slice, resource or institution. • Resource Allocation Policy is a statement regarding the resource allocations or allocation behaviors associated with a given project, slice or experimenter. • For example, we may wish to limit the number of compute nodes (computers or VM’s) allocated to a given project at any given time. • It does not override an aggregate’s local resource allocation policies unless the aggregate has explicitly agreed to do so as part of federation membership

20. Federation Services:Authorization [2] • The Authorization Service determines whether a given action is permitted by policy. • It contains a series of guards, each of which may veto a given action (i.e. an act is authorized if and only if it is allowed by every guard). • Aggregates may use this service, or by mutual agreement, a different trusted authorization service that enforces federation and local policy • The Credential Store provides storage/retrieval access to credentials to Federation Services and also may be used by AM’s to support their own authorization decisions. • By keeping authorization credentials separate from authentication certificates and by imposing short expiration times on credentials, it is possible to modify credentials and have the effects of these modifications take effect in a reliable and timely manner throughout the federation. • Version 1 of the GENI Federation Clearinghouse will include a trust guard and a resource allocation guard.

21. Federation Services:Accountability • The Federation provides a Logging Service that logs transactions (successful or failed) between experimenter tools and aggregates to support real-time and post-facto forensics and analytics • Aggregates may use this logging service, or by mutual agreement, some other trusted logging service. • In the GENI Federation, all AM transactions must be logged, and all logs accessible to the GMOC • The GMOC logs provide the traceability between slivers and slices. • The Slice Authority provides the link of slices to projects. • The Project Authority provides the link of projects to leads. • Together, these provide the ability to find the responsible party to contact in case of problematic behavior on the part of an experiment

22. GENI Federation Schematic: Services and Internal Relationships GENI Clearinghouse Credential Store Transaction Store Slice Authority Identity Provider Update Credentials Identity Certificates Project Authority Store, Retrieve Transaction Data Retrieve Credentials Authorization Service Logging Service Service Registry

23. Architecture Details:Federation Deployment Configurations [1] The GENI architecture reflects a hybrid approach towards federation. • GENI reflects a belief in the autonomy of aggregates, and local decision and control regarding resource management and provision of services to clients. • While supporting federation-level authentication, authorization and accountability • GENI is also explicitly designed to allow aggregates to participate in more than one federation simultaneously. • The GENI architecture also reflects a similar hybrid philosophy towards monitoring and maintenance • Federation services are informed by aggregates on the state they choose to share, from which high-level views and decisions may be taken.

24. Architecture Details:Federation Deployment Configurations [2] The GENI Federation will consist of a range of different aggregates with different approaches towards authorization, logging and resource management. These approaches represent deployment decisions: the act of trusting an aggregate entails trusting the details and consequences of its deployment decisions. • Local Trusted Services. An AM has its own aggregate management infrastructure and provides its own authorization and logging services. • Federation Trusted Services. An AM uses the Clearinghouse Logging and Authorization services in the course of responding to any AM API request. • Local Proxy Aggregate Manager. An AM acts as a pass-through wrapper for another AM, providing its own authorization and logging services. • GENI Proxy Aggregate Manager. This configuration is much like the local proxy, with the difference that the proxy AM is provided by the GENI Federation and services multiple aggregates.

25. GENI Federated Trusted Services Configuration GMOC Identity Provider GENI Clearinghouse Service Authority Logging Service Credential Store AuthZ Service Project Authority Slice Authority Aggregate Researcher Tool

26. Architecture Details:Trust Relationships • The GENI Federation rests on trusted interactions among the different entities (people and the tools or services that represent them). There are essentially two kinds of trust statements required for these interactions: • Authentication: I trust that you are who you claim to be. • Authorization: I trust that you have the attributes (roles, privileges, capabilities) you claim to have.   • Trust within GENI is based on the exchange of PKI key materials, and a trusted statement is one signed by a trusted entity with their private key. • If I have access to the public key of a trusted entity and can decrypt a message signed by that entity with their private key, I can be assured that they signed (and thus believe or assert) that statement.

27. Architecture Details:Trust Relationships [2] • From these trust foundations, we may establish chains of trust: if I trust any statement signed by a root, I may trust any statement signed by an entity with particular attributes asserted by that root, etc. Every GENI federated AM must import the GENI root certificate and accept identity certificates signed by the GENI Identity Provider (IdP)

28. Architecture Details:Trust Relationships [3] • Beyond trust of the GENI root, there are additional kinds of trust established between entities by which one entity (A) authorizes or permits another (B) to act: • Delegation: By delegating a privilege or right to entity B, entity A trusts B to perform tasks that A is currently permitted to do. B is then free to act autonomously with this new privilege based on that trust. • Representative: For more granular control, A can assert that B ‘speaks for’ A in a particular request. A must delegate to B the general privilege that he ‘may speak for’ A. • A specific request, signed by B can be said to be made on A’s behalf. • Proxy: A tool or service may be provided with the private key of an entity and thus are indistinguishable from that entity for purposes of trust and action within the federation. • The GENI Federation trusts: • People who have established their identity through the GENI IdP. • Project leads to manage the delegation of authority within their projects. • AM’s who have established their attributes and identity through the Service Registry. • Clearinghouse services.

29. GENI Federation Trust Structure GENI Trust Root Signs Credentials For (Trusts) Installs Root Cert From (Trusts anyone trusted by Root) Researchers Certificate Signed by IdP (Known) GENI Clearinghouse Checks Permission (Trusts) Holds Private Key for (Represents) Researcher Tools Aggregates Makes Authenticated Requests

30. Upcoming Architecture Topics There are several critical topics to be considered next by the GENI Architecture team, including: • Stitching: How to orchestrate construction of cross-aggregate topologies (particularly wrt. negotiating consistent VLAN ID’s) • Experiment Management: How the GENI architecture might define open interfaces for the crafting, deployment, orchestration, instrumentation, measuring, and analysis of experiments and applications. • Opt-in Users: How GENI can reliably and securely support experiments in which customers may opt-in (provide informed consent) to the use of their personal traffic by that service. • Cross-Federation Interoperability: How to establish common trust and communications between GENI and other federations. These will be discussed at the “Upcoming Architecture Topics” session today in R1 at 1600.