Virtualization as Architecture - GENI Rudra Dutta Special Topic on SDN, Spring, 2017 Some slides from GENI Project Office

Network Integration Vision of integrated services network Single network infrastructure which carries traffic for various types of use But – requirements are very different Integrating networks requires making “greatest of all networks” (ATM) rather than “least of all networks” Raises barrier to entry Separate networks are good For banking and videochat and telesurgery, e.g. But frustrating that “solved” problems reappear, old solutions cannot be easily applied Copyright Spring 2017, Rudra Dutta, CSC, NCSU

Motivation for Virtualization Approach similar to compute virtualization A substrate that provides basic capabilities A method to identify smallest units (“slivers”) of Bandwidth Switching ??? Resources that make up substrate must each be sliverable Easiest when slivering is along physical lines (NICs, switches) Collection of slivers makes up a virtual network (“slice”) Similar to a virtual machine Advantage of integrated network without (some of) the drawbacks Copyright Spring 2017, Rudra Dutta, CSC, NCSU

GENI In late 2000’s, an NSF initiative to create a national-scale sharable network testbed Allow researchers to experiment with a national “at-scale” footprint Allow experimentation with different architectures, fundamentally incompatible Virtualized underlying infrastructure indispensable for such a testbed Different experiments would be completely isolated Would use completely different stacks, hops Also the thought: maybe virtualization is the next architecture Copyright Spring 2017, Rudra Dutta, CSC, NCSU

GENI – Current User View Something like a virtualization platform May be easier to think of it as VCL, but with some differences Ability to define “nodes” Provided as VM’s by GENI Option (in some cases) of requesting “bare metal” Option (in some cases) to bind to specific substrate Ability to define “links” Between nodes already defined Characterize link metrics Install/develop software on nodes, run Leave running unattended, access as needed Copyright Spring 2017, Rudra Dutta, CSC, NCSU

Using GENI (First steps) Must complete, in HW4: Configuration and setup A simple exercise Must be member of a “GENI project” (done in HW3) Request to become member of “ncsu_teaching” Receive approval from instructor Now, you can log into the GENI portal Visit portal.geni.net, click “Use GENI” This is the authentication step (you are who you say you are) GENI uses a single sign-on system with federation Shibboleth will bring up a list of authentication (login) domains Choose “NC State University” if not already pre-selected Log in with your UNITY ID/PW Copyright Spring 2017, Rudra Dutta, CSC, NCSU

Creating a Slice GENI returns, upon request, a slice certificate This is the authorization to use resources from aggregates Now, you can create “slices” A “slice” is a virtual network Each “node” is a VM, on which you have root access Can use for any processing, including forwarding packets Each “link” is a virtual circuit, L2 (VLAN) or L3 (OF) You should not have to understand distinction, or allow for any differences GENI provides: Various aggregates (see previous slides from GPO) Various tools to view and access those aggregates All tools access all aggregates, but some pairs match better We shall use ExoGENI aggregates with Flukes This combination supported some extra functionalities – we shall try to keep within GENI set Copyright Spring 2017, Rudra Dutta, CSC, NCSU

Creating and Using Slices “Clearinghouse” Login (UNITY credentials) “Aggregate Manager” Web Request GENI certificate Flukes (X509 (PEM) file) Login (GENI certificate) Issue certificate Request slice Provide personal login credentials (ssh key) Confirm Provision slice Install login credentials Login (personal credentials) (ssh key) Use ssh “Aggregate” Copyright Spring 2017, Rudra Dutta, CSC, NCSU

Designing a Slice with Flukes Very simple – add nodes and links by point-and-click Nodes are VMs Can choose types (what OS will be loaded initially) Can install software after it boots up – or even automate through startup scripts Can choose what blade VM physically comes from All are optional – accept default unless specific need ExoGENI enforces secure login Provide keys through Flukes Links are “stitched adjacencies” – treat as links Copyright Spring 2017, Rudra Dutta, CSC, NCSU

Create and Use Your Slice The previous step only designed the slice Still just a picture on a screen – no actual resources “Submit” this design to be instantiated Should succeed if you have authorization, aggregate has available resources, and all goes well Can check in Flukes if provisioning successfully finished or not When finished, can log in using ssh X11 display pushback may be possible When used is finished, release slice Will eventually expire even without release Copyright Spring 2017, Rudra Dutta, CSC, NCSU

Summary GENI has completed Spirals 1 – 5, and has started transition to use model Original thinking and positioning has been questioned and revisited GENI research council has been set up Architectural vision also evolved – common Aggregate Manager API Increasing set of “common access” tools, API Overall broad goal remains to enable isolated experiments deep into the network stack Future Internet architectural insights and/or partial realizations might emerge We will use GENI as an instructional lab facility For many groups, may be project platform Some informational slides from GENI follow Copyright Spring 2017, Rudra Dutta, CSC, NCSU

Global networks are creating extremely important new challenges Science Issues We cannot currently understand or predict the behavior of complex, large-scale networks Innovation Issues Substantial barriers to at-scale experimentation with new architectures, services, and technologies Credit: MONET Group at UIUC increasingly rely on our evolving technological and social networks, intertwined and worldwide in scale Paradigm Shifts and Global Communications are transforming societies and economies. Society Issues We increasingly rely on the Internet but are unsure that can trust its security, privacy or resilience 12

Programmable & federated, with end-to-end virtualized “slices” GENI Conceptual Design Infrastructure to support at-scale experimentation Virtualized Deeply programmable Programmable & federated, with end-to-end virtualized “slices” Mobile Wireless Network Edge Site Sensor Network Federated International Infrastructure Heterogeneous, and evolving over time via spiral development 13

Federation GENI grows by “gluing together” heterogeneous infrastructure My experiment runs across the evolving GENI federation. Wireless #1 Corporate GENI suites Backbone #1 Compute Cluster #1 My GENI Slice Other-Nation Projects Access #1 Compute Cluster #2 Backbone #2 This approach looks remarkably familiar . . . Other-Nation Projects Wireless #2 NSF parts of GENI Goals: avoid technology “lock in,” add new technologies as they mature, and potentially grow quickly by incorporating existing infrastructure into the overall “GENI ecosystem” 14

Resource discovery Aggregates publish resources, schedules, etc Resource discovery Aggregates publish resources, schedules, etc., via clearinghouses What resources can I use? GENI Clearinghouse These Researcher Components Components Components Aggregate A Computer Cluster Aggregate B Backbone Net Aggregate C Metro Wireless 15

Slice creation Clearinghouse checks credentials & enforces policy Aggregates allocate resources & create topologies Create my slice GENI Clearinghouse Components Components Components Aggregate A Computer Cluster Aggregate B Backbone Net Aggregate C Metro Wireless 16

Experimentation Researcher loads software, debugs, collects measurements Experiment – Install my software, debug, collect data, retry, etc. GENI Clearinghouse Components Components Components Aggregate A Computer Cluster Aggregate B Backbone Net Aggregate C Metro Wireless 17

Slice growth & revision Allows successful, long-running experiments to grow larger Make my slice bigger ! GENI Clearinghouse Components Components Components Aggregate A Computer Cluster Aggregate B Backbone Net Aggregate C Metro Wireless 18

Federation of Clearinghouses Growth path to international, semi-private, and commercial GENIs Make my slice even bigger ! GENI Clearinghouse Federated Clearinghouse Components Components Components Components Aggregate A Computer Cluster Aggregate B Backbone Net Aggregate C Metro Wireless Aggregate D Non-NSF Resources 19

Operations & Management Always present in background for usual reasons Will need an ‘emergency shutdown’ mechanism Stop the experiment immediately ! Oops GENI Clearinghouse Federated Clearinghouse Components Components Components Components Aggregate A Computer Cluster Aggregate B Backbone Net Aggregate C Metro Wireless Aggregate D Non-NSF Resources 20

Viewing GENI at Different Planes Link-1 Topology Plane: Nodes, links VM-1 VM-2 TOR Switch TOR Switch Resource Plane: Racks, switches, PCs Rack Node Rack Node Rack Node Rack Node Rack Node Rack Node Rack Node Rack Node Rack Node Rack Node MA SA AM-1 AM-2 Control Plane: Aggregates [AM API], Authorities [Federation API], Tools, Slices, Slivers, Projects Tool This talk will focus on the entities comprising the GENI control plane and their relationships.

Architecture Schematic: Tools interacting with Aggregates 2) SSL connection validated, user authorized, slice credential constructed User certificate and slice credential are used to authenticate and authorize the experimenter at the AM Clearinghouse SA (Slice Authority) 1) Federation API (SA): get_credentials XMLRPC/SSL : Experimenter’s cert sent, request encrypted by experimenter’s SSL private key 3) Slice credential returned 4) AM API: listresources XMLRPC/SSL PLUS slice credential 5) SSL connection validated, user authorized, manifest constructed Experimenter Tool (omni) Aggregate Manager 6) Manifest Rspec returned omni.py –a test-agg listresources myslice

Huh? Slow down! What is a Slice Authority? Why do I need to go from the Tool to the Slice Authority when I really want to go straight to the Aggregate? What are all these Credentials and Certificates for? I just want some resources!

GENI: Trying to give Experimenters the Resources they Need Resource Owner Who is this guy? What should I allow him to have? What happens if something goes wrong?

Expanding Resource Owner’s Concerns “Who is this guy?”: Authentication We need to know that the person asking for resources is who they claim to be. “What should I allow him to have?”: Authorization We need to be able to determine which users are entitled to which resources in which context. “What happens if something goes wrong?”: Accountability We need to be able to tell when an experiment is behaving in a way that risks my resources, and if so, shut it down and keep it from happening it again. Providing experimenters with authenticated, authorized, accountable access to resources is the foundation of the GENI architecture.

Wanted: A Trusted Third Party In general, the experimenter and the resource owner don’t know each other and don’t trust each other. Moreover, requiring that they do won’t scale to large numbers of users and resources. For the resource owner to be willing to allocate resources to the experimenter, a mutually trusted third party is needed who can: Vouch for the experimenter’s identity Provide information about the experimenter from which to make authorization decisions Monitor experiments, provide alert, shutdown and forensics services, revoke privileges when needed These trusted third parties are the Slice and Member Authorities

Participants in a GENI Federation Federation: A collection of people and institutions who agree to share resources and abide by common procedures in order to share resources in a reliable, mutually beneficial manner. Clearinghouse: Set of services establishing federation-level authentication, authorization and accountability of experimenter use of federation resources. Esp. contains one or more Slice Authorities and Member Authorities Monitoring: Processes and tools monitoring activity on GENI resources for health, performance, adherence to policies. Tools: Software capabilities that interact with federation resources on behalf of experimenters Aggregates: Software entities that represent federated resources in transactions with experimenter tools. Note the human trust pillars: AM provider agreements, recommended use policy, CH provider agreement Experimenter: A researcher seeking to perform network experiments on customized data plane. Resources: Physical resources (compute, network, storage) made available to the federation by means of a participating aggregate. Real-world entities Software entities

Looking at Credentials A credential is a signed statement. In GENI, we have many different kinds of credentials that are used in different ways A Certificate is an identity credential: “The person bearing the private key associated with this public key has these attributes: UUID, URN, email…” In GENI, these are in X509 format, signed by a Federation Member Authority. Certificates are the basis of Authentication in GENI. All API calls (to aggregates through the AM API or to the Clearinghouse through the Federation API) are made via SSL using the caller’s certificate and private key

Looking at Credentials [2] Slice and User Credentials Slice credentials are statements from the SA regarding rights and roles of a user with respect to a given slice User credentials are statements from the MA regarding rights and roles of a user independent of a slice The aggregate uses these to inform its own Authorization decisions Attributes Statements about a user: “User is …” a Project Lead or Operator or Faculty at X institute… These may be things that are true outside of GENI or within GENI

The Authorization Pipeline Authentication Authentication: An API (AM or Federation) call is made using user’s certificate and private key. If the public key in cert matches private key, user is authenticated. Identity Identity: The caller’s certificate contains some key identity attributes: URN, UUID, email. Attributes Attributes: The call may contain other credentials (e.g. slice credential or PI attribute). Policy Policy: The server (SA, MA, AM) has rules determining what attributes are required to allow actions in a given context (e.g. slice). Rights Rights: Attributes crossed with policies leads to a specific set of rights in a given context. Authorization Authorization: The call is (or is not) authorized if user has sufficient rights based on policy. GENI does not apply independent reasoning to authorization: all the logic is in attributes and policies.

Trust Relationships in GENI The elements of GENI (users, tools, federation services, aggregates) have different degrees of trust that allow them to interoperate We mean different things by ‘trust’, and represent them differently in the GENI architecture CREDIBILITY: If you claim it, I believe it Accepting your statements as true Incorporation of your root cert into my ‘trusted root bundle’ ENDORSEMENT: I vouch for you to others Directory services, membership, credential granting RELIANCE: I believe you can do something as I would want it done Delegation or Speaks-for credentials Implied in using a tool, connecting to a service

Who trusts whom? What relationships are privileged? Trusted entity USER TOOL CH AM Reliance Endorsement Credibility Trusting entity We will review these different trust relationships, which may be represented and supported in different ways in the architecture.

Trust Credentials at work: Getting a slice manifest (Desktop tool) 2) SSL connection validated, user authorized, slice credential constructed User certificate and slice credential are used to authenticate and authorize the experimenter at the AM Clearinghouse SA (Slice Authority) 1) Federation API (SA): get_credentials XMLRPC/SSL : Experimenter’s cert sent, request encrypted by experimenter’s SSL private key 3) Slice credential returned 4) AM API: listresources XMLRPC/SSL PLUS slice credential 5) SSL connection validated, user authorized, manifest constructed Experimenter Tool (omni) Aggregate Manager 6) Manifest Rspec returned omni.py –a test-agg listresources myslice

Trust Credentials at work: Getting a slice manifest (Hosted tool) 2) SSL connection validated, speaks-for validated, user authorized, slice credential constructed Tool Speaks For the experimenter, supplying an extra 'speaks for' credential Clearinghouse SA (Slice Authority) 1) Federation API (SA): get_credentials XMLRPC/SSL; tool speaks for experimenter, supplying an extra speaks-for credential 3) Slice credential returned 4) AM API: listresources XMLRPC/SSL tool speaks for experimenter, supplying an extra speaks-for credential 5) SSL connection validated, speaks-for validated, user authorized, manifest constructed Hosted Experimenter Tool (GENI Portal) Aggregate Manager 6) Manifest Rspec returned

Trust Relationships: Tool trusts Tool This is a RELIANCE trust relationship InCommon IdP GPO IdP Café IdP The GENI Portal serves as A Shibboleth Service Provider (i.e. client to the Shib IdP) An IdP for OpenID clients (e.g. GEE, LabWiki, WiMAX) The tools who use the Portal’s OpenID IdP trust the Portal to authenticate users properly and return their attributes. Shib IdP (Server) GENI Portal Shib Service Provider (Client) OpenID IdP (Server) OpenID Relying Party (Client)

GENI Accountability Foundations Monitoring Gather data from Aggregates and Clearinghouse on current system state Relational: Current relationships among users, slices, slivers, aggregates Time Series: real-time network, compute, disk resource metrics Alerting Determining potentially problematic behaviors or metric patterns on or across aggregate resources. Forensics Determine what happened and who is responsible for these resources (experimenter, slice owner, project lead) Response Depending on the severity and time-criticality, there are a number of options including: Sliver isolation Account disabling Certificate non-renewal Certificate revocation GENI has a variety of processes, policies and procedures that ensure that experimenters can, if necessary, be accountable for actions taken on federation resources