Development ideas

Suggested changes to existing protocol

Re-order parameters in IBP_STATUS command

The existing IBP v1.4 implementation is:

version IBP_STATUS RID IBP_ST_INQ password TIMEOUT \n

version IBP_STATUS RID IBP_ST_CHANGE password TIMEOUT \n max_hard max_soft max_duration \n

version IBP_STATUS IBP_ST_RES TIMEOUT \n

Notice that two of the commands have a primary command, IBP_STATUS, a resource ID (RID), followed by a sub-command (IBP_ST_INQ, IBP_ST_CHANGE) and the last version has no RID, just a sub-command, IBP_ST_RES. The current implementation can only be parsed by first reading the whole line in and then counting the number of arguments. The argument count is then used to determine which command is actually being issued. A more natural version of the commands would always have the sub-command immediately follow the IBP_STATUS command.

Change in RID format

The current definition of an RID is an integer as defined in struct ibp_depot. The definition of an integer is architecture dependent and hense not portable. An alternative definition would be to define the RID as a character string. This would provide flexibility in its implmentation and use. The current IBP client libraries already treat the RID as an opaque character string for all commands except IBP_Allocate().

Provide interface to IBP data structures

No explicit interfaces are provided for any of the various IBP data structures. A more flexible approach would be to add API calls to manipulate these structures indirectly.

Security

Auth/AuthZ for IBP_ALLOC command

This command has the potential for abuse and could result in a a "Denial of Space" attack on the depot. If the concept of an "account" is added one could then come up with additional methods to share resources for example adding the concept of an account quota. It also provides a tracking mechanism on who is *creating* allocations.

Virtual Capabilities(vcap)

The current implementation only allows a single set of caps for an allocation. So once a user has access to a cap it can never be revoked. Virtual caps is designed to solve this problem. The idea is a user presenting the IBP_MANAGE cap could request the depot issue a new set of caps with a shorter duration. These new vcaps could then be provided to a 3rd party. At any time the original cap owner can revoke access to the allocation by simply using the IBP_MANAGE command to delete the vcap. Another useful feature to consider is restricting the vcap to a specific byte range of the original cap.

IBP "Accounts"

In order for several of these ideas to work a new set of commands would need to be added to manage the accounts.