| 53 | | After: |
| 54 | | == Session Summary == |
| 55 | | }}} |
| | 53 | A group of experimenters worked through some of the exercises from tutorials, several operators came for one-on-one discussions, monitoring developers had discussions, and various GENI community members came for free-form discussions and to ask questions. |
| | 54 | |
| | 55 | === Coding Sprint - Developer Summary === |
| | 56 | Meanwhile at the developer coding sprint portion of the session, we discussed stitching, AM API changes, and various concerns with the portal specifically and persistent tools that experimenters use for GENI control actions in general. |
| | 57 | |
| | 58 | First, we reviewed the overall plan to complete layer 2 network stitching across aggregates by GEC16. Then we talked in slightly more detail about the topology service, computation service, workflow computation, and negotiation. |
| | 59 | |
| | 60 | We discussed the Topology Service being built by Ahmed El-Hassany of Indiana University in UNIS. Ahmed explained that the UNIS topology service reads in GENI aggregate advertisement RSpecs and DCN network topologies, and then |
| | 61 | makes those available in UNIS topology format. The UNIS representation and format is NML compatible and derived from perfSonar. This service is a helper service that tools are not required to use. Various community members expressed concern that the topology information is not in RSpec format, requiring tools to read another format. Rob Ricci also expressed a desire for helper functions as part of the topology service, like determining nodes that are all accessible by layer 2. We agreed to discuss modifications to the topology service in follow-on conversations to enhance its utility. |
| | 62 | |
| | 63 | The computation service would find paths between nodes, providing another optional helper service.. We agreed that MAX and the GPO would develop the compute service API. The service would take RSpecs and constraints, and produce expanded RSpecs and workflow rules and instructions for how to pass tags from one aggregate to another. This could be in the form of XPath instructions, RSpec extensions, or something else. |
| | 64 | |
| | 65 | We then discussed negotiation, which will be necessary to find a successful path between aggregates eventually. Rob Ricci argued strongly that tree mode (client driven as we are doing) is the wrong way to do negotiation, because it puts too much complexity in the tool. Nick Bastin argued negotiation could be bad in chain mode as well. Xi Yang of MAX mentioned that Allocate() in the OSCARS network is expensive - all the networks must coordinate. Tom Lehman asked if you can call `Update()` (AM API v4 addition) on allocated slivers (you can). Tom mentioned that for a single OSCARS domain, `Update()` would not be too slow. We agreed that in the near term, we will not implement negotiation, though we should not forget about it. |
| | 66 | |
| | 67 | This led to a discussion of AM API changes. |
| | 68 | First, we discussed the proposed `Update()` method. This conversation picked up from the discussion at the [wiki:GEC15Agenda/AMTopics AM Topics session]. |
| | 69 | Nick Bastin asked again for an option to allow an aggregate to have only 1 sliver state machine. We agreed to provide this, with details to be discussed via email. |
| | 70 | |
| | 71 | Rob Ricci asked whether `PerformOperationalAction()` could just say results are undefined while the sliver is updating. The group consensus was that disallowing this was better. |
| | 72 | |
| | 73 | How should slivers being deleted be marked? Jon Duerig proposed adding a new `geni_deleting` state for such slivers. The group consensus was to not add another state, and instead return another value: `geni_next_allocation_status`, indicating whether the sliver is being deleted. |
| | 74 | |
| | 75 | The group then agreed to adopt the [wiki:GAPI_AM_API_DRAFT#ChangeSetC:Update `Update()` proposal] with these changes for inclusion in AM API version 4. We also agreed that aggregates are free to implement `Update()` as part of their API version 3 implementations. |
| | 76 | |
| | 77 | We then discussed the [wiki:GAPI_AM_API_DRAFT#ChangeSetN:AddinformationtoGetVersion smaller changes to the AM API previously posted to the wiki]. The group agreed to adopt these as part of AM API version 4 and allow aggregates to implement these as part of their AM API v3 implementations. |
| | 78 | |
| | 79 | The group then began discussing several concerns that members of the community have with the GENI Portal and its handling of keys and certificates. |
| | 80 | |
| | 81 | '''Issue 1''': Services should 'Speak For' a user, not 'Speak As' as user |
| | 82 | |
| | 83 | Rob Ricci wanted the Portal to use a 'Speaks For' assertion, where the portal has a signed statement showing that the experimenter has authorized the portal to speak on their behalf. But Rob did not want the portal to 'Speak As' an experimenter, pretending to be the experimenter. Leigh Stoller proposed using a delegated slice credential. Tom Mitchell pointed out that aggregates would think the portal was reserving all resources. Rob wants ProtoGENI to try something. He wants to distinguish between 'speaks for' assertions and a delegated credential. And he wants some way to do this before there is a slice, so experimenters can use this tool to create slices. Perhaps a delegated user credential. |
| | 84 | |
| | 85 | Rob suggested that ProtoGENI aggregates would learn to accept a delegated user credential meaning 'Speaks For'. Once that happens, he said that he'd accept the portal using a checkbox authorizing generation of the 'speaks for' credential. |
| | 86 | |
| | 87 | Nick Bastin noted that jury-rigging 'speaks for' into SFA style credentials is the kind of ugliness that Jeff Chase warned us about as a sign that we need to use ABAC. However ABAC is more work for aggregates and so less likely to be available soon. |
| | 88 | |
| | 89 | Someone suggested that the portal use an intermediate CA certificate (identifying itself as the portal) and use that to sign experimenter certificates that the portal uses when it 'Speaks As' |
| | 90 | experimenters. That would allow aggregates to exclude all portal 'Speaks As' actions if they chose, but also (using the Issuer DN) identify experimenter certificates that are issued by the portal. |
| | 91 | |
| | 92 | Rob Ricci noted that that the clearinghouse must issue Certificate Revocation Lists. |
| | 93 | |
| | 94 | '''Issue 2''': Keep keys local to the user's machine |
| | 95 | |
| | 96 | Nick Bastin and Rob Ricci expressed the desire for experimenters to be able to use the GENI Portal without having to turn over their private key. |
| | 97 | |
| | 98 | Nick Bastin expressed the desire to allow experimenters to keep their private key always local to their machine. The problem Nick has is that the portal lives on a server, and the server could be compromised. Nick proposed some kind of browser plugin. The experimenter could then make a decision whether they wanted to be prompted to sign each time, or have the browser plugin sign automatically for them. This plugin could sign everything - credentials, S/MIME messages, even SSL connections. Rob noted that SSL connections might be hard in such a plugin. Nick suggested this plugin would allow a 'Channels for Me' credential where the portal is merely passing messages already signed by the experimenter, to go along with Rob's desired 'Speaks for Me'. |
| | 99 | |
| | 100 | Aaron Helsinger noted that with issues 1 and 2, these are various solutions that trade off various desirable attributes: |
| | 101 | - Accountability (can servers identify who they are talking to) |
| | 102 | - Ease of use (do not require experimenters to handle keys and certificates and signing) |
| | 103 | - Security: Protect private keys, allowing experimenters to retain control, preserving the PKI security model |
| | 104 | - Time: Users are coming and we must support them. Changes will take time, including at aggregates. But if we wait, it will get harder. |
| | 105 | |
| | 106 | '''Issue 3''': Rob wants ProtoGENI users to be able to use the portal |
| | 107 | |
| | 108 | Rob Ricci asked that ProtoGENI users be able to use the portal using their existing account, key and certificate. Theoretically, this should work for all ProtoGENI authorities, as well as !PlanetLAb users. Aaron Helsinger expressed concerns about how this would work. |
| | 109 | |
| | 110 | Rob expressed the priority that ProtoGENI users be able to create slices and add resources using the Portal. Less important is the ability to use existing ProtoGENI slices within the Portal. In both cases, using existing ProtoGENI SSH keys is desirable. |
| | 111 | |
| | 112 | The following steps were proposed: |
| | 113 | - Add a Portal Intermediate CA certificate for issuing 'Speaks As' experimenter certificates |
| | 114 | - Support CRLs in the Clearinghouse |
| | 115 | - Then begin designing a 'Speaks For' credential (possibly a delegated user credential) |
| | 116 | - When aggregates are capable of accepting this credential, the portal will stop using certificates claiming to be the experimenter, and instead will use the new 'Speaks For' credentials. |
| | 117 | |
| | 118 | Meanwhile, to keep keys protected, we proposed that the community would investigate a browser plugin for signing statements, that would allow experimenters to keep their keys local and secure. |
| | 119 | |
| | 120 | Separately, we will investigate how to support ProtoGENI users or users of other control frameworks using the Portal as a tool, with their existing certificates and keys. |
