The NASD Interface

In recent experiments, documented in A Cost Effective, High Bandwidth Storage Architecture we have constructed a simple, capability-based, object-store interface containing less than 20 requests including: read and write object data; read and write object attributes; create and remove object; create, resize, and remove partition; construct a copy-on-write object version; and set security key. Figure 1 diagrams the components of a NASD request and illustrates the layering of networking and security.

Figure 1: Packet diagram of the major components of a NASD request in our current prototype. The details of NASD objects, requests, and security are documented in separate papers  X and Y listed in our Publications section.

Based loosely on the inode interface of a UNIX filesystem, our interface provides soft partitions, control objects, and per-object attributes for preallocation, clustering, and capability revocation. Resizeable partitions allow capacity quotas to be managed by a drive administrator. Objects with well-known names and structures allow configuration and bootstrap of drives and partitions. This also allows filesystems to find a fixed starting point for an object hierarchy and a complete list of allocated object names. Object attributes provide timestamps, size, and allow capacity to be reserved and objects to be linked for clustering. A logical version number on the object may be changed by a filesystem to immediately revoke a capability (either temporarily or permanently). Finally, an uninterpreted block of attribute space is available to the file manager to record its own long-term, per-object state such as filesystem access control lists or mode bits.

NASD security is based on cryptographic capabilities which are protected by a small number of keys organized into a four-level hierarchy. The primary use of the keys is to manage the key hierarchy and construct capabilities for use by clients. Clients obtain capabilities from a file manager using a secure and private protocol external to NASD. A capability contains a public and a private portion. The public portion is a description of what rights are being granted for which object. The private portion is a cryptographic key generated via a keyed message digest from the public portion and drive’s secret keys. A drive verifies a client’s right to perform an operation by confirming that the client holds the private portion of an appropriate capability. The client sends the public portion along with each request and generates a second digest of the request parameters keyed by the private field. Because the drive knows its keys, receives the public fields of a capability with each request, and knows the current version number of the object, it can compute the client’s private field (which the client cannot compute on its own because only the file manager has the appropriate drive secret keys). If any field has been changed, including the object version number, the access fails and the client is sent back to the file manager.