Abstract: Techniques are disclosed for identifying faulty links in a virtualized computing environment. Network path latency information is received for one or more network paths in the networked computing environment. Based on the network path latency information, a probable presence of a faulty component is determined. In response to the determination, physical links for a network path associated with the probable faulty component are identified. Information indicative of likely sources of the probable faulty component is received from multiple hosts of the networked computing environment. Based on the identified physical links and information, a faulty component is determined.

Abstract: Techniques are disclosed for identifying faulty links in a virtualized computing environment. Network path latency information is received for one or more network paths in the networked computing environment. Based on the network path latency information, a probable presence of a faulty component is determined. In response to the determination, physical links for a network path associated with the probable faulty component are identified. Information indicative of likely sources of the probable faulty component is received from multiple hosts of the networked computing environment. Based on the identified physical links and information, a faulty component is determined.

Abstract: Techniques are disclosed for identifying faulty links in a virtualized computing environment. Network path latency information is received for one or more network paths in the networked computing environment. Based on the network path latency information, a probable presence of a faulty component is determined. In response to the determination, physical links for a network path associated with the probable faulty component are identified. Information indicative of likely sources of the probable faulty component is received from multiple hosts of the networked computing environment. Based on the identified physical links and information, a faulty component is determined.

Abstract: Techniques are disclosed for identifying faulty links in a virtualized computing environment. Network path latency information is received for one or more network paths in the networked computing environment. Based on the network path latency information, a probable presence of a faulty component is determined. In response to the determination, physical links for a network path associated with the probable faulty component are identified. Information indicative of likely sources of the probable faulty component is received from multiple hosts of the networked computing environment. Based on the identified physical links and information, a faulty component is determined.

Abstract: Techniques are disclosed for identifying faulty links in a virtualized computing environment. Network path latency information is received for one or more network paths in the networked computing environment. Based on the network path latency information, a probable presence of a faulty component is determined. In response to the determination, physical links for a network path associated with the probable faulty component are identified. Information indicative of likely sources of the probable faulty component is received from multiple hosts of the networked computing environment. Based on the identified physical links and information, a faulty component is determined.

Abstract: A verified software system may be executable on secure hardware. Prior to being executed, the software system may be verified as conforming to a software specification. First credentials attesting to an identity of the software system may be sent to an external application. Second credentials signed by a provider of the secure hardware may be sent to the external application. The second credentials may attest to an identity of the secure hardware. The external application may securely exchange one or more messages with a software application of the software system. For example, the one or more messages may be decryptable only by the external application and the software application to provide confidentiality for each message. As another example, an attestation may vouch for an identity of a sender of each of the one or more messages to attest to an integrity of each message.

Abstract: Software code of a software system (e.g., a software stack) may be verified as conforming to a specification. A high-level language implementation of the software system may be compiled using a compiler to create an assembly language implementation. A high-level specification corresponding to the software system may be translated to a low-level specification. A verifier may verify that the assembly language implementation functionally conforms to properties described in the low-level specification. In this way, the software system (e.g., a complete software system that includes an operating system, device driver(s), a software library, and one or more applications) may be verified at a low level (e.g., assembly language level).

Abstract: A verified software system may be executable on secure hardware. Prior to being executed, the software system may be verified as conforming to a software specification. First credentials attesting to an identity of the software system may be sent to an external application. Second credentials signed by a provider of the secure hardware may be sent to the external application. The second credentials may attest to an identity of the secure hardware. The external application may securely exchange one or more messages with a software application of the software system. For example, the one or more messages may be decryptable only by the external application and the software application to provide confidentiality for each message. As another example, an attestation may vouch for an identity of a sender of each of the one or more messages to attest to an integrity of each message.

Abstract: A verified software system may be executable on secure hardware. Prior to being executed, the software system may be verified as conforming to a software specification. First credentials attesting to an identity of the software system may be sent to an external application. Second credentials signed by a provider of the secure hardware may be sent to the external application. The second credentials may attest to an identity of the secure hardware. The external application may securely exchange one or more messages with a software application of the software system. For example, the one or more messages may be decryptable only by the external application and the software application to provide confidentiality for each message. As another example, an attestation may vouch for an identity of a sender of each of the one or more messages to attest to an integrity of each message.

Abstract: Software code of a software system (e.g., a software stack) may be verified as conforming to a specification. A high-level language implementation of the software system may be compiled using a compiler to create an assembly language implementation. A high-level specification corresponding to the software system may be translated to a low-level specification. A verifier may verify that the assembly language implementation functionally conforms to properties described in the low-level specification. In this way, the software system (e.g., a complete software system that includes an operating system, device driver(s), a software library, and one or more applications) may be verified at a low level (e.g., assembly language level).

Abstract: A verified software system may be executable on secure hardware. Prior to being executed, the software system may be verified as conforming to a software specification. First credentials attesting to an identity of the software system may be sent to an external application. Second credentials signed by a provider of the secure hardware may be sent to the external application. The second credentials may attest to an identity of the secure hardware. The external application may securely exchange one or more messages with a software application of the software system. For example, the one or more messages may be decryptable only by the external application and the software application to provide confidentiality for each message. As another example, an attestation may vouch for an identity of a sender of each of the one or more messages to attest to an integrity of each message.

Abstract: Disclosed is an authentication mechanism that enables an information recipient to ascertain that the information comes from the sender it purports to be from. This mechanism integrates a private/public key pair with selection by the sender of a portion of its address. The sender derives its address from its public key, for example, by using a hash of the key. The recipient verifies the association between the address and the sender's private key. The recipient may retrieve the key from an insecure resource and know that it has the correct key because only that key can produce the sender's address in the message. The hash may be made larger than the sender-selectable portion of the address. The recipient may cache public key/address pairs and use the cache to detect brute force attacks and to survive denial of service attacks. The mechanism may be used to optimize security negotiation algorithms.

Abstract: Wireless adapters are installed on one or more general purpose computing devices and are connected via a network in an enterprise environment. The adapters are densely deployed at known locations throughout the environment and are configured as air monitors. The air monitors monitor signals transmitted by one or more transceiver devices and records information about these signals. One or more analysis or inference engines may be deployed to obtain the recorded signal information and the air monitor locations to determine a location of the one or more wireless transceivers devices deployed in the environment.

Abstract: A method to determine if a rogue device is connected to a specific wired network from dynamic host control protocol (DHCP) requests on the wired network. These DHCP requests are analyzed to determine the type of device issuing the request. Once the type of device has been determined, it can be checked against a list of authorized device types. If the device issuing the DHCP request is not an authorized device type, then it can be determined that the suspect device is a rogue that is connected to the specific wired network. Additionally, even if the system of the present invention determines that it is an authorized device type, if the device is not one of the few authorized devices of this type, e.g. because its MAC address is not recognized as that of one of the authorized devices, the system can flag the suspect as a rogue.

Abstract: A method of detecting rogue devices that are coupled to a wired network without generating false negative or false positive alerts is provided. When a wireless monitor detects an observed SSID and/or BSSID, various tests are run to determine whether the observed device is actually coupled to the wired network. To guard against the suspect device spoofing an authorized SSID and/or BSSID, location information is gathered so that the network administrator can pinpoint the location of the rogue device. If the device is not recognized, various other tests are run to determine whether the unrecognized device is actually connected to the wired network. These tests include an association test, a MAC address test, an ARP test, a packet replay test, a correlation test, and/or a DHCP fingerprint test. Once it is determined that the suspect device is a rogue connected to the wired network, an appropriate alert is generated.

Abstract: Systems and methods for routing packets by nodes in an ad hoc network in accordance with a link quality source routing protocol are disclosed. Route discovery, route maintenance, and metric maintenance are designed to propagate and keep current link quality measurements. Metric maintenance includes a reactive approach for links that a node is currently using to route packets, and a proactive mechanism for all links. Nodes are configured to include a send buffer, a maintenance buffer, a request table, link quality metric modules, and preferably a neighbor cache and a link cache. The invention allows for asymmetric links in the network. The invention may be implemented within a virtual protocol interlayer between the link and network layers. The invention may employ any particular link quality metrics, including metrics based on probing techniques as well as metrics based on knowledge gained in other ways.

Abstract: Techniques for enhancing the throughput capacity available to client devices connected to a wireless local area network (WLAN) are described. Specifically, existing WLAN resources are converted into wireless access points (APs) to create a dense infrastructure of wireless APs. To leverage this dense AP infrastructure, central management techniques are employed. With client-to-AP mapping, these techniques are used to prevent the discovery of multiple APs in a WLAN by a client device and to select a single AP (using certain policies) to associate with the client device and provide it with an enhanced wireless connection to the WLAN. Additionally, techniques are employed to centrally determine, using central policies, when the AP should disassociate from the client device and when another centrally selected AP should respond to, and associate with, the client device to provide it with an enhanced wireless connection to the WLAN—without interrupting/disrupting the client device's access.

Abstract: Systems and methods for routing packets by nodes in an ad hoc network in accordance with a link quality source routing protocol are disclosed. Route discovery, route maintenance, and metric maintenance are designed to propagate and keep current link quality measurements. Metric maintenance includes a reactive approach for links that a node is currently using to route packets, and a proactive mechanism for all links. Nodes are configured to include a send buffer, a maintenance buffer, a request table, link quality metric modules, and preferably a neighbor cache and a link cache. The invention allows for asymmetric links in the network. The invention may be implemented within a virtual protocol interlayer between the link and network layers. The invention may employ any particular link quality metrics, including metrics based on probing techniques as well as metrics based on knowledge gained in other ways.

Abstract: Systems and methods for routing packets by nodes in an ad hoc network in accordance with a link quality source routing protocol are disclosed. Route discovery, route maintenance, and metric maintenance are designed to propagate and keep current link quality measurements. Metric maintenance includes a reactive approach for links that a node is currently using to route packets, and a proactive mechanism for all links. Nodes are configured to include a send buffer, a maintenance buffer, a request table, link quality metric modules, and preferably a neighbor cache and a link cache. The invention allows for asymmetric links in the network. The invention may be implemented within a virtual protocol interlayer between the link and network layers. The invention may employ any particular link quality metrics, including metrics based on probing techniques as well as metrics based on knowledge gained in other ways.

Abstract: A framework for wireless network management applications in an enterprise environment using existing general purpose computing devices is presented. At least one of the devices is configured with a wireless adapter and is used as an AirMonitor to monitor one or more wireless networks. Other devices are configured as LandMonitors to monitor traffic on a wired network in the enterprise environment. At least one inference engine uses the LandMonitors and AirMonitors by assigning them monitoring tasks. Data from the monitoring tasks are stored in a database. Analysis of the data that is computationally intensive is generally performed by the inference engines. Wireless network management applications use the framework by installing and running application-specific components (e.g., filters) on the AirMonitors, LandMonitors, and/or inference engines.