Cisco Technology, Inc.

Telefonaktiebolaget Lm Ericsson (publ)

Jakob Heitz

Pascal Thubert

Eric Michel Levy-Abegnoli

Eric Albin Voit

Dhananjaya Rao

David Delano Ward

Alfred C Lindem, Iii

Evgeny Tantsura

Swadesh Agrawal

Reda Haddad

Pramodh D'Souza

William Michael Hudson, Jr

Lars Ernström

Dawei Wang

Juan Alcaide

Dhananjaya Kasargod Rao

Disclosed are systems, apparatuses, methods, and computer-readable media for secure network routing. A method includes: receiving, at a network node, an advertisement message for a network route including an IP address prefix; receiving, at the network node, a route origin authorization associated with the IP address prefix, the route origin authorization including a digital signature and a security requirement of a route to a destination that corresponds to the IP address prefix; determining, by the network node, one or more network nodes satisfies the security requirement to yield a determination; and determining, by the network node, to route network traffic to the IP address prefix based on the determination. In one example, the method can include, when the one or more network nodes satisfies the security requirement, advertising the route to the one or more network nodes that satisfies the security requirement.

Advertising BGP destination secure path requirement in global internet

Techniques for mitigating BGP blackholes and hijackings are disclosed herein. The techniques include methods for determining, by a victim autonomous system (AS), that a first AS is associated with a first BGP route that includes the victim AS as the destination or as an AS along the first BGP route to the destination and sending a message to a second AS directing the second AS to refrain from using the first AS to propagate data to the victim AS. The message can include a set of one or more AS numbers to avoid in refraining from using to propagate data to the victim AS, a timestamp, an expiration interval, a signature of the victim AS, and an identifier identifying a certificate to be used to verify the signature. Systems and computer-readable media are also provided.

BGP blackhole and hijack mitigation

A particular fat tree network node stores default routing information indicating that the particular fat tree network node can reach a plurality of parent fat tree network nodes of the particular fat tree network node. The particular fat tree network node obtains, from a first parent fat tree network node of the plurality of parent fat tree network nodes, a negative disaggregation advertisement indicating that the first parent fat tree network node cannot reach a specific destination. The particular fat tree network node determines whether the first parent fat tree network node is the only parent fat tree network node of the plurality of parent fat tree network nodes that cannot reach the specific destination. If so, the particular fat tree network node installs supplemental routing information indicating that every parent fat tree network node except the first parent fat tree network node can reach the specific destination.

Routing in fat tree networks using negative disaggregation advertisements

A verifier peer system transmits a request to an application of another peer system to obtain integrity data of the application. In response to the request, the verifier peer system obtains a response that includes kernel secure boot metrics of the other peer system and integrity data of the application and of any application dependencies. If the verifier peer system determines that the response is valid, the verifier peer system evaluates the integrity data and the kernel secure boot metrics against a set of Known Good Values to determine whether the integrity data and the kernel secure boot metrics are valid. If the integrity data and the kernel secure boot metrics are valid, the verifier peer system determines that the other peer system is trustworthy.

Attestation-based route reflector

Techniques for updating a routing table based on a single message are described. One technique includes receiving at a first network device a node message from a second network device. The node message includes a sequence number and a list of link state(s) originated by the second network device. The first network device determines whether to withdraw one or more link states originated by the second network device and maintained in a routing table of the first network device based on the sequence number and the list of the link state(s) within the node message. The routing table is updated based on the determinations.

Link state addition and deletion based on reception of a single message in link state vector routing

The present disclosure provides Border Gateway Protocol route aggregation in a Clos fabric when one or more communication failures are detected. A method includes receiving a prefix component of a first aggregate route from a first next hop node, the prefix component being associated with a failed network element; announcing, to one or more neighboring nodes, the first aggregate route along with the prefix component and the first next hop node associated with the failed network element; identifying, by the one or more neighboring nodes, a second aggregate route, the second aggregate route being a shortest aggregate route that contains the first aggregate route; and generating, from the second aggregate route, one or more Chad routes to the prefix component of the first aggregate route, wherein the one or more Chad routes are associated with one or more next hop nodes that are different from the first next hop node.

BGP aggregation in Clos networks

In one embodiment a system, method, and related apparatus are described for a router which receives notice of a route including a hijacked prefix having a hijacked prefix netmask length, searches a set of routes with equal or shorter netmask lengths that cover the hijacked prefix in order to find at least one route which has no autonomous system (AS) in common with the particular route comprising the hijacked prefix, if a specific route is found with a netmask length equal to or shorter than the hijacked prefix netmask length, then the specific route which has been found is a determined alternative route, extracts the particular route comprising the hijacked prefix from the specific route if said specific route has a netmask length covering a larger address range than the hijacked prefix netmask length, inserts the determined alternative route in a routing table, and modifies attributes of the determined alternative route in the routing table according to the determined alternative route. Related systems, methods, and apparatus are also described.

Poison-path routing policy

A method is disclosed that is implemented by a router for executing an internet protocol fast reroute process in response to a network event invalidating a current route to a destination node without degrading forwarding plane functionality or performance caused by indirect forwarding information base lookups. The method comprises a set steps including receiving or generating the network event by the router, the network event associated with a network event identifier and looking up the network event identifier in an event table to determine routes that are affected by the network event. The method further includes determining whether a route with a fast reroute forwarding object is affected by the network event in the routing information base and overwriting a current next hop forwarding object using a backup next hop forwarding object in the forwarding information base.

Method and apparatus for IP/MPLS fast reroute

Embodiments of the invention include a method for maintaining an active-standby relationship between an active control card and a standby control card in a network element. The network element receives a data from a remote peer at the active control card. The network element communicates data from the active TCP module to an active application module in the active control card. The network element communicates synchronization data from the active application module to a standby application module on the standby control card. The network element communicates a single application synchronization acknowledgement from the standby application module to the active APP module. The network element communicates an application acknowledgment packet from the active application module to the active TCP module responsive to receiving the application synchronization acknowledgment. The network element then communicates an acknowledgement to the remote peer responsive to the application acknowledgement.

Synchronization between active TCP application and standby TCP application

A method, in a first network element of an inter-chassis redundancy (ICR) system, of cooperating with a second network element of the ICR system to provide ICR. The network elements are coupled by a synchronization channel. IP addresses are announced with a favorable traffic direction attribute. It is determined that the second network element either has announced the IP addresses with an unfavorable traffic direction attribute less favorable than the favorable direction attribute, or has not announced the IP addresses. Sessions that are connected through the IP addresses are handled. Session state synchronization messages that include session state for the handled sessions are transmitted over the synchronization channel to the second network element. It is determined, after an occurrence of a failure event that inhibits the first element from handling the sessions, that the IP addresses have been announced by the second network element with a favorable traffic direction attribute.

Inter-chassis redundancy with coordinated traffic direction

Embodiments of the invention include a method for maintaining an active-standby relationship between an active control card and a standby control card in a network element. The network element receives a data from a remote peer at the active control card. The network element communicates data from the active TCP module to an active application module in the active control card. The network element communicates synchronization data from the active application module to a standby application module on the standby control card. The network element communicates an application synchronization acknowledgement from the standby application module to the active APP module. The network element communicates an application acknowledgment packet from the active application module to the active TCP module responsive to receiving the application synchronization acknowledgment. The network element then communicates an acknowledgement to the remote peer responsive to the application acknowledgement.

Growing community of inventors

Santa Clara, CA, United States of America

Jakob Heitz