Gec7ControlFrameworkAgenda: gec7-cfwg-minutes-01.txt

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.