Gec7ControlFrameworkAgenda: gec7-cfwg-minutes-01.txt

File gec7-cfwg-minutes-01.txt, 12.7 KB (added by Aaron Falk, 13 years ago)
1Control Framework Working Group
2Meeting Summary
3GEC7 meeting
4March 18, 2010
6Working group chairs: Rob Ricci, Jeff Chase
7Working group system engineer: Aaron Falk
8Notes take by Matt Zekauskas
12  1. Welcome & Introduction (Rob Ricci)
14  2. Talk: GENI Aggregate Manager API (Tom Mitchell, GPO)
16  3. Talk: Recap of stitching discussion on mailing list: general
17     points of agreement and points of disagreement (Aaron Falk, GPO)
19  4. Talk: Authorization, Trust Management, and Identity Management
20     (Jeff Chase, Duke)
22  5. Talk: GENI Federation Scenarios and Requirements (Sangjin Jeong,
23     ETRI)
25  6. Panel: Rob Ricci (ProtoGENI), Jeff Chase (ORCA), Max Ott (ORBIT),
26     Rob Sherwood (OpenFlow), David Irwin (ViSE), John Wroclawski
27     (TIED), Aaron Falk (GPO, Moderator)
30Common PlanetLab-ProtoGENI Aggregate Manager Interface
31Tom Mitchell, GENI Project Office
33  The GENI Project Office is leading an effort to implement a common
34  API to allow GENI Aggregates to affiliate with GENI control
35  frameworks through a common API.  The API will enable researcher
36  access to conforming GENI Aggregates through two existing control
37  frameworks: PlanetLab and ProtoGENI. Other GENI control frameworks
38  will be added in Spiral 3. The Spiral 2 implementation will support
39  three kinds of GENI Aggregate Managers: PlanetLab nodes, ProtoGENI
40  clusters and OpenFlow switches.  There will be a demonstration of a
41  slice containing PlanetLab, ProtoGENI, and OpenFlow resources at GEC
42  9.  The work is not addressing the client to control framework
43  interface, stitching, scheduling, or RSpecs.  Updates will be posted
44  to the control-wg mail list.
46  Draft APIs are posted at:
50  Slides posted at:
53Summary of Slice Stitching Discussion
54Aaron Falk, GENI Project Office
56  This talk is intended to summarize a discussion on the control-wg
57  mail list about establishing slice-specific network connectivity
58  between slivers.  The control framework is pretty clear about how to
59  establish slivers, those portions of a slice that reside within an
60  aggregate.  Sliver allocation is coordinated via the aggregate
61  manager.  However, establishing connectivity between those slivers
62  is not well specified.  The near-term emphasis is on Ethernet VLANs
63  (supplemented by IP tunnels) but VLANs are just an initial example:
64  the stitching framework should be sufficiently flexible to handle
65  other cases as well.
67  Three approaches were discussed:
69  Aaron's proposal: A set of static VLANs are pre-configured between
70  adjacent aggregates.  Each aggregate is responsible for translating
71  VLAN IDs at it's boundary, thus removing the need for end-to-end
72  coordination of VLAN IDs.  A mandatory stitching coordinator as part
73  of (or on behalf of) a clearinghouse controls the exchange of (and
74  logs) stitching VLAN parameters as they are passed between
75  aggregates.  The emphasis on this proposal is simplicity.
77  Rob's proposal: An optional slice embedding service annotates an
78  RSpec description of a slice with connectivity information, thus
79  permitting AMs to identify that they need to establish a 'stitching'
80  connectivity.  Static or dynamic connectivity can be used.  All AMs
81  in a slice see the RSpecs and deduce the needed connectivity.  The
82  AMs negotiate the parameters of the connection via TBD protocol.
84  Jeff's proposal: The slice manager manages the exchange of stitching
85  parameters between aggregates.  Aggregates sign their parameters
86  before handing them to the slice manager, ensuring they are not
87  inappropriately modified along the way.
89  Discussion addressed the importance of understanding the trust
90  model: who is trusted in the parameter exchange and how is the trust
91  created?  There's value in leveraging the pre-existing trust between
92  'adjacent' aggregates, which have connectivity relationships.  Some
93  aggregates wont' be directly connected, i.e., tunnels may be used to
94  tie them together.  The clearinghouse can play the role of broker,
95  providing endorsements.
97  There are systems that already do network stitching -- DRAGON is one
98  example and has been used as a model for Rob's ProtoGENI approach.
99  Other systems which might be relevant include Internet2, ESnet,
100  GEANT.  See which has technology that
101  dynamically connects VLANs.
103  Email threads:
107  Slides posted at:
109Authorization/Trust Mgmt/Identity Management
110Jeff Chase, Duke
112  The presentation reviewed elements of GENI security architecture
113  work done in 2007, highlighting the understanding of security
114  requirements and threat model from that time.  The GENI security
115  architecture is still insufficiently defined.  It should be common
116  across control frameworks, separate policy from mechanism, support
117  future policy needs, and use standard solutions when suitable.
119  Important questions remain: Who issues credentials?  How are are the
120  subjects named?  What are the attributes, rights, etc.?  How is
121  trust brokered?  How are authorization policies specified?  The SFA
122  architecture does not go far enough to answer these questions.  GENI
123  should enable/permit external identity providers but the SFA appears
124  to preclude IdPs: just one reason why we need to move beyond SFA.
126  A brief introduction to Shibboleth was presented using the ORCA
127  control framework as an example pointing out the benefits of using
128  Shibboleth showing how IdPs can be used at the user/browser
129  interface in a way that complements other key-based mechanisms used
130  internally.
132  Related security issues include the semantics and constraints for
133  delegating tickets; authorization for aggregates that don't fit the
134  'host' model; location of policy decision and enforcement code; and
135  the implications of naming structures and resolution mechanisms.
137  Slides posted at:
140ETRI work on federation
141Sangjin Jeong, ETRI; Andy Bavier, Princeton
143  Researchers at ETRI, in Korea, and Princeton have been collaborating
144  on defining requirements and scenarios for federation between major
145  testbed projects.  Challenges include differences in identity &
146  authority management, control procedures, and resource & experiment
147  description. 
149  The project has produced a report proposing requirements for
150  federation and is seeking feedback and adoption of the effort as a
151  working group activity.  The authors will send pointer to an
152  update of the report to the control-wg list.
154  Pointer to original report email:
157  Slides posted at:
159Panel Discussion: Rob Ricci, ProtoGENI; John Wroclawski, TIED/DETER;
160Jeff Chase, ORCA; Rob Sherwood, OpenFlow; David Irwin, VISE; Max Ott,
163  Comment highlights:
165  - Different control frameworks are assuming different operational
166    models.  Should be more explicit and get better discussion between
167    operations and control framework folks.
170  Stitching
172  - Should focus more on what trust relationships needed to make
173    stitching work.
175  - Simple, static stitching approach may be most appropriate to go
176    between control frameworks.
178  - Additional stitching challenges: 1) There won't necessarily be
179    VLANs everywhere and how non-VLAN parts get stitched may be
180    challenging.  2) Also, mapping PlanetLab nodes, which have
181    internal logic to demux packets to slivers, to OpenFlow network is
182    not an easy problem. 3) Slicing rules may vary across OpenFlow
183    aggregates, making it difficult to stitch them together.  4) Not
184    clear whether storage will have unique stitching challenges.
186  Resource Description
188  - Minimal API work may not be sufficient for actuators, which have
189    unique needs in how control is authorized and shared.  Cameras may
190    have special restrictions on, e.g., where to point, privacy, and
191    safety.
193  - RSpec approach is probably good enough for now if one considers it
194    as an 'assembly language' building block but it has to represent
195    relationships.  Will need tools to allow researchers to work with
196    higher-level constructs.
198  API
200  - RPCs are brittle.  Suggest that API interactions should be based
201    on messages and that messages are self-contained and include
202    credentials.  Some approaches are using credentials embedded in
203    transport (e.g., SSL), this is bad for for loosely-coupled
204    distributed systems.
206  Authorization Model
208  - GENI should be able to use many sources of primary identity.
210  - Shibboleth may not be rich enough in group delegation of trust.
211    Not clear it is appropriate for use as a control framework
212    internal mechanism.  Worth continuing to explore, though.
214  - Should be careful not to adopt standards that limit flexibility.
216  - Shibboleth can be used in a straightforward way ("no-brainer") to
217    leverage existing institutional identity providers for
218    authentication to portals and testbeds.  Solid model, widely
219    deployed, good enough to use for now.
221  - Two alternatives available today for handling delegation: 1) OAUTH:
222    an IETF standard that can convert SAML assertions into other
223    tokens; 2) Project Moonshot: putting federation into GSS-API and
224    below. 
226  - Important to consider "conservation of contracts."  A vexing thing
227    about GENI's use of federation is that it applies to a lot of
228    different 'nouns'.  Some parameters of federation may not be well
229    aligned to relationships.  E.g., Who will maintain the required
230    emergency stop mechanism contact info?
232  - Need to consider de-provisioning, i.e,. taking accounts away from
233    people.  We need a mechanism for this.
235  - Need to consider privacy and anonymity.  Perhaps through the use
236    of opaque identifiers.  Even those would need to be varied across
237    entities to avoid correlation attacks.
239  - Shibboleth may have something to offer to GENI control framework
240    authorization.  It wouldn't require the policy decision points
241    within the control frameworks to discontinue the use of X.509.
242    There are mechanisms such as gridshib to pack SAML assertions into
243    X.509.  There are questions about applicable the web-session auth
244    model is to GENI's experiment-based auth model.  For example, if
245    authorization decisions are based on attributes, how are
246    attributes passed within SAML and shib, given that Shib attributes
247    are associated with a session (typically browser session, SSL)?
249  - Shib has well developed set of principles about how identity
250    providers share information that requires services to be
251    relatively static, and to know about each other.
253  - The really important question is about the semantics of
254    authorization.  We haven't gotten there yet.  WG should try to
255    tease apart this area.
257  - Lots of interest in ABAC project at Sparta.  It will provide a set
258    of rules and capabilities.  ABAC provides a mechanism to delegate
259    to a group when you don't know the members.  Shibboleth guys will
260    talk with ABAC guys.  Appear to be complementary technologies:
261    Shib's job is to tell you true things about principals.  ABAC will
262    reason about giving access.  Ted hopes to have an ABAC code & demo
263    at GEC8.
265Discussion of future wg topics
267  - Architectural design principles that give GENI robustness.  We
268    should build a system that overall is stable, robust and usable
269    for research while allowing the flexibility to bring in new
270    things, and constantly update it to get away from ossification.
271    Suggest that some groups should write statements of design
272    principles & architecture.
274  - Continue stitching discussion.  Important topic that didn't
275    converge.  Discussion will continue on the list, focusing on the
276    broader stitching problem and the relationships to interdomain
277    provisioning for dynamic circuit networks (e.g.,
279  - Shibboleth.  Would like to see a group integrate Shibboleth and
280    report back by GEC8.
282  - ETRI/Princeton federation document.  WG should review and discuss.
284  - How to identify principals.  While this has been discussed, there
285    may be sufficient experience to revisit and get a more informed
286    discussion going.  For example, consider the topic flat
287    vs. hierarchical namespaces.  Hierarchy limits trust through
288    compartmentalization.