Control Framework Working Group Meeting Summary GEC7 meeting March 18, 2010 Working group chairs: Rob Ricci, Jeff Chase Working group system engineer: Aaron Falk Notes take by Matt Zekauskas Agenda 1. Welcome & Introduction (Rob Ricci) 2. Talk: GENI Aggregate Manager API (Tom Mitchell, GPO) 3. Talk: Recap of stitching discussion on mailing list: general points of agreement and points of disagreement (Aaron Falk, GPO) 4. Talk: Authorization, Trust Management, and Identity Management (Jeff Chase, Duke) 5. Talk: GENI Federation Scenarios and Requirements (Sangjin Jeong, ETRI) 6. Panel: Rob Ricci (ProtoGENI), Jeff Chase (ORCA), Max Ott (ORBIT), Rob Sherwood (OpenFlow), David Irwin (ViSE), John Wroclawski (TIED), Aaron Falk (GPO, Moderator) Common PlanetLab-ProtoGENI Aggregate Manager Interface Tom Mitchell, GENI Project Office The GENI Project Office is leading an effort to implement a common API to allow GENI Aggregates to affiliate with GENI control frameworks through a common API. The API will enable researcher access to conforming GENI Aggregates through two existing control frameworks: PlanetLab and ProtoGENI. Other GENI control frameworks will be added in Spiral 3. The Spiral 2 implementation will support three kinds of GENI Aggregate Managers: PlanetLab nodes, ProtoGENI clusters and OpenFlow switches. There will be a demonstration of a slice containing PlanetLab, ProtoGENI, and OpenFlow resources at GEC 9. The work is not addressing the client to control framework interface, stitching, scheduling, or RSpecs. Updates will be posted to the control-wg mail list. Draft APIs are posted at: http://groups.geni.net/geni/wiki/GAPI_AM_API http://groups.geni.net/geni/wiki/GAPI_CH_API Slides posted at: http://groups.geni.net/geni/attachment/wiki/Gec7ControlFrameworkAgenda/AggregateManagerCFWG.pptx Summary of Slice Stitching Discussion Aaron Falk, GENI Project Office This talk is intended to summarize a discussion on the control-wg mail list about establishing slice-specific network connectivity between slivers. The control framework is pretty clear about how to establish slivers, those portions of a slice that reside within an aggregate. Sliver allocation is coordinated via the aggregate manager. However, establishing connectivity between those slivers is not well specified. The near-term emphasis is on Ethernet VLANs (supplemented by IP tunnels) but VLANs are just an initial example: the stitching framework should be sufficiently flexible to handle other cases as well. Three approaches were discussed: Aaron's proposal: A set of static VLANs are pre-configured between adjacent aggregates. Each aggregate is responsible for translating VLAN IDs at it's boundary, thus removing the need for end-to-end coordination of VLAN IDs. A mandatory stitching coordinator as part of (or on behalf of) a clearinghouse controls the exchange of (and logs) stitching VLAN parameters as they are passed between aggregates. The emphasis on this proposal is simplicity. Rob's proposal: An optional slice embedding service annotates an RSpec description of a slice with connectivity information, thus permitting AMs to identify that they need to establish a 'stitching' connectivity. Static or dynamic connectivity can be used. All AMs in a slice see the RSpecs and deduce the needed connectivity. The AMs negotiate the parameters of the connection via TBD protocol. Jeff's proposal: The slice manager manages the exchange of stitching parameters between aggregates. Aggregates sign their parameters before handing them to the slice manager, ensuring they are not inappropriately modified along the way. Discussion addressed the importance of understanding the trust model: who is trusted in the parameter exchange and how is the trust created? There's value in leveraging the pre-existing trust between 'adjacent' aggregates, which have connectivity relationships. Some aggregates wont' be directly connected, i.e., tunnels may be used to tie them together. The clearinghouse can play the role of broker, providing endorsements. There are systems that already do network stitching -- DRAGON is one example and has been used as a model for Rob's ProtoGENI approach. Other systems which might be relevant include Internet2, ESnet, GEANT. See www.controlplane.net which has technology that dynamically connects VLANs. Email threads: http://old.nabble.com/-cfwg--a-proposal-for-slice-stitching-td27404947.html http://old.nabble.com/-cfwg--slice-stitching%3A-beyond-vlan-tags-to28074918.html Slides posted at: http://groups.geni.net/geni/attachment/wiki/Gec7ControlFrameworkAgenda/falk-cfwg-gec7-stitching-summary.pptx Authorization/Trust Mgmt/Identity Management Jeff Chase, Duke The presentation reviewed elements of GENI security architecture work done in 2007, highlighting the understanding of security requirements and threat model from that time. The GENI security architecture is still insufficiently defined. It should be common across control frameworks, separate policy from mechanism, support future policy needs, and use standard solutions when suitable. Important questions remain: Who issues credentials? How are are the subjects named? What are the attributes, rights, etc.? How is trust brokered? How are authorization policies specified? The SFA architecture does not go far enough to answer these questions. GENI should enable/permit external identity providers but the SFA appears to preclude IdPs: just one reason why we need to move beyond SFA. A brief introduction to Shibboleth was presented using the ORCA control framework as an example pointing out the benefits of using Shibboleth showing how IdPs can be used at the user/browser interface in a way that complements other key-based mechanisms used internally. Related security issues include the semantics and constraints for delegating tickets; authorization for aggregates that don't fit the 'host' model; location of policy decision and enforcement code; and the implications of naming structures and resolution mechanisms. Slides posted at: http://groups.geni.net/geni/attachment/wiki/Gec7ControlFrameworkAgenda/gec7-cf-chase-security.ppt ETRI work on federation Sangjin Jeong, ETRI; Andy Bavier, Princeton Researchers at ETRI, in Korea, and Princeton have been collaborating on defining requirements and scenarios for federation between major testbed projects. Challenges include differences in identity & authority management, control procedures, and resource & experiment description. The project has produced a report proposing requirements for federation and is seeking feedback and adoption of the effort as a working group activity. The authors will send pointer to an update of the report to the control-wg list. Pointer to original report email: http://old.nabble.com/Initial-investigation-result-of-federation-issues-td26299783.html Slides posted at: http://groups.geni.net/geni/attachment/wiki/Gec7ControlFrameworkAgenda/Jeong-ETRI-GENI-federation-scenario-GEC7.ppt Panel Discussion: Rob Ricci, ProtoGENI; John Wroclawski, TIED/DETER; Jeff Chase, ORCA; Rob Sherwood, OpenFlow; David Irwin, VISE; Max Ott, ORBIT. Comment highlights: - Different control frameworks are assuming different operational models. Should be more explicit and get better discussion between operations and control framework folks. Stitching - Should focus more on what trust relationships needed to make stitching work. - Simple, static stitching approach may be most appropriate to go between control frameworks. - Additional stitching challenges: 1) There won't necessarily be VLANs everywhere and how non-VLAN parts get stitched may be challenging. 2) Also, mapping PlanetLab nodes, which have internal logic to demux packets to slivers, to OpenFlow network is not an easy problem. 3) Slicing rules may vary across OpenFlow aggregates, making it difficult to stitch them together. 4) Not clear whether storage will have unique stitching challenges. Resource Description - Minimal API work may not be sufficient for actuators, which have unique needs in how control is authorized and shared. Cameras may have special restrictions on, e.g., where to point, privacy, and safety. - RSpec approach is probably good enough for now if one considers it as an 'assembly language' building block but it has to represent relationships. Will need tools to allow researchers to work with higher-level constructs. API - RPCs are brittle. Suggest that API interactions should be based on messages and that messages are self-contained and include credentials. Some approaches are using credentials embedded in transport (e.g., SSL), this is bad for for loosely-coupled distributed systems. Authorization Model - GENI should be able to use many sources of primary identity. - Shibboleth may not be rich enough in group delegation of trust. Not clear it is appropriate for use as a control framework internal mechanism. Worth continuing to explore, though. - Should be careful not to adopt standards that limit flexibility. - Shibboleth can be used in a straightforward way ("no-brainer") to leverage existing institutional identity providers for authentication to portals and testbeds. Solid model, widely deployed, good enough to use for now. - Two alternatives available today for handling delegation: 1) OAUTH: an IETF standard that can convert SAML assertions into other tokens; 2) Project Moonshot: putting federation into GSS-API and below. - Important to consider "conservation of contracts." A vexing thing about GENI's use of federation is that it applies to a lot of different 'nouns'. Some parameters of federation may not be well aligned to relationships. E.g., Who will maintain the required emergency stop mechanism contact info? - Need to consider de-provisioning, i.e,. taking accounts away from people. We need a mechanism for this. - Need to consider privacy and anonymity. Perhaps through the use of opaque identifiers. Even those would need to be varied across entities to avoid correlation attacks. - Shibboleth may have something to offer to GENI control framework authorization. It wouldn't require the policy decision points within the control frameworks to discontinue the use of X.509. There are mechanisms such as gridshib to pack SAML assertions into X.509. There are questions about applicable the web-session auth model is to GENI's experiment-based auth model. For example, if authorization decisions are based on attributes, how are attributes passed within SAML and shib, given that Shib attributes are associated with a session (typically browser session, SSL)? - Shib has well developed set of principles about how identity providers share information that requires services to be relatively static, and to know about each other. - The really important question is about the semantics of authorization. We haven't gotten there yet. WG should try to tease apart this area. - Lots of interest in ABAC project at Sparta. It will provide a set of rules and capabilities. ABAC provides a mechanism to delegate to a group when you don't know the members. Shibboleth guys will talk with ABAC guys. Appear to be complementary technologies: Shib's job is to tell you true things about principals. ABAC will reason about giving access. Ted hopes to have an ABAC code & demo at GEC8. Discussion of future wg topics - Architectural design principles that give GENI robustness. We should build a system that overall is stable, robust and usable for research while allowing the flexibility to bring in new things, and constantly update it to get away from ossification. Suggest that some groups should write statements of design principles & architecture. - Continue stitching discussion. Important topic that didn't converge. Discussion will continue on the list, focusing on the broader stitching problem and the relationships to interdomain provisioning for dynamic circuit networks (e.g., controlplane.net) - Shibboleth. Would like to see a group integrate Shibboleth and report back by GEC8. - ETRI/Princeton federation document. WG should review and discuss. - How to identify principals. While this has been discussed, there may be sufficient experience to revisit and get a more informed discussion going. For example, consider the topic flat vs. hierarchical namespaces. Hierarchy limits trust through compartmentalization.