Patent Description:
Sensitive information may be transmitted through one or more nodes within a network. Certain nodes within the network may become compromised. For example, an attacker may gain access to one or more of the network nodes. If a network node is compromised, traditional protections such as link encryption may prove ineffectual in protecting the sensitive information traversing the compromised node.

<NPL>, discloses a distributed authentication platform (DAP) architecture that addresses the problems of fast user authentication and secure data transmission in large-scale ubiquitous networks. <CIT>, <CIT> and <NPL>" represent other relevant pieces of prior art which have been employed by the EPO to assess the merits of the present application.

According to an embodiment, a router includes one or more processors and one or more computer-readable non-transitory storage media coupled to the one or more processors. The one or more computer-readable non-transitory storage media include instructions that, when executed by the one or more processors, cause the router to perform operations including determining a path through a plurality of provider nodes within a provider network and determining that the path through the plurality of provider nodes within the provider network is secure. The operations also include receiving, from a customer node, a Resource Reservation Protocol (RSVP) path message comprising an attribute for a security request. The operations further include routing the RSVP path message along the path of the plurality of provider nodes.

The operations may include receiving an RSVP reservation (resv) message from one of the plurality of provider nodes, verifying that the path through the plurality of provider nodes is secure based on the RSVP resv message, communicating, to the customer node, that the path through the plurality of provider nodes is secure, receiving, from the customer node, customer data, and routing the customer data along the path of the plurality of provider nodes. The operations may include determining an alternate path through a plurality of alternate provider nodes within the provider network, determining that the alternate path through the plurality of alternate provider nodes within the provider network is secure, receiving an RSVP path error message from one of the plurality of provider nodes, and routing the RSVP path message along the alternate path of the plurality of alternate provider nodes in response to receiving the RSVP path error message.

In certain embodiments, the router is a provider edge node of the plurality of provider nodes. The operations may include communicating an identity of the provider edge node to the customer node. The RSVP path message may be received by the provider edge node from the customer node in response to communicating the identity of the provider edge node to the customer node. Determining that the path through the plurality of provider nodes within the provider network is secure may include deriving information from each of the plurality of provider nodes from interior gateway protocol (IGP) advertisements and/or a controller of the provider network, determining a security level for each of the plurality of provider nodes based on the derived information, and determining that the security level of each of the plurality of provider nodes is below a predetermined security constraint value. The RSVP path message may also include a Record Route Object (RRO), Label Switched Paths (LSP) attributes, and/or link attributes. Determining that the path through the plurality of provider nodes within the provider network is secure may be performed prior to receiving the RSVP path message from the customer node. The operations may include verifying that the path through the plurality of provider nodes within the provider network is secure after receiving the RSVP path message from the customer node.

According to another embodiment, a method includes determining a path through a plurality of provider nodes within a provider network and determining that the path through the plurality of provider nodes within the provider network is secure. The method also includes receiving, from a customer node, an RSVP path message that includes an attribute for a security request. The method further includes routing the RSVP path message along the path of the plurality of provider nodes.

The method may include receiving an RSVP resv message from one of the provider nodes, verifying that the path through the plurality of provider nodes is secure based on the RSVP resv message, communicating, to the customer node, that the path through the plurality of provider nodes is secure, receiving, from the customer node, customer data, and routing the customer data along the path of the plurality of provider nodes. The method may include determining an alternate path through a plurality of alternate provider nodes within the provider network, determining that the alternate path through the plurality of alternate provider nodes within the provider network is secure, receiving an RSVP path error message from one of the provider nodes, and routing the RSVP path message along the alternate path of the plurality of alternate provider nodes in response to receiving the RSVP path error message.

The method may include communicating an identity of a provider edge node to the customer node. The RSVP path message may be received by the provider edge node from the customer node in response to communicating the identity of the provider edge node to the customer node. Determining that the path through the plurality of provider nodes within the provider network is secure may include deriving information from each of the plurality of provider nodes from IGP advertisements and/or a controller of the provider network, determining a security level for each of the plurality of provider nodes based on the derived information, and determining that the security level of each of the plurality of provider nodes is below a predetermined security constraint value. The RSVP path message may include an RRO, LSP attributes, and/or link attributes. The method may include determining that the path through the plurality of provider nodes within the provider network is secure prior to receiving the RSVP path message from the customer node and verifying that the path through the plurality of provider nodes within the provider network is secure after receiving the RSVP path message from the customer node.

According to yet another embodiment, one or more computer-readable non-transitory storage media embody instructions that, when executed by a processor, cause the processor to perform operations including determining a path through a plurality of provider nodes within a provider network and determining that the path through the plurality of provider nodes within the provider network is secure. The operations also include receiving, from a customer node, an RSVP path message comprising an attribute for a security request. The operations further include routing the RSVP path message along the path of the plurality of provider nodes.

The operations may include receiving an RSVP resv message from one of the plurality of provider nodes, verifying that the path through the plurality of provider nodes is secure based on the RSVP resv message, communicating, to the customer node, that the path through the plurality of provider nodes is secure, receiving, from the customer node, customer data, and routing the customer data along the path of the plurality of provider nodes. The operations may include determining an alternate path through a plurality of alternate provider nodes within the provider network, determining that the alternate path through the plurality of alternate provider nodes within the provider network is secure, receiving an RSVP path error message from one of the plurality of provider nodes, and routing the RSVP path message along the alternate path of the plurality of alternate provider nodes in response to receiving the RSVP path error message.

The operations may include communicating an identity of a provider edge node to the customer node. The RSVP path message may be received by the provider edge node from the customer node in response to communicating the identity of the provider edge node to the customer node. Determining that the path through the plurality of provider nodes within the provider network is secure may include deriving information from each of the plurality of provider nodes from IGP advertisements and/or a controller of the provider network, determining a security level for each of the plurality of provider nodes based on the derived information, and determining that the security level of each of the plurality of provider nodes is below a predetermined security constraint value. The RSVP path message may also include a RRO, LSP attributes, and/or link attributes. Determining that the path through the plurality of provider nodes within the provider network is secure may be performed prior to receiving the RSVP path message from the customer node. The operations may include verifying that the path through the plurality of provider nodes within the provider network is secure after receiving the RSVP path message from the customer node.

Technical advantages of certain embodiments of this disclosure may include one or more of the following. The systems and methods described herein allow a customer to request a path from a provider that meets specific security criteria. The customer can verify that the path selected by the provider meets the specific security criteria before communicating sensitive information to the provider. The provider uses RSVP to verify the security of the path prior to routing the customer's sensitive information through the path.

Other technical advantages will be readily apparent to one skilled in the art from the following figures, descriptions, and claims. Moreover, while specific advantages have been enumerated above, various embodiments may include all, some, or none of the enumerated advantages.

In certain embodiments of this disclosure, a customer (e.g., a medical, financial, or military organization) signals into a provider (e.g., a service provider) to request a certified path through the nodes of the provider's network to a target host or Internet Protocol (IP) address. The provider replies to the customer whether the provider can provide the requested certified path. In certain embodiments, verifiable specifics associated with establishing trust of the selected certified path is provided to the customer. The verifiable specifics may include attested proof from the transited nodes along the selected certified path that the nodes are secure.

<FIG> shows an example system for determining a secure network path using RSVP, and <FIG> shows another example system for determining a secure network path to be used by the system of <FIG>. <FIG> shows an example method for determining a secure network path within a provider network, and <FIG> shows an example method for determining a secure network path within a customer network. <FIG> shows an example computer system that may be used by the systems and methods of <FIG>.

<FIG> illustrates an example system <NUM> for determining a secure network path using RSVP. RSVP is transport layer protocol designed to reserve resources across a network for quality of service (QoS). In certain embodiments, system <NUM> may use RSVP Traffic Engineering (RSVP-TE). RSVP-TE is resource reservation protocol that is used to allocate bandwidth for individual paths through the network. System <NUM> or portions thereof may be associated with an entity, which may include any entity, such as a business or company (e.g., a service provider) that determines secure network paths. The components of system <NUM> may include any suitable combination of hardware, firmware, and software. For example, the components of system <NUM> may use one or more elements of the computer system of <FIG>.

System <NUM> includes a network <NUM>, a provider domain <NUM>, and a customer domain <NUM>. Network <NUM> of system <NUM> is any type of network that facilitates communication between components of system <NUM>. Network <NUM> may connect one or more components of system <NUM>. This disclosure contemplates any suitable network. One or more portions of network <NUM> may include an ad-hoc network, an intranet, an extranet, a VPN, a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, a combination of two or more of these, or other suitable types of networks. Network <NUM> may include one or more networks. Network <NUM> may be any communications network, such as a private network, a public network, a connection through Internet, a mobile network, a WI-FI network, etc. One or more components of system <NUM> may communicate over network <NUM>. Network <NUM> may include a core network (e.g., the Internet), an access network of a service provider, an Internet service provider (ISP) network, and the like.

Provider domain <NUM> of system <NUM> is a group of nodes (e.g., computers and devices) on network <NUM> that are administered as a unit with common rules and procedures. Provider domain <NUM> may be associated with any provider, such as an application service provider, a network service provider, an ISP, a security service provider, a telecommunications service provider, an infrastructure service provider, a provider of cloud computing, and the like. One or more components of provider domain <NUM> may be controlled by the provider. Provider domain <NUM> includes one or more provider nodes <NUM>, one or more provider edge nodes <NUM>, and a provider controller <NUM>.

Provider nodes <NUM> of provider domain <NUM> are connection points within provider domain <NUM> that receive, create, store and/or send data along a path. Provider nodes <NUM> are managed by the administrator (e.g., a service provider) of provider domain <NUM>. Provider nodes <NUM> may include one or more endpoints and/or one or more redistribution points that recognize, process, and forward data to other provider nodes <NUM>. Provider nodes <NUM> may include virtual and/or physical network nodes. In certain embodiments, one or more provider nodes <NUM> include data communications equipment such as switches, bridges, modems, hubs, and the like. In some embodiments, one or more provider nodes <NUM> include data terminal equipment such as routers, servers, printers, workstations, and the like. Certain provider nodes <NUM> may be host computers.

Provider edge nodes <NUM> of provider domain <NUM> are provider nodes <NUM> within provider domain <NUM> that act as an interface for communication with nodes of a different domain (e.g., customer edge nodes <NUM> of customer domain <NUM>). For example, provider edge nodes <NUM> may be gateway nodes or edge communication nodes. Provider edge nodes <NUM> are managed by the administrator of provider domain <NUM>. In certain embodiments, one or more provider edge nodes <NUM> may determine whether one or more provider nodes <NUM> within provider domain <NUM> are secure. For example, provider edge node <NUM> may receive security information from provider controller <NUM>. As another example, provider edge node <NUM> may derive information from each provider node <NUM> from IGP advertisements. Examples of IGP include Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Intermediate System to Intermediate System (IS-IS), Enhanced Interior Gateway Routing Protocol (EIGRP), and the like.

Provider edge node <NUM> of provider domain <NUM> may determine a security level for each provider node <NUM> based on the derived information. Provider edge node <NUM> compares the security level to a predetermined security constraint value. If the security level is below a predetermined security constraint value, provider edge node <NUM> determines that provider node <NUM> is secure. If provider edge node <NUM> cannot determine a security level for a particular provider node <NUM>, provider edge node <NUM> determines that the particular provider node <NUM> is compromised.

In certain embodiments, provider edge node <NUM> of provider domain <NUM> may communicate a secure message <NUM> to a node (e.g., customer edge node <NUM>) of customer domain <NUM>. Secure message <NUM> is any message that is sent over a path that qualifies under predetermined security criteria. The predetermined security criteria is designed to reduce or eliminate the potential for exposure of information traversing the path. Secure message <NUM> may be an exterior gateway protocol (EGP) message (e.g., a Border Gateway protocol (BGP)), a message communicated using an offline mechanism, and the like. Secure message <NUM> includes an identity of provider edge node <NUM>. The identity of provider edge node <NUM> is communicated to the node of customer domain <NUM> to inform customer domain <NUM> that provider edge node <NUM> is a secure entry into provider domain <NUM>. Customer domain may then communicate network path requests to provider edge node <NUM>.

Provider edge node <NUM> may receive an RSVP path message <NUM> from customer edge node <NUM>. If provider edge node <NUM> determines a secure path though provider domain, provider edge node <NUM> routes RSVP path message <NUM> along the secure path of provider nodes <NUM> and/or provider edge nodes <NUM>. RSVP path message <NUM> is sent from provider edge node <NUM> to a destination provider node <NUM>. Destination provider node <NUM> may be identified by a hostname or an IP address in RSVP path message <NUM>. RSVP path message <NUM> includes an attribute for a security request. The attribute for the security request indicates to provider edge node <NUM> that customer domain <NUM> is requesting a secure path to communicate customer data <NUM> through provider domain <NUM> to another destination domain or to a destination node within provider domain <NUM>. The attribute for the security request may be in addition to existing attributes (e.g., bandwidth attributes) of RSVP path message <NUM>.

RSVP path message <NUM> may include a RRO. The RRO stores IP addresses of the traversed nodes. RSVP path message <NUM> may include LSP attributes, link attributes, and the like. Provider edge node <NUM> may communicate RSVP path message <NUM> along the secure path at predetermined intervals (e.g., every <NUM> seconds. ) If one or more provider nodes <NUM> and/or provider edge nodes <NUM> that receive RSVP path message <NUM> do not understand RSVP, that provider node <NUM> and/or provider edge node <NUM> may forward RSVP path message <NUM> without interpreting its contents and will not reserve resources for the flow.

Provider edge node <NUM> may receive an RSVP resv message <NUM> from one or more provider nodes <NUM> and/or provider edge nodes <NUM>. RSVP resv message <NUM> is communicated from destination provider node <NUM> to provider edge node <NUM> through a reverse path of the path traversed by RSVP path message <NUM>. The RSVP resv message <NUM> may include flow specifications. Provider edge node <NUM> may verify that the path is secure in response to receiving RSVP resv message <NUM>. Provider edge node <NUM> may communicate RSVP resv message <NUM> to customer edge node <NUM>, which indicates to customer edge node <NUM> that the path is secure. In certain embodiments, RSVP resv message <NUM> may time out. If RSVP resv message <NUM> times out, this indicates that one or more provider nodes <NUM> and/or provider edge nodes <NUM> did not satisfy one or more constraints of RSVP resv message <NUM>.

In response to receiving RSVP resv message, customer edge node <NUM> may communicate customer data <NUM> to provider edge node <NUM>. Customer data <NUM> is any sensitive information associated with customer domain <NUM> that may pose a risk to customer domain <NUM> if discovered by another entity or the general public. Customer data <NUM> may include personal information (e.g., medical information, biometric data, Social Security numbers, etc.), business information (e.g., trade secrets, financial data, acquisition plans, etc.), classified information pertaining to a government body (e.g., restricted information, confidential information, top secret information, etc.), and the like. Provider edge node <NUM> then routes customer data <NUM> along the verified path.

Provider edge node <NUM> may determine one or more alternate paths along one or more provider nodes <NUM> and/or provider edge nodes <NUM> and route RSVP path message <NUM> along the alternate route in response to one or more conditions. A condition may include provider edge node <NUM> receiving an RSVP path error message. Provider edge node <NUM> may determine that the path is not secure in response to receiving the RSVP path error message <NUM>. Another condition may include provider edge node <NUM> determining that RSVP path message <NUM> timed out. Other conditions for using alternate paths may include path protection of the original path, Fast Reroute (FRR), and the like.

Provider controller <NUM> of system <NUM> is a component that determines secure nodes within provider domain <NUM>. For example, provider controller <NUM> may determine that one or more provider nodes <NUM> and/or provider edge nodes <NUM> of provider domain <NUM> are secure. Provider controller <NUM> may determine whether one or more provider nodes <NUM> and/or provider edge nodes <NUM> of provider domain <NUM> are secure by analyzing a security posture of each provider node <NUM> and/or provider edge node <NUM>. For example, provider controller <NUM> may verify the security posture of each provider node <NUM> and/or provider edge node <NUM> using the underlying hardware of each provider node <NUM> and/or provider edge node <NUM>. As another example, provider controller <NUM> may determine the security level of each provider node <NUM> and/or provider edge node <NUM> using routing protocols.

In certain embodiments, provider controller <NUM> may validate certain predetermined security metrics to determine whether each provider node <NUM> and/or provider edge node <NUM> is secure. The security metrics may be associated with one or more of the following: a number of vulnerabilities found on a network device, an operating system, an application server, middleware, and the like; an assessment of whether malware protection software has been properly installed and/or is up to date; a determination of whether automatic vulnerability system scans have been performed; a determination of whether penetration testing has been performed; a number of open security exceptions; a determination of whether the design, adoption, and/or delivery of an application is in accordance with an approved written policy, procedure, standard, and/or guideline; a determination of whether access to an application and/or data is in accordance with an approved written policy, procedure, standard, and/or guideline; and the like.

One or more components of system <NUM> (e.g., provider edge node <NUM> or provider controller <NUM>) may determine a security level of the path through provider nodes <NUM> and/or provider edge nodes <NUM>. The security level may be equal to the minimum security level of each provider node <NUM> and/or provider edge node <NUM> along the path. If a security level of provider node <NUM> and/or provider edge node <NUM> cannot be determined, that corresponding provider node <NUM> and/or provider edge node <NUM> is assumed compromised. The security level of the path through provider nodes <NUM> and/or provider edge nodes <NUM> may be advertised to one or more components of customer domain <NUM> in a control plane protocol. For example, the security level may be advertised through Stateful Path Computation Element Protocol (PCEP), BGP Link State (BGP-LS), and the like.

In certain embodiments, the verified path (e.g., the RSVP-TE tunnel) through provider domain <NUM> may be advertised to one or more components of customer domain <NUM>. The verified path may be advertised with a binding segment ID. In some embodiments, the verified path is hidden from customer domain <NUM>. For example, upon customer domain <NUM> receiving an indication from provider domain <NUM> that a path through provider domain <NUM> is verified, customer domain <NUM> may communicate customer data <NUM> to a secure node of provider domain <NUM> without knowing the path that customer data <NUM> will travel through customer domain <NUM>.

Customer domain <NUM> of system <NUM> is a group of nodes (e.g., computers and devices) on network <NUM> that are administered as a unit with common rules and procedures. Customer domain <NUM> may be associated with any customer, such as the Federal Bureau of Investigation (FBI), the United States Department of Defense, a police department, and the like. One or more components of customer domain <NUM> may be controlled by an entity (e.g., the customer). Customer domain <NUM> includes customer nodes <NUM>, customer edge nodes <NUM>, and a customer controller <NUM>.

Customer nodes <NUM> of customer domain <NUM> are connection points within customer domain <NUM> that receive, create, store and/or send data along a path. Customer nodes <NUM> are managed by the administrator of customer domain <NUM>. Customer nodes <NUM> may include one or more endpoints and one or more redistribution points that recognize, process, and forward data to other customer nodes <NUM>. Customer nodes <NUM> may include virtual and/or physical network nodes. In certain embodiments, one or more customer nodes <NUM> include data communications equipment such as switches, bridges, modems, hubs, and the like. In some embodiments, one or more customer nodes <NUM> include data terminal equipment such as routers, servers, printers, workstations, and the like. One or more customer nodes <NUM> may be host computers.

Customer edge nodes <NUM> of customer domain <NUM> are customer nodes <NUM> within customer domain <NUM> that act as an interface for communication with nodes of a different domain (e.g., provider nodes <NUM> of provider domain <NUM>). For example, customer edge nodes <NUM> may be gateway nodes or edge communication nodes. Customer edge nodes <NUM> are managed by the administrator of customer domain <NUM>. In certain embodiments, one or more customer edge nodes <NUM> may determine whether one or more customer nodes <NUM> within customer domain <NUM> are secure. For example, customer edge node <NUM> may receive security information from customer controller <NUM>. As another example, customer edge node <NUM> may derive information from each customer node <NUM> from IGP advertisements. Customer edge node <NUM> may determine a security level for each customer edge node <NUM> based on the derived information. Customer edge node <NUM> compares the security level to a predetermined security constraint value. If the security level is below a predetermined security constraint value, customer edge node <NUM> determines that customer node <NUM> is secure.

Customer controller <NUM> of system <NUM> is a component that determines secure nodes within customer domain <NUM>. For example, customer controller <NUM> may determine that one or more customer nodes <NUM> and/or customer edge nodes <NUM> of customer domain <NUM> are secure. Customer controller <NUM> may determine whether one or more customer nodes <NUM> and/or customer edge nodes <NUM> of customer domain <NUM> are secure by analyzing a security posture of each customer node <NUM> and/or customer edge node <NUM>. For example, customer controller <NUM> may verify the security posture of each customer node <NUM> and/or customer edge node <NUM> using the underlying hardware of each customer node <NUM> and/or customer edge node <NUM>. As another example, customer controller <NUM> may determine the security level of each customer node <NUM> and/or customer edge node <NUM> using routing protocols.

In certain embodiments, customer controller <NUM> may validate certain predetermined security metrics to determine whether each customer node <NUM> and/or customer edge node <NUM> is secure. The security metrics may be associated with one or more of the following: a number of vulnerabilities found on a network device, operating system, application server, middleware, and the like; an assessment of whether malware protection software has been properly installed and/or is up to date; a determination of whether automatic vulnerability system scans have been performed; a determination of whether penetration testing has been performed; a number of open security exceptions; a determination of whether the design, adoption, and/or delivery of an application is in accordance with an approved written policy, procedure, standard, and/or guideline; a determination of whether access to an application and/or data is in accordance with an approved written policy, procedure, standard, and/or guideline; and the like.

In operation, provider controller <NUM> of provider domain <NUM> determines which provider nodes <NUM> and provider edge nodes <NUM> of provider domain <NUM> are secure. Provider controller <NUM> communicates the identity of the secure provider nodes <NUM> and secure provider edge nodes <NUM> to a particular secure provider edge node <NUM>. Provider edge node <NUM> determines a secure path through provider nodes <NUM> and/or provider edge nodes <NUM>. Provider edge node <NUM> communicates secure message <NUM> to customer edge node <NUM> of customer domain <NUM>. Secure message <NUM> includes an identity of secure provider edge node <NUM>. Customer edge node <NUM> requests to send a message through a secure path of provider domain <NUM> by communicating RSVP path message <NUM> to the secure entry of provider edge node <NUM>. Provider edge node <NUM> receives RSVP path message <NUM>, which includes an attribute for a security request. Provider edge node <NUM> routes RSVP path message <NUM> along the secure path through provider nodes <NUM> and/or provider edge nodes <NUM>. Provider edge node <NUM> receives RSVP resv message <NUM> from provider node <NUM> along the secure path, which verifies that the path through provider nodes <NUM> and/or provider edge nodes <NUM> is secure. Provider edge node <NUM> communicates RSVP resv message <NUM> to customer edge node <NUM>. In response to receiving RSVP resv message <NUM> from provider edge node <NUM>, customer edge node <NUM> communicates customer data <NUM> to provider edge node <NUM>, and provider edge node <NUM> routes customer data <NUM> along the secure path. As such, system <NUM> of <FIG> allows customer domain <NUM> to communicate customer data <NUM> along a path through provider domain <NUM> that meets specific security criteria.

Although <FIG> illustrates a particular arrangement of network <NUM>, provider domain <NUM>, provider nodes <NUM>, provider edge nodes <NUM>, provider controller <NUM>, customer domain <NUM>, customer nodes <NUM>, customer edge nodes <NUM>, customer controller <NUM>, secure message <NUM>, RSVP path message <NUM>, RSVP resv message <NUM>, and customer data <NUM>, this disclosure contemplates any suitable arrangement of network <NUM>, provider domain <NUM>, provider nodes <NUM>, provider edge nodes <NUM>, provider controller <NUM>, customer domain <NUM>, customer nodes <NUM>, customer edge nodes <NUM>, customer controller <NUM>, secure message <NUM>, RSVP path message <NUM>, RSVP resv message <NUM>, and customer data <NUM>. For example, provider domain <NUM> and customer domain <NUM> may switch locations such that provider domain <NUM> receives secure message <NUM>, communicates RSVP path message <NUM>, etc..

Although <FIG> illustrates a particular number of networks <NUM>, provider domains <NUM>, provider nodes <NUM>, provider edge nodes <NUM>, provider controllers <NUM>, customer domains <NUM>, customer nodes <NUM>, customer edge nodes <NUM>, customer controllers <NUM>, secure messages <NUM>, RSVP path messages <NUM>, RSVP resv messages <NUM>, and customer data <NUM>, this disclosure contemplates any suitable number of networks <NUM>, provider domains <NUM>, provider nodes <NUM>, provider edge nodes <NUM>, provider controllers <NUM>, customer domains <NUM>, customer nodes <NUM>, customer edge nodes <NUM>, customer controllers <NUM>, secure messages <NUM>, RSVP path messages <NUM>, RSVP resv messages <NUM>, and customer data <NUM>. For example, system <NUM> may include multiple customer domains <NUM>.

<FIG> illustrates an example system <NUM> for determining a secure network path that may be used by the system of <FIG>. System <NUM> includes provider domain <NUM> and customer domain <NUM>. Provider domain <NUM> of system <NUM> includes provider nodes P1, P2, P3, P4, and P5 and provider edge nodes PE1 and PE2. Provider domain <NUM> includes a first path from PE1 to P2, P2 to P3, and P3 to PE2. Provider domain <NUM> includes a second path from PE1 to P1 and P1 to PE2. Provider domain <NUM> includes a third path from PE1 to P4, P4 to P5, and P5 to PE2. Customer domain <NUM> of system <NUM> includes customer nodes C1, C2, C3, C4, and C5 and customer edge nodes CE1 and CE2. Customer domain <NUM> includes a first path from CE1 to C2, C2 to C3, and C3 to CE2. Customer domain <NUM> includes a second path from CE1 to C1 and C1 to CE2. Customer domain <NUM> includes a third path from CE1 to C4, C4 to C5, and C5 to CE2.

In the illustrated embodiment of <FIG>, PE1 of provider domain <NUM> determines that P4, P5, and PE2 are secure provider nodes. For example, PE1 may derive security level information for P4, P5, and PE1 from a provider controller (e.g., provider controller <NUM> of <FIG>) and/or IGP advertisements and determine that P4, P5, and PE2 are secure based on the security level of each node being below a predetermined security constraint value. PE1 may then determine that the third path from PE1 to P4, P4 to P5, and P5 to PE2 is secure. PE1 may determine that certain provider nodes of provider domain <NUM> are not secure. For example, PE1 may determine that the security level of P1 is above a predetermined security constraint value. Based on this determination, PE1 may determine that P1 is not secure and/or compromised.

PE1 of provider domain <NUM> communicates secure message <NUM> to CE1 of customer domain <NUM>, which informs CE1 that PE1 is a secure entry. CE1 requests a path that meets specific security criteria by communicating RSVP path message <NUM> to PE1. PE1 routes RSVP path message <NUM> along the third path from PE1 to P4, P4 to P5, and P5 to PE2. PE2, upon receiving RSVP path message <NUM>, generates RSVP resv message <NUM> and communicates RSVP resv message <NUM> to PE1 along the reverse path from PE2 to P5, P5 to P4, and P4 to PE1. In response to receiving RSVP resv message <NUM>, PE1 verifies that the third path is secure. PE1 communicates RSVP resv message <NUM> to CE1. In response to receiving RSVP resv message <NUM>, CE1 communicates customer data <NUM> to PE1. PE1 routes customer data <NUM> along the third route.

In certain embodiments, in response to routing RSVP path message <NUM> along the third path, PE1 may not receive RSVP resv message <NUM> or may receive an RSVP path error message, indicating that the third path is not secure. If PE1 determines that the third path is not secure, PE1 may route RSVP path message <NUM> along an alternate route. For example, PE1 may route RSVP path message <NUM> along the first route from PE1 to P2, P2 to P3, and P3 to PE2. PE1 will not route RSVP path message <NUM> along a path in which PE1 determines that one or more provider nodes of the path are not secure. In some embodiments, PE1 may route RSVP path message <NUM> along an alternate route even though the original route is secure. For example, PE1 may route RSVP path message <NUM> along an alternate route due to path protection, FRR, and the like.

Although <FIG> illustrates a particular arrangement of provider domain <NUM>, provider nodes P1, P2, P3, P4, and P5, provider edge nodes PE1 and PE2, customer domain <NUM>, customer nodes C1, C2, C3, C4, and C5, customer edge nodes CE1 and CE <NUM>, secure message <NUM>, RSVP path message <NUM>, RSVP resv message <NUM>, and customer data <NUM>, this disclosure contemplates any suitable arrangement of provider domain <NUM>, provider nodes P1, P2, P3, P4, and P5, provider edge nodes PE1 and PE2, customer domain <NUM>, customer nodes C1, C2, C3, C4, and C5, customer edge nodes CE1 and CE <NUM>, secure message <NUM>, RSVP path message <NUM>, RSVP resv message <NUM>, and customer data <NUM>. For example, provider domain <NUM> and customer domain <NUM> may be switched such that customer domain <NUM> receives RSVP path message <NUM> from provider domain <NUM> and routes RSVP path message <NUM> along its third route.

Although <FIG> illustrates a particular number of provider domains <NUM>, provider nodes P1, P2, P3, P4, and P5, provider edge nodes PE1 and PE2, customer domains <NUM>, customer nodes C1, C2, C3, C4, and C5, customer edge nodes CE1 and CE <NUM>, secure messages <NUM>, RSVP path messages <NUM>, RSVP resv messages <NUM>, and customer data <NUM>, this disclosure contemplates any suitable number of provider domains <NUM>, provider nodes P1, P2, P3, P4, and P5, provider edge nodes PE1 and PE2, customer domains <NUM>, customer nodes C1, C2, C3, C4, and C5, customer edge nodes CE1 and CE <NUM>, secure messages <NUM>, RSVP path messages <NUM>, RSVP resv messages <NUM>, and customer data <NUM>. For example, provider domain <NUM> may include more or less than five provider nodes (e.g., <NUM> provider nodes) and/or two provider edge nodes. As another example, customer domain <NUM> may include more or less than five customer nodes (e.g., <NUM> customer nodes) and/or two customer edge nodes.

<FIG> illustrates an example method <NUM> for determining a secure network path within a provider network. Method <NUM> begins at step <NUM>. At step <NUM>, a provider node (e.g., PE1 of <FIG>) of a provider network (e.g., provider domain <NUM> of <FIG>) determines a path through a plurality of provider nodes (e.g., P4, P5, and PE2 of <FIG>) within the provider network. Method <NUM> then moves from step <NUM> to step <NUM>, where the provider node determines that the path through the plurality of provider nodes within the provider network is secure. For example, the provider node may receive IGP advertisements from each of the plurality of provider nodes along the path and determine a security level for each of the plurality of provider nodes from information included in the IGP advertisements. As another example, the provider node may receive security information for each of the plurality of provider nodes along the path from a provider controller (e.g., provider controller <NUM> of <FIG>) and determine a security level for each of the plurality of provider nodes from the security information. The provider node may determine that the security level of each of the plurality of provider nodes is below a predetermined security constraint value. Based on this determination, the provider node may determine that the path through the plurality of provider nodes is secure. As still another example, the provider node may receive an identity of the secure provider nodes of the provider network from the provider controller.

Method <NUM> then moves from step <NUM> to step <NUM>, where the provider node communicates its identity to a customer node of a customer network (e.g., customer domain <NUM> of <FIG>. ) The provider node may communicate its identity to the customer node using a secure message (e.g., secure message <NUM> of <FIG>. ) Method <NUM> then moves from step <NUM> to step <NUM>, where the provider node receives an RSVP path message (e.g., RSVP path message <NUM> of <FIG>) from the customer node. The RSVP path message may include an attribute for a security request that indicates to the provider node that the customer domain is requesting a secure path through the customer network to a destination node (e.g., PE2 of <FIG>). The RSVP path may also include an RRO, LSP attributes, link attributes, bandwidth constraint attributes, and the like. Method <NUM> then moves from step <NUM> to step <NUM>.

At step <NUM>, the provider node routes the RSVP path message along the path of the plurality of provider nodes. For example, the provider node may route the RSVP path message along the third path of system <NUM> of <FIG>. Method <NUM> then moves from step <NUM> back to step <NUM>, where the provider node determines whether it has received an RSVP resv message from one of the provider nodes (e.g., P4 of <FIG>) along the path. If the provider node receives an RSVP resv message from one of the provider nodes along the path, method <NUM> advances from step <NUM> to step <NUM>.

If the provider node does not receive an RSVP resv message from one or the provider nodes along the path, method <NUM> moves from step <NUM> to step <NUM>, where the provider node determines an alternate path through a plurality of alternate provider nodes within the provider network. For example, the provider node may route the RSVP path message along the first path of system <NUM> of <FIG>. Method <NUM> then moves from step <NUM> to step <NUM>, where the provider node determines whether the alternate path through the plurality of alternate provider nodes within the provider network is secure. For example, the provider node may receive IGP advertisements from each of the plurality of alternate provider nodes along the path and determine a security level for each of the plurality of alternate provider nodes from information included in the IGP advertisements. The provider node may determine that the security level of each of the plurality of alternate provider nodes is below a predetermined security constraint value. Based on this determination, the provider node may determine that the path through the plurality of alternate provider nodes is secure. As another example, the provider node may receive an identity of the secure alternate provider nodes of the provider network from a provider controller (e.g., provider controller <NUM> of <FIG>. ) Method <NUM> then moves from step <NUM> to step <NUM>.

At step <NUM>, the provider node routes the RSVP path message along the alternate path of the plurality of alternate provider nodes. For example, the provider node may route the RSVP path message along the first path of system <NUM> of <FIG>. Method <NUM> them moves from step <NUM> back to step <NUM>, where the provider node determines whether it has received an RSVP resv message from one of the alternate provider nodes (e.g., P2 of <FIG>) along the path. If the provider node receives an RSVP resv message from one of the alternate provider nodes along the path, method <NUM> advances from step <NUM> to step <NUM>. Otherwise, steps <NUM> through <NUM> are repeated until an RSVP resv message is received.

At step <NUM>, the provider node communicates that the path (or the alternate path) is secure to the customer node. For example, the provider node may forward the RSVP resv message to the customer node. Method <NUM> then moves from step <NUM> to step <NUM>, where the provider node receives customer data (e.g., customer data <NUM> of <FIG>) from the customer node. Method <NUM> then moves from step <NUM> to step <NUM>, where the provider node routes the customer data along the secure path. Method <NUM> ends at step <NUM>.

Although this disclosure describes and illustrates particular steps of method <NUM> of <FIG> as occurring in a particular order, this disclosure contemplates any suitable steps of method <NUM> of <FIG> occurring in any suitable order. For example, steps <NUM> and <NUM> directed to determining a secure path through a plurality of provider nodes within a provider network may be performed after step <NUM> directed to receiving an RSVP path message that indicates an attribute for a security request.

Although this disclosure describes and illustrates an example method <NUM> for determining a secure network path within a provider network including the particular steps of the method of <FIG>, this disclosure contemplates any suitable method <NUM> for determining a secure network path within a particular network, including any suitable steps, which may include all, some, or none of the steps of the method of <FIG>, where appropriate. For example, the terms "provider" and "customer" of method <NUM> may be interchanged such that method <NUM> is directed to determining a secure network path within the customer network.

Although this disclosure describes and illustrates particular components, devices, or systems carrying out particular steps of method <NUM> of <FIG>, this disclosure contemplates any suitable combination of any suitable components, devices, or systems carrying out any suitable steps of method <NUM> of <FIG>. For example, a provider controller (e.g., provider controller <NUM> of <FIG>) may perform one or more of the steps of method <NUM>.

<FIG> illustrates an example method <NUM> for determining a secure network path within a provider network. Method <NUM> begins at step <NUM>. At step <NUM>, a customer node (e.g., CE1 of <FIG>) of a customer network (e.g., customer domain <NUM> of <FIG>) determines a path through a plurality of customer nodes (e.g., C4, C5, and CE2 of <FIG>) within the customer network. Method <NUM> then moves from step <NUM> to step <NUM>, where the customer node determines that the path through the plurality of customer nodes within the customer network is secure. For example, the customer node may receive IGP advertisements from each of the plurality of customer nodes along the path and determine a security level for each of the plurality of customer nodes from information included in the IGP advertisements. The customer node may determine that the security level of each of the plurality of customer nodes is below a predetermined security constraint value. Based on this determination, the customer node may determine that the path through the plurality of customer nodes is secure. As another example, the customer node may receive an identity of each of the secure customer nodes of the customer network from a customer controller (e.g., customer controller <NUM> of <FIG>.

Method <NUM> then moves from step <NUM> to step <NUM>, where the customer node communicates an RSVP path message (e.g., RSVP path message <NUM> of <FIG>) to a provider node (e.g., provider edge node PE1 of <FIG>. ) The RSVP path message may include an attribute for a security request that indicates to the provider node that the customer domain is requesting a secure path through the provider network to a destination node (e.g., PE2 of <FIG>). The RSVP path may also include an RRO, LSP attributes, link attributes, bandwidth attributes, and the like. Method <NUM> then moves from step <NUM> to step <NUM>.

At step <NUM>, the customer node determines whether it has received an RSVP resv message from the provider node, which indicates that the provider node can provide a secure path through the provider network. If the customer node does not receive an RSVP resv message from the provider node, method <NUM> advances from step <NUM> to step <NUM>, where method <NUM> ends. If the customer node receives an RSVP resv message from the provider node, method <NUM> moves from step <NUM> to step <NUM>, where the customer node receives customer data (e.g., customer data <NUM> of <FIG>) along the secure path within the customer network. Method <NUM> then moves from step <NUM> to step <NUM>, where the customer node communicates the customer data to the provider node, which allows the provider node to route the customer data along a secure path within its network. Method <NUM> then moves from step <NUM> to step <NUM>, where method <NUM> ends.

Although this disclosure describes and illustrates particular steps of method <NUM> of <FIG> as occurring in a particular order, this disclosure contemplates any suitable steps of method <NUM> of <FIG> occurring in any suitable order. Moreover, although this disclosure describes and illustrates an example method <NUM> for determining a secure network path within a customer network including the particular steps of the method of <FIG>, this disclosure contemplates any suitable method <NUM> for determining a secure network path within a customer network, including any suitable steps, which may include all, some, or none of the steps of the method of <FIG>, where appropriate. Furthermore, although this disclosure describes and illustrates particular components, devices, or systems carrying out particular steps of the method of <FIG>, this disclosure contemplates any suitable combination of any suitable components, devices, or systems carrying out any suitable steps of the method of <FIG>.

<FIG> illustrates an example computer system <NUM>. In particular embodiments, one or more computer systems <NUM> perform one or more steps of one or more methods described or illustrated herein. In particular embodiments, one or more computer systems <NUM> provide functionality described or illustrated herein. In particular embodiments, software running on one or more computer systems <NUM> performs one or more steps of one or more methods described or illustrated herein or provides functionality described or illustrated herein. Particular embodiments include one or more portions of one or more computer systems <NUM>. Herein, reference to a computer system may encompass a computing device, and vice versa, where appropriate. Moreover, reference to a computer system may encompass one or more computer systems, where appropriate.

In particular embodiments, processor <NUM> includes hardware for executing instructions, such as those making up a computer program. As an example and not by way of limitation, to execute instructions, processor <NUM> may retrieve (or fetch) the instructions from an internal register, an internal cache, memory <NUM>, or storage <NUM>; decode and execute them; and then write one or more results to an internal register, an internal cache, memory <NUM>, or storage <NUM>. In particular embodiments, processor <NUM> may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor <NUM> including any suitable number of any suitable internal caches, where appropriate. As an example and not by way of limitation, processor <NUM> may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction caches may be copies of instructions in memory <NUM> or storage <NUM>, and the instruction caches may speed up retrieval of those instructions by processor <NUM>. Data in the data caches may be copies of data in memory <NUM> or storage <NUM> for instructions executing at processor <NUM> to operate on; the results of previous instructions executed at processor <NUM> for access by subsequent instructions executing at processor <NUM> or for writing to memory <NUM> or storage <NUM>; or other suitable data. The data caches may speed up read or write operations by processor <NUM>. The TLBs may speed up virtual-address translation for processor <NUM>. In particular embodiments, processor <NUM> may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates processor <NUM> including any suitable number of any suitable internal registers, where appropriate. Where appropriate, processor <NUM> may include one or more arithmetic logic units (ALUs); be a multi-core processor; or include one or more processors <NUM>. Although this disclosure describes and illustrates a particular processor, this disclosure contemplates any suitable processor.

In particular embodiments, memory <NUM> includes main memory for storing instructions for processor <NUM> to execute or data for processor <NUM> to operate on. As an example and not by way of limitation, computer system <NUM> may load instructions from storage <NUM> or another source (such as, for example, another computer system <NUM>) to memory <NUM>. Processor <NUM> may then load the instructions from memory <NUM> to an internal register or internal cache. To execute the instructions, processor <NUM> may retrieve the instructions from the internal register or internal cache and decode them. During or after execution of the instructions, processor <NUM> may write one or more results (which may be intermediate or final results) to the internal register or internal cache. Processor <NUM> may then write one or more of those results to memory <NUM>. In particular embodiments, processor <NUM> executes only instructions in one or more internal registers or internal caches or in memory <NUM> (as opposed to storage <NUM> or elsewhere) and operates only on data in one or more internal registers or internal caches or in memory <NUM> (as opposed to storage <NUM> or elsewhere). One or more memory buses (which may each include an address bus and a data bus) may couple processor <NUM> to memory <NUM>. Bus <NUM> may include one or more memory buses, as described below. In particular embodiments, one or more memory management units (MMUs) reside between processor <NUM> and memory <NUM> and facilitate accesses to memory <NUM> requested by processor <NUM>. In particular embodiments, memory <NUM> includes random access memory (RAM). This RAM may be volatile memory, where appropriate. Where appropriate, this RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, where appropriate, this RAM may be single-ported or multi-ported RAM. This disclosure contemplates any suitable RAM. Memory <NUM> may include one or more memories <NUM>, where appropriate. Although this disclosure describes and illustrates particular memory, this disclosure contemplates any suitable memory.

In particular embodiments, communication interface <NUM> includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) between computer system <NUM> and one or more other computer systems <NUM> or one or more networks. As an example and not by way of limitation, communication interface <NUM> may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. This disclosure contemplates any suitable network and any suitable communication interface <NUM> for it. As an example and not by way of limitation, computer system <NUM> may communicate with an ad hoc network, a personal area network (PAN), a LAN, a WAN, a MAN, or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. As an example, computer system <NUM> may communicate with a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WI-FI network, a WI-MAX network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network, a Long-Term Evolution (LTE) network, or a <NUM> network), or other suitable wireless network or a combination of two or more of these. Computer system <NUM> may include any suitable communication interface <NUM> for any of these networks, where appropriate. Communication interface <NUM> may include one or more communication interfaces <NUM>, where appropriate. Although this disclosure describes and illustrates a particular communication interface, this disclosure contemplates any suitable communication interface.

The scope of this disclosure is not limited to the example embodiments described or illustrated herein. Moreover, although this disclosure describes and illustrates respective embodiments herein as including particular components, elements, feature, functions, operations, or steps, any of these embodiments may include any combination or permutation of any of the components, elements, features, functions, operations, or steps described or illustrated anywhere herein that a person having ordinary skill in the art would comprehend. Furthermore, reference in the appended claims to an apparatus or system or a component of an apparatus or system being adapted to, arranged to, capable of, configured to, enabled to, operable to, or operative to perform a particular function encompasses that apparatus, system, component, whether or not it or that particular function is activated, turned on, or unlocked, as long as that apparatus, system, or component is so adapted, arranged, capable, configured, enabled, operable, or operative. Additionally, although this disclosure describes or illustrates particular embodiments as providing particular advantages, particular embodiments may provide none, some, or all of these advantages.

Claim 1:
An apparatus, comprising:
one or more processors; and
one or more computer-readable non-transitory storage media coupled to the one or more processors and comprising instructions that, when executed by the one or more processors, cause the apparatus to perform operations comprising:
determining a path through a plurality of provider nodes (<NUM>) within a provider network (<NUM>);
determining that the path through the plurality of provider nodes (<NUM>) within the provider network (<NUM>) is secure, comprising:
deriving information from each of the plurality of provider nodes (<NUM>) from at least one of the following:
interior gateway protocol, IGP, advertisements and
a provider controller (<NUM>) of the provider network (<NUM>);
determining a security level for each of the plurality of provider nodes (<NUM>) based on the derived information;
determining that the security level of each of the plurality of provider nodes (<NUM>) is below a predetermined security constraint value;
receiving, from a customer node (<NUM>), a Resource Reservation Protocol, RSVP, path message (<NUM>) comprising an attribute for a security request; and
routing the RSVP path message (<NUM>) along the path of the plurality of provider nodes (<NUM>).