Abstract: Systems, methods, and computer-readable media for assessing reliability and trustworthiness of devices operating within a network. A recipient node in a network environment can receive a neighbor discovery (ND) message from an originating node in the network environment that are both implementing a neighbor discovery protocol. Trustworthiness of the originating node can be verified by identifying a level of trust of the originating node based on attestation information for the originating node included in the ND message received at the recipient node. Connectivity with the recipient node through the network environment can be managed based on the level of trust of the originating node identified from the attestation information included in the ND message.

Abstract: This disclosure describes various methods, systems, and devices related to identifying path changes of data flows in a network. An example method includes receiving, at a node, a packet including a first value. The method further includes generating a second value by inputting the first value and one or more node details into a hash function. The method includes replacing the first value with the second value in the packet. The packet including the second value is forwarded by the node.

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

Abstract: The present technology discloses methods, systems, and non-transitory computer-readable media for receiving, by a relying node in an optical transport network environment, attestation information in a trail trace identifier of an optical unit from an attester node in the optical transport network environment; verifying a trustworthiness of the attester node by identifying a level of trust of the attester node from the attestation information; and controlling network service access of the attester node through the relying node in the network environment based on the level of trust of the attester node identified from the attestation information.

Abstract: This disclosure describes various methods, systems, and devices related to identifying path changes of data flows in a network. An example method includes receiving, at a node, a packet including a first path signature. The method further includes generating a second path signature by inputting the first path signature and one or more node details into a hash function. The method includes replacing the first path signature with the second path signature in the packet. The packet including the second path signature is forwarded by the node.

Abstract: In one embodiment, network operations are improved by performing updating operations data in an operations data field associated with the header of a particular protocol during the processing of a different protocol. A particular multiple-protocol (MP) packet is received by a particular network node in a network. The particular MP packet includes multiple protocol headers, including a first protocol header associated with a first protocol and a second protocol header associated with a second protocol. Further, the second protocol header associated with a second operations data field. During protocol processing of the first protocol on the particular MP packet, the second operations data field updated with particular operations data. The particular MP packet is sent from the particular network node, with said sent particular MP packet including said updated second operations data field with particular operations data.

Abstract: Embodiments of the disclosure pertain to activating in-band OAM based on a triggering event. Aspects of the embodiments are directed to receiving a first notification indicating a problem in a network; triggering a data-collection feature on one or more nodes in the network for subsequent packets that traverse the one or more nodes; evaluating a subsequent packet that includes data augmented by the data collection feature; and determining the problem in the network based on the data augmented to the subsequent packet.

Abstract: Disclosed is a method of establishing secure communications. The method includes receiving an attestation parameter associated with a first peer in a potential peer-to-peer communication, adding the attestation parameter to an MACsec Key Agreement (MKA) protocol key exchange, transmitting the key exchange from the first peer to a second peer in the potential peer-to-peer communication and upon a validation of the attestation parameter by the second peer, enabling secure communication between the first peer and the second peer.

Abstract: In one embodiment, nodes use in-band operations data (e.g., carried in iOAM data field(s)) to signal departures in the processing of a packet in a network. A “departure” refers to a divergence or deviation, as from an established rule, plan, or procedure. Departures include, but are not limited to, sending a packet over a backup path (thus, a departure/deviation from sending over a primary path); offload processing of a packet (thus, a departure/deviation from processing of a packet by an application processing apparatus); and exception or punting/slow/software path processing of a packet (thus, a departure/deviation from normal or fast/hardware path processing of a packet). In one embodiment, a proof of transit validation apparatus uses departure information to select among multiple possible verification secrets, with the selected verification secret used in validation processing with a cumulative secret value obtained from the packet.

Abstract: In one embodiment, in-band operations data included in packets being processed is used to signal among entities of a virtualized packet processing apparatus. Using in-band operations data provides insight on actual entities used in processing of the packet within the virtualized packet processing apparatus. The operations data in the packet is modified to signal a detected overload condition of an entity that participates in communicating the packet within the virtualized packet processing apparatus and/or applying a network service to the packet. An In-Situ Operations, Administration, and Maintenance (IOAM) header is used in one embodiment, with the IOAM header typically including a new Overload Flag to signal the detection of the overload condition. In response to the signaled overload condition, a load balancer is adjusted such that future packets are not distributed to the virtualized entity associated with the detected overload condition.

Abstract: This disclosure describes various methods, systems, and devices related to identifying path changes of data flows in a network. An example method includes receiving, at a node, a packet including a first path signature. The method further includes generating a second path signature by inputting the first path signature and one or more node details into a hash function. The method includes replacing the first path signature with the second path signature in the packet. The packet including the second path signature is forwarded by the node.

Abstract: In one embodiment, network nodes coordinate recording of In-Situ Operations, Administration, and Maintenance (IOAM) data in packets traversing the network nodes, including a node adding IOAM data of another node to packets on behalf of the another node. After receiving a particular packet, a network node adds first IOAM data and second IOAM data to the particular packet, with the first IOAM data related to the first network node and the second IOAM data related to a second network node. The packet is then sent from the first network node. The coordinated offloading of the adding of IOAM data to packets allows a node to free up resources currently used for IOAM operations to be used for other packet processing operations, while still having IOAM data related to the node recorded in packets. The coordinated offloading may include control plane communication (e.g., via a routing or other protocol).

Abstract: In one embodiment, in-band operations data (e.g., In-situ Operations, Administration, Maintenance and/or other operations data) is added to Seamless Bidirectional Forwarding (S-BFD) packets. In one embodiment, a S-BFD packet received by a node includes a BFD discriminator and operations data. Reactive processing is identified based on the BFD discriminator. The S-BFD packet and the operations data (e.g., in an operations data field in a header of the received S-BFD packet, in an IOAM Type-Length-Value (TLV), etc.) is processed according to the identified reactive function. Examples of these reactive actions include, but are not limited to, determining a result based on processing of said particular operations data by the local node or a remote analytics server, and sending a response packet including unprocessed and/or a result of the processed operations data (e.g., performance, loss, jitter, an indication of compliance with a service level agreement, and/or another data measurement or result).

Abstract: A method is provided that is performed by a network element in a network. The network element receives a packet. The network element inserts into a header of the packet, packet replication information indicating whether and to which egress interface the network element performs a replication operation on the packet, wherein the header is an In-Situ Operations, Administration and Management (IOAM) header. The network element sends the packet, with the packet replication information included in the IOAM header, in the network.

Abstract: In one embodiment, a service configured to execute on trusted participant devices authenticates network service devices each having identifying information and one or more offered services, and creates an entry into a secure digital ledger for each authenticated network service device and associated offered services, each entry based on the identifying information and the one or more offered services for a corresponding network service device. Upon receiving an advertisement for an advertised service from an advertising device attached to a given trusted participant device, the service then requests and may receive an authentic ledger entry from the secure digital ledger for the advertised service.

Abstract: In one embodiment, improved operations processing of multiple-protocol packets is performed by a node connected to a network. Received is a multiple-protocol (MP) packet that has multiple protocol headers, each having an operations data field. The operations data field of a first protocol header includes first protocol ordered operations data. Operations data is cohered from the operations data field of each of multiple protocol headers into the operations data field of a second protocol header resulting in the operations data field of the second protocol header including ordered MP operations data evidencing operations data of each of the multiple network nodes in a node traversal order taken by the MP packet among multiple network nodes. The ordered MP operations data includes said first protocol ordered operations data cohered from the operations data field of the first protocol header.

Abstract: In one embodiment, in-band operations data (e.g., In-situ Operations, Administration, Maintenance and/or other operations data) is added to Seamless Bidirectional Forwarding (S-BFD) packets. In one embodiment, a S-BFD packet received by a node includes a BFD discriminator and operations data. Reactive processing is identified based on the BFD discriminator. The S-BFD packet and the operations data (e.g., in an operations data field in a header of the received S-BFD packet, in an IOAM Type-Length-Value (TLV), etc.) is processed according to the identified reactive function. Examples of these reactive actions include, but are not limited to, determining a result based on processing of said particular operations data by the local node or a remote analytics server, and sending a response packet including unprocessed and/or a result of the processed operations data (e.g., performance, loss, jitter, an indication of compliance with a service level agreement, and/or another data measurement or result).

Abstract: Embodiments of the disclosure pertain to activating in-band OAM based on a triggering event. Aspects of the embodiments are directed to receiving a first notification indicating a problem in a network; triggering a data-collection feature on one or more nodes in the network for subsequent packets that traverse the one or more nodes; evaluating a subsequent packet that includes data augmented by the data collection feature; and determining the problem in the network based on the data augmented to the subsequent packet.

Abstract: Presented herein are techniques for monitoring packets in a container networking environment. A method includes receiving a packet at a network node, the packet having been routed to the network node in accordance with instructions from a container orchestration system, inserting an additional field in the packet that is configured to record a path of the packet within a first POD of the host device that includes at least one container, forwarding the packet to the first POD of the host device in accordance with the instructions from the container orchestration system, updating the additional field with container networking path information as the packet transits the first POD and the at least one container therein, storing the container path information in an analytics node of the network node, removing the additional field from the packet, and transmitting the packet from the network node to the network.

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