Devices and Applications

NetQuery devices can be realized with low implementation and performance overhead. NetQuery devices export their state to the tuplespace, and expose state transitions to application-specified triggers, thus enabling applications to determine from a device's configuration how it would behave on the network, to detect changes to the configuration, and to extend the device with new functionality.

NetQuery Router

The NetQuery router is derived from the open source Quagga router. NetQuery-Quagga interposes on Quagga's interface to Linux, and exports all relevant kernel requests to the tuplespace. In total, only 777 lines of localized changes were needed, out of a total code base of 190 KLOC.

NetQuery Switch

The NetQuery switch exports the state of its physical interfaces, and allows applications to install triggers that can veto the enablement of ports. Applications can use this functionality to extend the switch with rich access control policies.

For instance, in the example below, the policy enforcer uses NetQuery triggers to implement a access policy allowing access only to hosts with disabled wireless interfaces. When announcing the attachment of a new host, the Ethernet switch transfers control to the tuplespace server, which in turn transfers control to the policy enforcer. The policy enforcer then checks the host X's tuple to determine whether it is properly configured.

Service selection applications

Service providers can use NetQuery to differentiate themselves to customers. For instance, a well-provisioned wireless ISP can advertise its high reliability and bandwidth capacity, and an ISP that deploys DoS prevention hardware can advertise its enhanced protection against attack.

A customer would use such metrics to pick an ISP only if the claims are trustworthy. In the wireless ISP example, an ISP operates a network running TPM-equipped devices, which use TPMs to attest to the accuracy of the reported configuration. Rather than reveal this accurate, but proprietary, information directly to the customer, the ISP instead makes it available to a third-party audit service, which analyzes the topology on behalf of the client. The ISP trusts the audit service to protect its proprietary topology information, while the customer trusts the audit service to run the analysis.

Computer Science Department
Cornell University