Patent Description:
The communications industry is rapidly changing to adjust to emerging technologies and ever increasing customer demand. This customer demand for new applications and increased performance of existing applications is driving communications network and system providers to employ networks and systems having greater speed and capacity (e.g., greater bandwidth). In trying to achieve these goals, a common approach taken by many communications providers is to use packet switching technology. Packets are typically forwarded in a network based on one or more values representing network nodes or paths.

A segment routing header is described in <NPL> (draft-ietf-6man-segment-routing-header-<NUM>. The routing header includes a segment list consisting of IPv6 addresses representing respective segments in the list. An optional set of Type Length Value (TLV) objects at the end of the header may include an HMAC (hash-based message authentication code) TLV.

<CIT> discloses methods for controlling packet traffic, including use of an authentication header employing a sequence number for preventing replay attacks. Use of HMAC packet integrity checks and sequence numbers is also discussed in the context of providing proof of transit in <NPL> Draft (draft-ietf-sfc-proof-of-transit-<NUM>).

Disclosed are, inter alia, methods, apparatus, and means associated with providing processing and network efficiencies in protecting Internet Protocol version <NUM> (IPv6) Segment Routing (SRv6) packets and functions using Security Segment Identifiers.

A first Segment Routing node formulates one or more Security Segment Identifiers for a secured portion of a particular Segment Routing packet, with these Security Segment Identifier(s) being included in a Segment List of the packet, which is then sent into a network.

A second Segment Routing node receives a particular Segment Routing packet. After authenticating the secured portion of the particular Segment Routing packet based on one or more Security Segment Identifiers included in a Segment List of the packet, the packet is not dropped, but is further processed typically according to a Segment Routing function. In one embodiment, the second Segment Routing node formulates one or more integrity check value(s) by security processing the secured portion of the packet (e.g., mirroring this processing by the originating node). A comparison operation is performed between a first value based on the integrity check value (possibly exactly the integrity check value) and a second value based on the Security Segment Identifier(s) (possibly exactly the Security Segment Identifiers) in the Segment List of the received packet.

The IP Destination Address of the packet (i.e., in the outer IPv6 header of the received packet) and/or a current Segment Identifier includes an identifiable anti-replay value (e.g., a sequence number or portion thereof), which is verified as appropriate (e.g., within a sliding window) as part of the authentication process of the received packet.

Each of formulating the Security Segment Identifier(s) and integrity check value(s) includes processing each value or field of the secured portion of the packet using a one-way cryptographic hash function. In one embodiment, a key that is pre-shared between the sending and second node is also input to the one-way cryptographic hash function. In one embodiment, such as, but not limited to, when a result of the hash function is greater than <NUM> bits, this result is shortened to a value that can be stored in a single Security Segment Identifier.

The secured portion of the packet includes the Destination Address and/or Source Address of the packet when said received by the second Segment Routing node; one or more Segment Identifiers (e.g., a Segment Identifier with a value of the Destination Address or a different value) in the Segments List of the packet; the Segments Left value corresponding to the Segments List; a Segment Routing Header group tag; a portion of an extended sequence number (e.g., possibly not included in the received packet but determined from the security association between the sending and second node); and/or other value(s) in the received packet (e.g., in a header or payload) or part of the security association.

Systems and apparatus for implementing the methods described herein, including network nodes, computer programs, computer program products, computer readable media and logic encoded on tangible media for implementing the methods are also described.

The appended claims set forth the features of one or more embodiments with particularity. The embodiment(s), together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which:
The appended claims set forth the features of one or more embodiments with particularity. The embodiment(s), together with its advantages, may be understood from the following detailed description taken in conjunction with the accompanying drawings of which:.

As used herein Segment Routing includes using Internet Protocol version <NUM> (IPv6) addresses as Segment Identifiers (SIDs); in other words, as used herein, Segment Routing includes IPv6 Segment Routing (SRv6). As used herein, a Segment Routing node refers to a network node (e.g., router, server, appliance) that performs Segment Routing functionality, including, but not limited to, adding, updating, or removing a Segment Routing Header; performing a Segment Routing function identified by a Segment Identifier that is the IP Destination Address of an IP packet or is a Segment Identifier in a Segment Routing Header. Also, as used herein, an IP packet may or may not be a Segment Routing Packet; but a Segment Routing packet is an IP packet.

The term "outer IP header" of a packet refers to the IP header (not an Extension header) used in processing and forwarding of the packet, and does not refer to a header of a packet encapsulated (e.g., in the payload) of the packet. The terms "Destination Address" and "Source Address" respectively refer to the value of the IP Destination and Source Address fields of the outer IP header. The phrase "wherein the value, when the particular packet was said received by the particular node, of the Destination Address" refers to the IP Destination Address of the packet when the packet was received by the particular node, which may or may not be the same as the IP Destination Address of the packet when sent from the particular node.

The terms "node" and "network node" are used herein to refer to a router or host. The term "route" is used herein to refer to a fully or partially expanded prefix/route (e.g., <NUM>. <NUM> or <NUM>. *), which is different than a "path" through the network which refers to a nexthop (e.g., next router) or complete path (e.g., traverse router A then router B, and so on). Also, the use of the term "prefix" without a qualifier herein refers to a fully or partially expanded prefix. Also, as used herein, "forwarding information" includes, but is not limited to, information describing how to process (e.g., forward, send, manipulate, modify, change, drop, copy, duplicate, receive) corresponding packets. In one embodiment, determining forwarding information is performed via an ingress lookup operation and an egress lookup operation. Also, the term "processing" when referring to processing of a packet process refers to a broad scope of operations performed in response to a packet, such as, but not limited to, forwarding/sending, dropping, manipulating/modifying/changing, receiving, duplicating, creating, applying one or more service or application functions to the packet or to the packet switching device (e.g., updating information), etc. Also, as used herein, the term processing in "parallel" is used in the general sense that at least a portion of two or more operations are performed overlapping in time.

As described herein, embodiments include various elements and limitations, with no one element or limitation contemplated as being a critical element or limitation. Each of the claims individually recites an aspect of the embodiment in its entirety. Moreover, some embodiments described may include, but are not limited to, inter alia, systems, networks, integrated circuit chips, embedded processors, ASICs, methods, and computer-readable media containing instructions. One or multiple systems, devices, components, etc., may comprise one or more embodiments, which may include some elements or limitations of a claim being performed by the same or different systems, devices, components, etc. A processing element may be a general processor, task-specific processor, a core of one or more processors, or other co-located, resource-sharing implementation for performing the corresponding processing. The embodiments described hereinafter embody various aspects and configurations, with the figures illustrating exemplary and non-limiting configurations. Computer-readable media and means for performing methods and processing block operations (e.g., a processor and memory or other apparatus configured to perform such operations) are disclosed and are in keeping with the extensible scope of the embodiments. The term "apparatus" is used consistently herein with its common definition of an appliance or device.

The steps, connections, and processing of signals and information illustrated in the figures, including, but not limited to, any block and flow diagrams and message sequence charts, may typically be performed in the same or in a different serial or parallel ordering and/or by different components and/or processes, threads, etc., and/or over different connections and be combined with other functions in other embodiments, unless this disables the embodiment or a sequence is explicitly or implicitly required (e.g., for a sequence of read the value, process said read value - the value must be obtained prior to processing it, although some of the associated processing may be performed prior to, concurrently with, and/or after the read operation). Also, nothing described or referenced in this document is admitted as prior art to this application unless explicitly so stated.

The term "one embodiment" is used herein to reference a particular embodiment, wherein each reference to "one embodiment" may refer to a different embodiment, and the use of the term repeatedly herein in describing associated features, elements and/or limitations does not establish a cumulative set of associated features, elements and/or limitations that each and every embodiment must include, although an embodiment typically may include all these features, elements and/or limitations. In addition, the terms "first," "second," etc., as well as "particular" and "specific" are typically used herein to denote different units (e.g., a first widget or operation, a second widget or operation, a particular widget or operation, a specific widget or operation). The use of these terms herein does not necessarily connote an ordering such as one unit, operation or event occurring or coming before another or another characterization, but rather provides a mechanism to distinguish between elements units. Moreover, the phrases "based on x" and "in response to x" are used to indicate a minimum set of items "x" from which something is derived or caused, wherein "x" is extensible and does not necessarily describe a complete list of items on which the operation is performed, etc. Additionally, the phrase "coupled to" is used to indicate some level of direct or indirect connection between two elements or devices, with the coupling device or devices modifying or not modifying the coupled signal or communicated information. Moreover, the term "or" is used herein to identify a selection of one or more, including all, of the conjunctive items. Additionally, the transitional term "comprising," which is synonymous with "including," "containing," or "characterized by," is inclusive or open-ended and does not exclude additional, unrecited elements or method steps. Finally, the term "particular machine," when recited in a method claim for performing steps, refers to a particular machine within the <NUM> USC § <NUM> machine statutory class.

<FIG> illustrates a network <NUM> (e.g., an aggregation of one or more networks of one or more different entities) operating according to one embodiment. As shown, network <NUM> includes client networks <NUM> and <NUM> (which are the same network in one embodiment) communicatively coupled to Segment Routing (SR) provider network <NUM>. In one embodiment, each of client networks <NUM> and <NUM> include hosts (e.g., end nodes) with upper-layer applications that communicate via network <NUM>. In one embodiment, some of the hosts in client network <NUM> and/or <NUM> are SR-capable in that they can generate and process Segment Routing packets.

In one embodiment, Segment Routing network <NUM> (e.g., a provider network) includes Segment Routing edge nodes <NUM> and <NUM>, and a network <NUM> of network nodes including SR-capable routers (and possibly some that are not SR-capable in that they do not process a Segment Routing header/complete Segment Identifier), SR gateways, service functions, and hosts (e.g., end nodes). In one embodiment, SR edge nodes <NUM> and <NUM> process packets received from networks <NUM> and <NUM>, which may include encapsulating or otherwise processing these packets into SR packets such as by adding a SR header (and possibly another IP header) to these packets according to a data plane ascertained Segment Routing policy, and subsequently decapsulating or removing a Segment Routing header (and possibly another IP header) and forwarding the native (Segment Routing or IP) packets into network <NUM> and <NUM>.

In one embodiment and in response to receiving a packet, a Segment Routing edge node <NUM>, <NUM> and/or a Segment Routing node within network <NUM> determines a Segment Routing policy (e.g., list of complete Segment Identifiers) through and/or to which to forward a Segment Routing packet encapsulating the native packet. These policies can change in response to network conditions, network programming, etc. In one embodiment, the Segment Routing policy specifies to add one or more SR headers, each with one or more Segment Identifiers, resulting in a Segment Routing packet having one or more Segment Routing headers. In one embodiment, a native packet is received without a Segment Routing header (possibly with an IP Destination Address that is a Segment Identifier/IP address of the receiving Segment Routing node), and the Segment Routing node encapsulates the native packet in a Segment Routing packet including one or more added Segment Routing headers, each including one or more Segment Identifiers. In one embodiment, a Segment Routing packet is received with a Segment Routing header, and with Segment Routing node adding one or more Segment Routing headers resulting in a Segment Routing packet including one or more added Segment Routing headers, each including one or more Segment Identifiers. In contrast, and for each of these scenarios a single Segment Routing header could have been used that includes all of the Segment Identifiers.

<FIG> illustrates a process according to one embodiment associated with providing processing and network efficiencies in protecting SRv6 packets and functions using Security Segment Identifiers. Processing begins with process block <NUM>. In process block <NUM>, routers in the networks continuously advertise and exchange routing information including Segment Routing information (e.g., routes including Segment Identifiers of network nodes and their corresponding function or function/arguments, attributes of Segment Identifiers, attributes of node) and other routing information (e.g., IPv4 or IPv6 topology information) typically via one or more routing protocols and /or other protocols. In process block <NUM>, Segment Routing and other network nodes continuously update their Segment Routing policies and routing/forwarding information as required (e.g., based on information received via a routing or other protocol, from a network management system, etc.). Processing of the flow diagram of <FIG> is complete as indicated by process block <NUM>.

<FIG> and their discussion herein provide a description of various network nodes according to one embodiment.

<FIG> illustrates one embodiment of a packet switching device <NUM> (e.g., router, node, appliance, gateway) according to one embodiment. As shown, packet switching device <NUM> includes multiple line cards <NUM> and <NUM>, each with one or more network interfaces for sending and receiving packets over communications links (e.g., possibly part of a link aggregation group), and with one or more processing elements that are used in one embodiment associated with providing processing and network efficiencies in protecting SRv6 packets and functions using Security Segment Identifiers. Packet switching device <NUM> also has a control plane with one or more processing elements (e.g., Route Processor(s)) <NUM> for managing the control plane and/or control plane processing of packets associated with providing processing and network efficiencies in protecting SRv6 packets and functions using Security Segment Identifiers. Packet switching device <NUM> also includes other cards <NUM> (e.g., service cards, blades) which include processing elements that are used in one embodiment to process (e.g., forward/send, drop, manipulate, change, modify, receive, create, duplicate, perform SR functionality possibly with shared memory with one or more service functions, apply a service according to one or more service functions) packets associated with providing processing and network efficiencies in protecting SRv6 packets and functions using Security Segment Identifiers, and some hardware-based communication mechanism <NUM> (e.g., bus, switching fabric, and/or matrix, etc.) for allowing its different entities <NUM>, <NUM>, <NUM> and <NUM> to communicate. Line cards <NUM> and <NUM> typically perform the actions of being both an ingress and egress line card, in regards to multiple other particular packets and/or packet streams being received by, or sent from, packet switching device <NUM>. In one embodiment, Segment Routing functions are implemented on line cards <NUM>, <NUM>.

<FIG> is a block diagram of an apparatus <NUM> (e.g., host, router, node, destination, or portion thereof) used in one embodiment associated with providing processing and network efficiencies in protecting SRv6 packets and functions using Security Segment Identifiers. In one embodiment, apparatus <NUM> performs one or more processes, or portions thereof, corresponding to one of the flow diagrams illustrated or otherwise described herein, and/or illustrated in another diagram or otherwise described herein.

In one embodiment, apparatus <NUM> includes one or more processor(s) <NUM> (typically with on-chip memory), memory <NUM> (possibly shared memory), storage device(s) <NUM>, specialized component(s) <NUM> (e.g. optimized hardware such as for performing lookup, packet processing (including Segment Routing processing) and/or service function operations; associative memory; binary and/or ternary content-addressable memory; Application Specific Integrated Circuit(s), cryptographic hash hardware, etc.), and interface(s) <NUM> for communicating information (e.g., sending and receiving packets, user-interfaces, displaying information, etc.), which are typically communicatively coupled via one or more communications mechanisms <NUM> (e.g., bus, links, switching fabric, matrix), with the communications paths typically tailored to meet the needs of a particular application.

Various embodiments of apparatus <NUM> may include more or fewer elements. The operation of apparatus <NUM> is typically controlled by processor(s) <NUM> using memory <NUM> and storage device(s) <NUM> to perform one or more tasks or processes. Memory <NUM> is one type of computer-readable/computer-storage medium, and typically comprises random access memory (RAM), read only memory (ROM), flash memory, integrated circuits, and/or other memory components. Memory <NUM> typically stores computer-executable instructions to be executed by processor(s) <NUM> and/or data which is manipulated by processor(s) <NUM> for implementing functionality in accordance with an embodiment. Storage device(s) <NUM> are another type of computer-readable medium, and typically comprise solid state storage media, disk drives, diskettes, networked services, tape drives, and other storage devices. Storage device(s) <NUM> typically store computer-executable instructions to be executed by processor(s) <NUM> and/or data which is manipulated by processor(s) <NUM> for implementing functionality in accordance with an embodiment.

<FIG> illustrates a Segment Identifier <NUM> according to one embodiment. As shown, Segment Identifier <NUM> includes locator <NUM> that is typically unique to a node; function <NUM> that identifies a Segment Routing function (e.g., a secured or non-secured function); and argument <NUM> (e.g., an anti-replay value or parameter for the function). The /<NUM>, /<NUM>, /<NUM> or other portion of Segment Identifier <NUM> is advertised as an address of a network node, with Segment Identifier <NUM> also being used as the Destination Address of a Segment Routing packet to steer the packet to that node. In one embodiment, the advertisement of Segment Identifier <NUM> excludes the argument <NUM> portion, as it varies typically on a per-sequential packet basis, such as for, but not limited to, providing an anti-replay value (e.g., sequence number) for use by the receiving Segment Routing node.

<FIG> illustrates a Security Segment Identifier <NUM> according to one embodiment wherein it is a value (e.g., <NUM> bits) that can fit in one or more Segment Identifiers in a Segment List of a Segment Routing packet.

<FIG> illustrates a SRv6 packet <NUM> according to one embodiment. As shown, SRv6 packet <NUM> includes an outer IPv6 header <NUM> that includes a Source Address and a Destination Address (and other values), Segment Routing header <NUM> (e.g., that includes a Segment List with one or more Security Segment Identifiers and/or other Segment Identifiers, a Segments Left value, group tag and other fields/values); optional additional extension headers <NUM> (that may include another Segment Routing header); and payload <NUM> (possibly including an encapsulated original packet).

One embodiment improves processing and network efficiencies by using the Segment List of a Segment Routing Header to store Security Segment Identifiers, albeit in violation of standardized Segment Routing requirements. The Security Segment Identifier is included not for being an address of a network node (e.g., and identifying a Segment Routing function), but rather is a security authentication value formulated based on portions of the Segment Routing packet (e.g., Destination Address and/or Segment Identifier including the anti-replay value) and typically other values (e.g., a pre-shared key).

In one embodiment, one or more Security Segment Identifiers are used to authenticate a packet, as well as protect a Segment Routing function from being invoked for a non-authenticated packet. In one embodiment, one or more Security Segment Identifiers are used to only protect a single Segment Routing function and therefore only that corresponding network node performs the authentication, and not all Segment Routing nodes that the Segment Routing packet may traverse. Also in one embodiment, one or more Security Segment Identifiers are used in authentication of the packet including the Source Address and/or Destination Address which may vary as the packet traverses the network. Typically, the creator of the Security Segment Identifier(s) that protect these values does so with their values when received by the second Segment Routing node, and not when sent from the originating Segment Routing node.

<FIG> illustrates a process according to one embodiment. Processing begins with process block <NUM>. In process block <NUM>, segment routing nodes (e.g., routers) in the segment routing networks establish security associations with other routers in order to send secured Segment Routing packets. In one embodiment, a security association is between two Segment Routing nodes, thus, each network node does not require the same pre-shared key. In one embodiment, a security association is a one-to-many or many-to-many relationship among Segment Routing nodes.

In one embodiment, these security associations are exchanged using a routing or other protocol, using a network management or operating system or path computation engine, or via another manner. This security association typically includes defining a private pre-share key for use between a sending node and a particular segment routing security function on a remote node, as well as other security parameters such as, but not limited to the size of a Security Segment Identifier (e.g., number of Segment Identifiers in the Segment List); whether to provide anti-replay protection, and if so, possibly a range for sequence numbers; what fields/values from the packet are included in the protected portion (e.g., Source Address, Destination Address, Segments Left, group tag, Segment Identifiers protected); other values (e.g., whether to use an extended sequence number); and the granularity of the security association (e.g., used for all packets between the two nodes, only for a particular flow). These security associations are updated (e.g., added, removed, modified) as needed. Processing of the flow diagram of <FIG> is complete as indicated by process block <NUM>.

<FIG> illustrates a process according to one embodiment. Processing begins with process block <NUM>. In process block <NUM> for a received or generated packet, a first segment routing node identifies a Segment Routing policy that includes steering the packet to a secured Segment Routing function of a remote segment routing node according to an established security association between the first and remote Segment Routing nodes. Processing continues to process block <NUM>.

In one embodiment, the security association defines how the one or more Security Segment Identifiers will be formulated, including what cryptographic hashing (e.g. Secure Hash Algorithm <NUM> / SHA-<NUM>) or other authentication function will be used, the values on which be used in formulating the Security Segment Identifier(s). In one embodiment, these values include, but are not limited to:.

In one embodiment, a <NUM>-bit value is formulated that is communicated in two Security Segment Identifiers in a Segment List of a packet. One embodiment formulates a single Security Segment Identifier by extracting <NUM> or fewer bits from a cryptographic hashing result (e.g., a <NUM>-bit value generated by SHA-<NUM>).

In one embodiment, the security association designates to include an anti-replay value (e.g., a sequence number from a sliding window) in the Destination Address and/or the current Segment Identifier in the Segments List of the receiving Segment Routing node. In one embodiment, each of the sending and receiving Segment Routing nodes maintains an extended sixty-four bit sequence number, but only communicates the low-order thirty-two bits of an extended sixty-four bit sequence number in the argument/low-order bits of the Destination Address and/or current Segment Identifier. To provide protection of this anti-replay value, it is typically included in the formulation of the Security Segment Identifier(s), such as, but not limited to, directly or as a portion of the Destination Address and/or current Segment Identifier.

The security Segment Identifier is added to a Segment List of the packet along with updating other fields of the Segment Routing Packet.

As determined in process block <NUM>, if there are additional secured functions to be traversed by the packet, then processing returns to process block <NUM> to process accordingly; otherwise processing proceeds to process block <NUM>. For example, a segment routing policy may steer a packet through two or more secure Segment Routing functions, each protected by a different one or more Security Segment Identifiers (even with a first of the Security Segment Identifier(s) formulated based on a second of the Security Segment Identifier(s), and possibly formulated based on different Source and Destination Addresses, different Segments Left values, an added Segment Routing Policy by an intervening Segment Routing node, etc. One embodiment generates correct Security Segment Identifiers for these and other scenarios.

Continuing with process block <NUM>, the secured Segment Routing packet is sent into the network, and processing of the flow diagram of <FIG> is complete as indicated by process block <NUM>.

<FIG> illustrates a process according to one embodiment. Processing begins with process block <NUM>. In process block <NUM>, a Segment Routing node (e.g., router) receives the protected Segment Routing packet, and operates according to secured Segment Routing function identified by the Destination Address (and typically by the current Segment Identifier in a Segment List).

As determined in process block <NUM>, if Segments Left is zero (then the Security Segment Identifier is not present), then processing proceeds to process block <NUM>; otherwise processing continues to process block <NUM>.

As determined in process block <NUM>, if anti-replay is to be invoked per the corresponding Security Association, then processing proceeds to process block <NUM>; otherwise, processing proceeds directly to process block <NUM>.

As determined in process block <NUM>, if the sequence number (e.g., in the low-order bits / argument of the current Segment Identifier or the Destination address) is proper for the packet (e.g., within a current sliding window or other expected value), then processing proceeds to process block <NUM>; otherwise processing proceeds to process block <NUM>.

Continuing in process block <NUM>, the node formulates one or more integrity check values according to the Security Association (e.g., typically the same processing performed by the originating node in process block <NUM> of <FIG>). As determined in process block <NUM>, if the integrity check value(s) are correct per the Security Segment Identifier(s) in the Segment List of the received packet, then processing proceeds to process block <NUM>; otherwise processing proceeds to process block <NUM>. Typically, these two formulated values will be the same, but in one embodiment, some additional manipulation is performed.

Continuing with process block <NUM>, the Segments Left value is decremented past the corresponding one or more Security Identifiers. Then as determined in process block <NUM>, if anti-replay is to be invoked per the corresponding Security Association, then processing proceeds to process block <NUM>; otherwise, processing proceeds directly to process block <NUM>. One embodiment performs this anti-replay check twice, inter alia, to ensure that multiple packets with a same sequence number are not processed overlapping in time.

Continuing with process block <NUM>, if the sequence number (e.g., in the low-order bits / argument of the current Segment Identifier or the Destination address) is proper for the packet (e.g., within a current sliding window or other expected value), then processing proceeds to process block <NUM>; otherwise processing proceeds to process block <NUM>. In process block <NUM>, the local sequence number tracking for the Security Association is updated to reflect that the sequence number was used (so another packet cannot use it, at least until a possible wrap-around of sequence numbers). Processing continues with process block <NUM>.

Continuing with process block <NUM>, the packet has been authenticated (e.g., origin authenticated, integrity of the segments protected, anti-replay protection) in a manner to allow further processing of the packet, typically by another Segment Routing function that was protected from execution unless the packet was authenticated. Processing proceeds to process block <NUM>.

Continuing with process block <NUM>, the packet is dropped as it was not authenticated and/or other error processing is performed. Processing proceeds to process block <NUM>.

Processing of the flow diagram of <FIG> is completed as indicated by process block <NUM>.

<FIG> illustrates a network <NUM> operating according to one embodiment.

Network <NUM> includes client network <NUM> (with source node <NUM> having an IPv6 address of A::) and client network <NUM> (with destination node <NUM> having an IPv6 address of B::).

Network <NUM> also includes provider network <NUM>, that includes provider nodes <NUM>-<NUM> (e.g., Segment Routing routers):.

Each Router <NUM>-<NUM> typically advertises all of their IP addresses using a routing or other protocol. Note, each of IPv6 addresses C2::<NUM>, C2::<NUM>; C3::<NUM>, and E4::<NUM> include a specification of a secured Segment Routing function that in one embodiment, operates according to the flow diagram of <FIG>.

<FIG> also shows the progression through network <NUM> of a same IP packet (denoted <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> for ease of communicating its current position in network <NUM>). Each of <FIG> illustrated different scenarios associated with this IP packet (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) traversing network <NUM> according to one embodiment that provides processing and network efficiencies in protecting Internet Protocol version <NUM> (IPv6) Segment Routing (SRv6) packets and functions using Security Segment Identifiers.

Each of <FIG> illustrate, according to one embodiment, processing of a packet as it is steered through network <NUM> as illustrated in <FIG>. These embodiments are illustrative of only some of an unlimited number of different processing that is performed by one or more Segment Routing nodes in accordance with one embodiment. In one embodiment, this processing includes that described in relation to <FIG> and/or <FIG>.

<FIG> illustrates an IP packet <NUM> being encapsulated and forwarded through network <NUM> according to a secure Segment Routing policy of one embodiment, with a Security Association having been established between Segment Routing nodes <NUM> and <NUM> for being authenticated by a secured Segment Routing function identified by C2::C3, with anti-replay protection enabled, and using a single Security Segment Identifier.

Network node <NUM> receives packet <NUM> and generates secure Segment Routing packet <NUM> which includes original packet <NUM> encapsulated therein. Segment Routing packet <NUM> has a Source Address of node <NUM>, a Destination Address (same value as Segment Identifier <NUM>) of a secured Segment Routing function of node <NUM>. Segment Routing Header includes the three Segment Identifiers <NUM>-<NUM>, Segments Left <NUM> having a value of two as Segment Identifier <NUM> is the current Segment Identifier (and the same as the Destination Address of packet <NUM>). Note, the argument portion of Segment Identifier <NUM> (and low-order bits of the Destination Address) includes an anti-replay sequence number value of <NUM>. Node <NUM> formulates security Segment Identifier <NUM> according to the established Security Association. In one embodiment, a one-way cryptographic hash function is performed on at least the secured portion of packet <NUM> in formulating the value of Security Segment Identifier <NUM>, typically using a pre-shared key that is part of the security association. Security Segment Identifier <NUM> is inserted in a Segment List of a Segment Routing Header of packet <NUM>. In one embodiment, the secured portion includes the Destination Address of packet <NUM> and/or the current Segment Identifier <NUM> (that includes at least a portion of the anti-replay value so that it is secured). In one embodiment, the secured portion includes the Source Address of packet <NUM>, the Destination Address of packet <NUM>, the current Segment Identifier <NUM>, Segments Left <NUM>, Segment Identifier <NUM>, and/or other values (e.g., from packet <NUM>, part of the security association such as, but not limited to, an extended sequence number), and/or otherwise described herein. Node <NUM> sends packet <NUM>, including Security Segment Identifier <NUM>, into network <NUM>.

Network node <NUM> receives packet <NUM>, which has a Destination Address that is an address of node <NUM>. Security authentication processing is performed according to the secured Segment Routing function identified by C2::C3 and according to the corresponding security association. In one embodiment, this authentication processing includes verifying that the sequence number is correct (and only used once) such as using a sliding window technique, and typically repeating the processing performed by node <NUM> by using the same one-way cryptographic hash function processing on the same values from packet <NUM> and that are part of the security association (e.g., the pre-shared key) to generated an integrity check value. The packet is authenticated based on the integrity check value and Security Segment Identifiers <NUM>, such as by, but not limited to a direct comparison, or possibly after some manipulation of one or both of these values (e.g., multiply each by two and compare those values). In response to authentication, packet <NUM> is further processed (e.g., not dropped) such as, but not limited to, according to another Segment Routing function invoked by the secured Segment Routing function identified by C2::C3.

Segments Left <NUM> of packet <NUM> is updated (to zero), as reflected in Segments Left <NUM> of packet <NUM>, by being reduced by two to advance past both current Segment Identifier <NUM> and Security Segment Identifier <NUM> of packet <NUM>, with the Destination Address of packet <NUM> being set to the Segment Identifier in the Segment List identified by the value of Segments Left <NUM> (i.e., value of zero). Packet <NUM> is sent from node <NUM>.

Node <NUM> of network <NUM> receives packet <NUM>, which is not addressed to node <NUM>, thus is forwarded back into network <NUM> as denoted packet <NUM>.

In response to receiving packet <NUM>, node <NUM> operates according to the Segment Routing function identified by E4::<NUM> to decapsulate and send IP packet <NUM> to client network <NUM>. In one embodiment, even though received packet <NUM> includes the Security Segment Identifier, node <NUM> does not perform authentication processing based thereon; rather, node <NUM> simply ignores the Security Segment Identifier.

<FIG> illustrates an IPv6 packet <NUM> being modified to add a Segment Routing Header and forwarded through network <NUM> according to a secure Segment Routing policy of one embodiment, with a Security Association having been established between Segment Routing nodes <NUM> and <NUM> for being authenticated by a secured Segment Routing function identified by C2::C3, with anti-replay protection enabled, and using a single Security Segment Identifier.

This network processing is very similar to that described in relation to <FIG> (or otherwise described herein), so the full description will not be repeated. <FIG> illustrates packet encapsulation with the use of a Security Segment identifier, while <FIG> illustrates adding a Segment Routing Header with the use of a Security Segment identifier.

Network node <NUM> receives packet <NUM> and generates secure Segment Routing packet <NUM> which includes original packet <NUM> with a Segment Routing Header added thereto. The Segment List includes a fourth Segment Identifier <NUM>, which is the Destination Address of received packet <NUM>, with Segments Left <NUM> set to three. The Destination Address of packet <NUM> is set to the first Segment Identifier <NUM>. Note, the argument portion of Segment Identifier <NUM> (and low-order bits of the Destination Address) includes an anti-replay sequence number value of <NUM>. Node <NUM> formulates security Segment Identifier <NUM> according to the established Security Association. In one embodiment, the protected portion also includes Segment Identifier <NUM>. Node <NUM> sends packet <NUM>, including Security Segment Identifier <NUM>, into network <NUM>.

Network node <NUM> receives packet <NUM>, which has a Destination Address that is an address of node <NUM>. Security authentication processing is performed according to the secured Segment Routing function identified by C2::C3 and according to the corresponding security association. In response to authentication, packet <NUM> is further processed (e.g., not dropped) such as, but not limited to, according to another Segment Routing function invoked by the secured Segment Routing function identified by C2::C3.

Segments Left <NUM> of packet <NUM> is updated (to one), as reflected as Segments Left <NUM> of packet <NUM>, by being reduced by two to advance past both current Segment Identifier <NUM> and Security Segment Identifier <NUM> of packet <NUM>, with the Destination Address of packet <NUM> being set to the Segment Identifier in the Segment List identified by the value of Segments Left <NUM> (i.e., value of one). Packet <NUM> is sent from node <NUM>.

In response to receiving packet <NUM>, node <NUM> operates according to the Segment Routing function identified by E4::<NUM> to decapsulate and send IP packet <NUM> to client network <NUM> (with a Destination Address of Segment Identifier <NUM> of received packet <NUM>). In one embodiment, even though received packet <NUM> includes the Security Segment Identifier, node <NUM> does not perform authentication processing based thereon; rather, node <NUM> simply ignores the Security Segment Identifier.

<FIG> illustrates an IP packet <NUM> being encapsulated and forwarded through network <NUM> according to a secure Segment Routing policy of one embodiment, with a Security Association having been established between Segment Routing nodes <NUM> and <NUM> for being authenticated by a secured Segment Routing function identified by C2::C8, with anti-replay protection enabled, and using a two Security Segment Identifiers (e.g., an integrity check value of up to <NUM> bits).

This network processing is very similar to that described in relation to <FIG> that uses an integrity check value contained in only one, not two, Security Segment Identifiers (or otherwise described herein), so the full description will not be repeated.

Network node <NUM> receives packet <NUM> and generates secure Segment Routing packet <NUM> which includes original packet <NUM> encapsulated therein. Segment Routing packet <NUM> has a Source Address of node <NUM>, a Destination Address (same value as Segment Identifier <NUM>) of a secured Segment Routing function of node <NUM>. Segment Routing Header includes the four Segment Identifiers <NUM>-<NUM>, Segments Left <NUM> having a value of three as Segment Identifier <NUM> is the current Segment Identifier (and the same as the Destination Address of packet <NUM>). Note, the argument portion of Segment Identifier <NUM> (and low-order bits of the Destination Address) includes an anti-replay sequence number value of <NUM>. Node <NUM> formulates security Segment Identifiers <NUM>-<NUM> according to the established Security Association. Node <NUM> sends packet <NUM>, including Security Segment Identifiers <NUM>-<NUM>, into network <NUM>.

Network node <NUM> receives packet <NUM>, which has a Destination Address that is an address of node <NUM>. Security authentication processing is performed according to the secured Segment Routing function identified by C2::C8 and according to the corresponding security association. In response to authentication, packet <NUM> is further processed (e.g., not dropped) such as, but not limited to, according to another Segment Routing function invoked by the secured Segment Routing function identified by C2::C8.

Segments Left <NUM> of packet <NUM> is updated (to zero), as reflected as Segments Left <NUM> of packet <NUM>, by being reduced by three to advance past current Segment Identifier <NUM> and the two Security Segment Identifiers <NUM> and <NUM> of packet <NUM>, with the Destination Address of packet <NUM> being set to the Segment Identifier in the Segment List identified by the value of Segments Left <NUM> (i.e., value of zero). Packet <NUM> is sent from node <NUM>.

<FIG> illustrates an IP packet <NUM> being encapsulated and forwarded through network <NUM> according to a secure Segment Routing policy of one embodiment, with.

This network processing is very similar to that described in relation to <FIG> that uses a secured Segment routing function on one, not two nodes (or otherwise described herein), so the full description will not be repeated.

Network node <NUM> receives packet <NUM> and generates secure Segment Routing packet <NUM> which includes original packet <NUM> encapsulated therein. Segment Routing packet <NUM> has a Source Address of node <NUM>, a Destination Address <NUM> (same value as Segment Identifier <NUM>) of a secured Segment Routing function of node <NUM>. Segment Routing Header includes the five Segment Identifiers <NUM>-<NUM>, Segments Left <NUM> having a value of four as Segment Identifier <NUM> is the current Segment Identifier (and the same as the Destination Address of packet <NUM>). Note, the argument portion of Segment Identifier <NUM> (and low-order bits of the Destination Address <NUM>) includes an anti-replay sequence number value of <NUM>; while the argument portion of Segment Identifier <NUM> include an anti-replay sequence number value of <NUM>.

Node <NUM> formulates security Segment Identifiers <NUM> and <NUM> according to the their respective established Security Association. In one embodiment, a secured portion for the calculation of either security Segment Identifiers <NUM> or <NUM> includes the value of the other security Segment Identifiers <NUM> or <NUM>.

In one embodiment, the secured portion of packet <NUM> includes its Destination Address <NUM>, which is a different value than Destination Address <NUM> of packet <NUM> sent from node <NUM>. Therefore, node <NUM>, in formulating the value of Security Segment Identifier <NUM>, uses the Destination Address <NUM> of packet <NUM> that will be received by node <NUM>. Similarly, in one embodiment, the secured portion of packet <NUM> includes Segments Left <NUM>. Therefore, node <NUM>, in formulating the value of Security Segment Identifier <NUM>, uses the value (two) of Segments Left <NUM> of packet <NUM>.

Node <NUM> sends packet <NUM>, including Security Segment Identifiers <NUM> and <NUM>, into network <NUM>.

Segments Left <NUM> of packet <NUM> is updated (to two) by being reduced by two to advance past current Segment Identifier <NUM> and first Security Segment Identifier <NUM>, with Destination Address <NUM> of packet <NUM> being set to the Segment Identifier in the Segment List identified by the value of Segments Left <NUM> (i.e., value of two). Packet <NUM> is sent from node <NUM>.

Network node <NUM> receives packet <NUM>, which has a Destination Address that is an address of node <NUM>. Security authentication processing is performed according to the secured Segment Routing function identified by C3::C7 and according to the corresponding security association. In response to authentication, packet <NUM> is further processed (e.g., not dropped) such as, but not limited to, according to another Segment Routing function invoked by the secured Segment Routing function identified by C3::C7.

Segments Left <NUM> of packet <NUM> is updated (to zero) by being reduced by two to advance past current Segment Identifier <NUM> and second Security Segment Identifier <NUM>, with Destination Address <NUM> of packet <NUM> being set to the Segment Identifier in the Segment List identified by the value of Segments Left <NUM> (i.e., value of zero). Packet <NUM> is sent from node <NUM>.

In response to receiving packet <NUM>, node <NUM> operates according to the Segment Routing function identified by E4::<NUM> to decapsulate and send IP packet <NUM> to client network <NUM>. In one embodiment, even though received packet <NUM> includes the two Security Segment Identifiers, node <NUM> does not perform authentication processing based thereon; rather, node <NUM> simply ignores the Security Segment Identifiers.

<FIG> illustrates an IP packet <NUM> being encapsulated and forwarded through network <NUM> according to a secure Segment Routing policy of one embodiment, with a Security Association having been established between Segment Routing nodes <NUM> and <NUM> (i.e., not directly connected Segment Routing node <NUM>) for being authenticated by a secured Segment Routing function identified by C3:<NUM>, with anti-replay protection enabled, and using a single Security Segment Identifier.

This network processing is very similar to that described in relation to <FIG> and <FIG> (or otherwise described herein), so the full description will not be repeated.

Network node <NUM> receives packet <NUM> and generates secure Segment Routing packet <NUM> which includes original packet <NUM> encapsulated therein. Segment Routing packet <NUM> has a Source Address of node <NUM>, a Destination Address <NUM> (same value as Segment Identifier <NUM>) of a non-secured Segment Routing function of node <NUM>. The Segment List of packet <NUM> includes four Segment Identifiers <NUM>-<NUM>, including Security Segment Identifier <NUM>. Segments Left <NUM> is set to three. The argument portion of Segment Identifier <NUM> includes an anti-replay sequence number value of <NUM>.

Node <NUM> formulates security Segment Identifier <NUM> according to the established Security Association. In one embodiment, the secured portion of packet <NUM> includes its Destination Address <NUM> and Segments Left <NUM>, which are different values in packet <NUM> sent from node <NUM> and packet <NUM> received by node <NUM>. Therefore, node <NUM>, in formulating the value of Security Segment Identifier <NUM>, uses the Destination Address <NUM> and Segments Left <NUM> of packet <NUM>, not of packet <NUM>.

Node <NUM> sends packet <NUM>, including Security Segment Identifier <NUM>, into network <NUM>.

Network node <NUM> receives packet <NUM>, which has a Destination Address that is an address of node <NUM>, which performs Segment Routing processing (including reducing Segments Left <NUM> by one and updating Destination Address <NUM>). Resulting packet <NUM> is sent into network <NUM>.

In response to receiving packet <NUM>, node <NUM> operates according to the Segment Routing function identified by E4::<NUM> to decapsulate and send IP packet <NUM> to client network <NUM>. In one embodiment, even though received packet <NUM> includes the Security Segment Identifier <NUM>, node <NUM> does not perform authentication processing based thereon; rather, node <NUM> simply ignores Security Segment Identifier <NUM>.

In summary, in one embodiment, a Segment Routing network node provides processing and network efficiencies in protecting Internet Protocol version <NUM> (IPv6) Segment Routing (SRv6) packets and functions using Security Segment Identifiers, which are included in Segment Lists of a Segment Routing Header of a SRv6 packet. The Security Segment Identifier provides, inter alia, origin authentication, integrity of information in one or more headers of the packet, and/or anti-replay protection. In one embodiment, a Security Segment Identifier includes a value determined based on a secured portion of the packet. A typically secured portion includes the Source and Destination Addresses, one or more Segment Identifiers in a Segment List and the Segments Left value. In one embodiment, the Destination Address and/or a Segment Identifier in the Segment List includes and an anti-replay value (e.g., sequence number or portion thereof) which is also in the secured portion of the packet.

Claim 1:
A method, comprising:
receiving, by a Segment Routing node (<NUM>), a protected Segment Routing packet (<NUM>) via a network (<NUM>), with said protected Segment Routing packet including:
a Segment Routing Header (<NUM>) comprising a Segment List with a plurality of segment identifiers (<NUM>-<NUM>), including a Security Segment Identifier (<NUM>) for a secured portion of the protected Segment Routing packet, and a Segments Left value (<NUM>) indicating a current segment identifier (<NUM>), wherein the Security Segment Identifier comprises a value based on processing the secured portion using a one-way cryptographic hash function; and
an outer Internet Protocol version <NUM>, IPv6, header (<NUM>) comprising a Destination Address of the Segment Routing node;
authenticating, by the Segment Routing node, the secured portion of the protected Segment Routing packet, with said authenticating including security processing the secured portion to generate an integrity check value, and performing a comparison operation between a first value based on the integrity check value and a second value based on the Security Segment Identifier in the Segment List of the protected Segment Routing packet; and
in response to said authenticating confirming the integrity of the secured portion, further processing the protected Segment Routing packet, the processing comprising:
reducing the Segments Left value to advance past the current segment identifier and the Security Segment Identifier; and
sending the protected Segment Routing packet into the network;
wherein the secured portion includes the value of the Destination Address of the protected Segment Routing packet when received by the Segment Routing node.