Microsoft Technology Licensing, LLC

Cisco Technology, Inc.

Himanshu Raj

Alastair Wolman

Stefan Saroiu

Paul England

Umesh Krishnaswamy

Stefan Thom

David John Linsley

David Michael Robinson

Magnus Nystrom

Jeremiah J Cox

Rob Spiger

He H Liu

Pradeep Padala

Rachee Singh

Kiran Kamity

Shravan Rayanchu

Anh M Nguyen

Selvi Kadirvel

Chen Chen

Paul David Mattes

Parveen Kumar Patel

Nikolaj Skallerud Bjorner

Srikanth Kandula

Michael Kevin Larkin

Ryan Andrew Beckett

Yiqun Cai

Behnaz Arzani

Pooria Namyar

Santiago Martin Segarra

Luis Irun-briz

Patrick J Colp

Nuno Santos

Sonal Kothari

John Michael Abeln

Pappula Prabhakar Reddy

Paul-Andre C Bissonnette

A system manages network traffic in a distributed system comprising a plurality of network devices. The network devices are divided into a plurality of network slices, each of the network slices including a subset of the network devices such that there is no overlap of network devices between the network slices. Individual network slices are associated with individual slice controllers, and an individual slice controller is configured to manage network routing of an individual network slice. Each of the individual slice controllers route the network traffic within each respective individual network slice. The network traffic is independently routed based on expected network conditions for each respective individual network slice, and data defining routing decisions is contained within each network slice to limit fault effects between the network slices.

Decentralized wide-area network traffic engineering

Solutions are disclosed that enable capacity-aware local repair of tunnels in packet switched wide area networks (WANs). Traffic engineering agents on the routers are programmed to create the tunnels and include sets of primary and alternate tunnels sharing the same source and destination. A tunnel source router is provided a traffic split for allocating incoming traffic to its primary and alternate tunnels for when the primary tunnel is operating at or near full capacity operation, and another traffic split that shifts at least some traffic from the primary tunnel to the alternate tunnel, when the primary tunnel's capacity drops below a threshold. A tunnel may lose capacity for commonly-occurring reasons, such as a disturbance to cabling and faults in optical transceivers. Traffic engineering agents along the tunnel report capacity to the tunnel source router, permitting the network to respond to capacity changes more rapidly than waiting for network tunnel reconfiguration.

Capacity-aware local repair of tunnels in wide area networks

A method and a network for routing data packet in a unified wide area network (WAN) is provided. The method includes encapsulating a data packet by an ingress aggregation router and forwarding the encapsulated data packet to an ingress backbone router. The encapsulated data packet includes a first label. The ingress backbone router selects an optimized traffic engineered tunnel and replaces the first label with the optimized traffic engineered tunnel and forwards the encapsulated data packet along the optimized traffic engineered tunnel.

Systems and methods for routing data packet in a unified wide area network

A computing device is provided, including a processor that receives a network graph. The processor further receives a specification of a network traffic control heuristic for a network traffic routing problem over the network graph. The processor further constructs a gap maximization problem that has, as a maximization target, a difference between an exact solution to the network traffic routing problem and a heuristic solution generated using the network traffic control heuristic. The processor further generates a Lagrange multiplier formulation of the gap maximization problem. At a convex solver, the processor further computes an estimated maximum gap as an estimated solution to the Lagrange multiplier formulation of the gap maximization problem. The processor further performs a network traffic control action based at least in part on the estimated maximum gap.

Network traffic control using estimated maximum gap

Technologies pertaining to limiting access to secret data through utilization of sensor-based constraints are described herein. A sensor-based constraint is a constraint that can only be satisfied by predefined readings that may be output by at least one sensor on a mobile computing device. If the sensor on the mobile computing device outputs a reading that satisfies the sensor-based constraint, secret data is provided to a requesting application. Otherwise, the requesting application is prevented from accessing the secret data.

Sealing secret data with a policy that includes a sensor-based constraint

In one embodiment, a system has host machines forming a cluster. Each host machine runs containers, where each container includes a segment of hardware resources associated with the host machine, a segment of an operating system utilized by the host machine, and at least one application. Host agents operate on the host machines. Each host agent collects operational parameters associated with the containers on each host machine. A management platform is operative to divide the cluster into container pools, where each container pool includes a sub-set of computation resources in the cluster and has associated container pool metrics including a priority level and computation resource limits. Operational parameters are collected from the host agents. The operational parameters are evaluated in accordance with the container pool metrics.

Container management and application ingestion engine

Disclosed is a trusted language runtime (TLR) architecture that provides abstractions for developing a runtime for executing trusted applications or portions thereof securely on a mobile device (e.g., a smartphone). TLR offers at least two abstractions to mobile developers: a trustbox and a trustlet. The trustbox is a runtime environment that offers code and data integrity, and confidentiality. Code and data running inside a trustbox cannot be read or modified by any code running outside the trustbox. A trustlet is the code portion of an application that runs inside a trustbox. With TLR, programmers can write applications in .NET and specify which parts of the application handle sensitive data, and thus, run inside the trustbox. With the TLR, the developer places these parts in a trustlet class, and the TLR provides all support needed to run the parts in the trustbox.

Trusted language runtime on a mobile platform

Various technologies described herein pertain to a computing device that includes secure hardware (e.g., a TPM, a secure processor of a processing platform, protected memory that includes a software-based TPM, etc.). The secure hardware includes a shared secret, which is shared by the secure hardware and a server computing system. The shared secret is provisioned by the server computing system or a provisioning computing system of a party affiliated with the server computing system. The secure hardware further includes a cryptographic engine that can execute a cryptographic algorithm using the shared secret or a key generated from the shared secret. The cryptographic engine can execute the cryptographic algorithm to perform encryption, decryption, authentication, and/or attestation.

Secure hardware for cross-device trusted applications

A multi-gateway virtual machine that operates multiple gateways. Each gateway acts as an interface between a virtual network and entities outside of the virtual network. Each virtual network has its own address space, which may be overlapping with the address space of other virtual networks, even if the gateways of those virtual networks are operating on the same virtual machine. Accordingly, the principles described herein relate to a virtual machine that can operate thereon multiple gateways, and thus to a multi-gateway virtual machine that services multiple virtual networks.

Multiple gateway operation on single operating system

Described is a technology by which classes of memory attacks are prevented, including cold boot attacks, DMA attacks, and bus monitoring attacks. In general, secret state such as an AES key and an AES round block are maintained in on-SoC secure storage, such as a cache. Corresponding cache locations are locked to prevent eviction to unsecure storage. AES tables are accessed only in the on-SoC secure storage, to prevent access patterns from being observed. Also described is securely preparing for an interrupt-based context switch during AES round computations and securely resuming from a context switch without needing to repeat any already completed round or round of computations.

Protecting secret state from memory attacks

A 'Firmware-Based TPM' or 'fTPM' ensures that secure code execution is isolated to prevent a wide variety of potential security breaches. Unlike a conventional hardware based Trusted Platform Module (TPM), isolation is achieved without the use of dedicated security processor hardware or silicon. In general, the fTPM is first instantiated in a pre-OS boot environment by reading the fTPM from system firmware or firmware accessible memory or storage and placed into read-only protected memory of the device. Once instantiated, the fTPM enables execution isolation for ensuring secure code execution. More specifically, the fTPM is placed into protected read-only memory to enable the device to use hardware such as the ARM&#xae; architecture's TrustZone&#x2122; extensions and security primitives (or similar processor architectures), and thus the devices based on such architectures, to provide secure execution isolation within a &#x201c;firmware-based TPM&#x201d; without requiring hardware modifications to existing devices.

Trustzone-based integrity measurements and verification using a software-based trusted platform module

In a cloud computing environment, a production server virtualization stack is minimized to present fewer security vulnerabilities to malicious software running within a guest virtual machine. The minimal virtualization stack includes support for those virtual devices necessary for the operation of a guest operating system, with the code base of those virtual devices further reduced. Further, a dedicated, isolated boot server provides functionality to securely boot a guest operating system. The boot server is isolated through use of an attestation protocol, by which the boot server presents a secret to a network switch to attest that the boot server is operating in a clean mode. The attestation protocol may further employ a secure co-processor to seal the secret, so that it is only accessible when the boot server is operating in the clean mode.

Attestation protocol for securely booting a guest operating system

Growing community of inventors

Issaquah, WA, United States of America

Himanshu Raj