GENI Engineering Conference 13 Session The GENI Federation

GENI Engineering Conference 13 Session The GENI Federation Software Architecture Marshall Brinn, GPO Rob Ricci, University of Utah March 14, 2012 Sponsored by the National Science Foundation

GENI Architecture Team • At GEC 12, 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) biweekly since GEC 12. – 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 (V 1. 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 University Chip Elliott, GPO Sponsored by the National Science Foundation March 14, 2012 2

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 Sponsored by the National Science Foundation March 14, 2012 3

The GENI Federation Software Architecture Document V 1. 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 V 1. 0, the first deliverable in an ongoing process of definition and refinement. Sponsored by the National Science Foundation March 14, 2012 4

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. Sponsored by the National Science Foundation March 14, 2012 5

GENI Vision: An architecture-specific rendering GENI is a deeply programmable infrastructure 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’ Sponsored by the National Science Foundation March 14, 2012 6

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 architecture is 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. • Experimenters 1 who wish to make use of federation resources for deploying experiments, services or applications. 1 The 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. Sponsored by the National Science Foundation March 14, 2012 7

Architecture Services: Motivation Experimenter: Aggregate Manager: I want deeply programmable resource topologies I want to protect my resources Authentication: Trusted 3 rd 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 Manager API Sponsored by the National Science Foundation Federation Services API March 14, 2012 8

GENI Federation Schematic Experimenter: I want deeply programmable resource topologies AM Requests Experimenter Tool Aggregate AM Responses Sponsored by the National Science Foundation March 14, 2012 9

GENI Federation Schematic Experimenter: Aggregate Manager: I want deeply programmable resource topologies I want to protect my resources: • Authentication Identity Provider (Id. P) Certified Identity AM Requests Experimenter Tool Aggregate AM Responses Sponsored by the National Science Foundation March 14, 2012 10

GENI Federation Schematic Experimenter: I want deeply programmable resource topologies Identity Provider (Id. P) Certified Identity Credential Provider (SA) Aggregate Manager: I want to protect my resources: • Authentication • Authorization Rights to Resources AM Requests Experimenter Tool AM Requests Aggregate Auth. Z Services AM Responses Sponsored by the National Science Foundation AM Responses March 14, 2012 11

GENI Federation Schematic Experimenter: Aggregate Manager: I want deeply programmable resource topologies Identity Provider (Id. P) Certified Identity Credential Provider (SA) Rights to Resources AM Requests Experimenter Tool I want to protect my resources: • Authentication • Authorization • Accountability GMOC Forensics Data Requests and Responses AM Requests Logging Services Aggregate Auth. Z Services AM Responses Sponsored by the National Science Foundation AM Responses March 14, 2012 12

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, Planet. Lab, Proto. GENI – 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 Sponsored by the National Science Foundation March 14, 2012 13

Architecture Details: Outline • • Aggregate Services Federation Deployment Configurations Trust Relationships Sponsored by the National Science Foundation March 14, 2012 14

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). Sponsored by the National Science Foundation March 14, 2012 15

Aggregate Manager (AM) API Summary The essential service types provided by an aggregate are: • Directory services: Listing resources available (e. g. list. Resources) • 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. Sponsored by the National Science Foundation March 14, 2012 16

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 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. Sponsored by the National Science Foundation March 14, 2012 17

Federation Services: Accountability The federation provides a series of services for managing the credentials of entities trusted by GENI. • Identity Providers (Id. Ps) 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. Sponsored by the National Science Foundation March 14, 2012 18

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 Sponsored by the National Science Foundation March 14, 2012 19

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. Sponsored by the National Science Foundation March 14, 2012 20

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 Sponsored by the National Science Foundation March 14, 2012 21

GENI Federation Schematic: Services and Internal Relationships GENI Clearinghouse Slice Authority Identity Provider Identity Certificates Credential Store Update Credentials Project Authority Service Registry Sponsored by the National Science Foundation Transaction Store March 14, 2012 Retrieve Credentials Authorization Service Store, Retrieve Transaction Data Logging Service 22

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. Sponsored by the National Science Foundation March 14, 2012 23

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. Sponsored by the National Science Foundation March 14, 2012 24

GENI Federated Trusted Services Configuration GMOC Identity Provider GENI Clearinghouse Service Authority Credential Store Auth. Z Service Logging Service Project Authority Slice Authority Researcher Tool Sponsored by the National Science Foundation Aggregate March 14, 2012 25

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. Sponsored by the National Science Foundation March 14, 2012 26

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 (Id. P) Sponsored by the National Science Foundation March 14, 2012 27

Architecture Details: Trust Relationships [3] • Beyond trust of the GENI root, there 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 Id. P. 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. Sponsored by the National Science Foundation March 14, 2012 28

GENI Federation Trust Structure GENI Trust Root Signs Credentials For (Trusts) Researchers Certificate Signed by Id. P (Known) GENI Clearinghouse Holds Private Key for (Represents) Researcher Tools Makes Authenticated Requests Sponsored by the National Science Foundation March 14, 2012 Installs Root Cert From (Trusts anyone trusted by Root) Checks Permission (Trusts) Aggregates 29

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 R 1 at 1600. Sponsored by the National Science Foundation March 14, 2012 30