WO2025054634A2 - Mechanism for achieving authentication and integrity verification with selective packets or flows - Google Patents

Abstract

A method including receiving an authentication policy from a controller of a network. The authentication policy provides packet authentication selection criteria for selecting specific flows or a set of packets of one flow for packet header authentication generating a packet comprising a packet payload and an encapsulation header encapsulating the packet payload, determining whether the packet is part of the specific flows or the set of packets based on the authentication policy, computing an authentication value for the packet for authenticating the packet when the packet is part of the specific flows or the set of packets, and encoding authentication information in the encapsulation header. The authentication information comprises the authentication value in an authentication value field when the packet is part of the specific flows or the set of packets. The method further includes transmitting the packet.

Description

MECHANISM FOR ACHIEVING AUTHENTICATION AND INTEGRITY

VERIFICATION WITH SELECTIVE PACKETS OR FLOWS

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application No. 63/651,496 filed on May 24, 2024. The disclosure of the aforementioned application is hereby incorporated by reference in its entirety.

BACKGROUND

[0002] Packet authentication is a process of verifying the integrity and authenticity of data packets in a network to ensure the packets have not been tampered with and are from a legitimate source. Packet authentication helps maintain network security by preventing unauthorized users from injecting malicious packets or modifying data packets while in transit. Packet authentication is critical in defending against attacks like man-in-the-middle, replay, denial-of- service (DoS), and injection attacks.

[0003] There are many scenarios in which additional packet headers may be added to a packet. For example, a Generic Network Virtualization Encapsulation (GENEVE) header may be added to a packet with an encrypted payload to steer the packet through one or more underlay networks to optimize packet forwarding. However, because the information carried in these additional headers is not encrypted, authenticating the additional headers is crucial for preventing malicious actors from tampering with header information.

SUMMARY

[0004] A first aspect relates to a method implemented by a controller to provide packet authentication selection criteria for selecting specific flows or a set of packets of one flow for packet header authentication. The method includes establishing control plane sessions with a plurality of devices; determining an authentication policy, wherein the authentication policy provides packet authentication selection criteria for selecting specific flows or a set of packets of one flow for packet header authentication; and sending the authentication policy over control plane sessions to the plurality of devices.

[0005] Optionally, in a first implementation according to the first aspect, the packet authentication selection criteria adjust a frequency of packets from the specific flows or in the set of packets that are selected for packet header authentication based on current network security conditions.

[0006] Optionally, in a second implementation according to the first aspect or any implementation thereof, the packet authentication selection criteria comprise a flow identifier (ID). [0007] Optionally, in a third implementation according to the first aspect or any implementation thereof, the method further includes determining a set of authentication keys associated with the authentication policy; and sending the set of authentication keys over the control plane sessions to at least two devices in the plurality of devices.

[0008] Optionally, in a fourth implementation according to the first aspect or any implementation thereof, the packet authentication selection criteria adjust a frequency of packets from the specific flows or in the set of packets that are selected for packet header authentication based on a network segment traversed by the packets.

[0009] A second aspect relates to a method implemented by a sending device to provide packet authentication selection criteria for selecting specific flows or a set of packets of one flow for packet header authentication. The method includes receiving an authentication policy from a controller of a network, wherein the authentication policy provides packet authentication selection criteria for selecting specific flows or a set of packets of one flow for packet header authentication; generating a packet comprising a packet payload and an encapsulation header encapsulating the packet payload; determining whether the packet is part of the specific flows or the set of packets based on the authentication policy; computing an authentication value for the packet for authenticating the packet when the packet is part of the specific flows or the set of packets; encoding authentication information in the encapsulation header, wherein the authentication information comprises the authentication value in an authentication value field when the packet is part of the specific flows or the set of packets, and wherein the authentication information comprises an obscure value in the authentication value field when the packet is not part of the specific flows or the set of packets; and transmitting the packet.

[0010] Optionally, in a first implementation according to the second aspect, the obscure value is randomly generated.

[0011] Optionally, in a second implementation according to the second aspect or any implementation thereof, the method further includes encrypting the packet payload.

[0012] Optionally, in a third implementation according to the second aspect or any implementation thereof, the authentication information is encoded in a hash-based message authentication code (HMAC) Sub-Type-Length- Value (TLV), and wherein the authentication value field carries a HMAC authentication value.

[0013] Optionally, in a fourth implementation according to the second aspect or any implementation thereof, the authentication information is encoded in a digital signature sub-TLV, and wherein the authentication value field carries a digital signature value.

[0014] Optionally, in a fifth implementation according to the second aspect or any implementation thereof, the method further includes receiving a set of authentication keys associated with the authentication policy; and determining the authentication value based on an authentication key in the set of authentication keys.

[0015] Optionally, in a sixth implementation according to the second aspect or any implementation thereof, the method further includes rotating the authentication key that is used in the set of authentication keys in determining the authentication value.

[0016] Optionally, in a seventh implementation according to the second aspect or any implementation thereof, the authentication information comprises an index of the authentication key in the set of authentication keys that is used in determining the authentication value.

[0017] Optionally, in an eighth implementation according to the second aspect or any implementation thereof, the encapsulation header is a Generic Network Virtualization Encapsulation (GENEVE) header, a Segment Routing over Internet Protocol (IP) version 6 (SRv6) header, or an Internet Protocol (IP) in IP (IPinIP) header.

[0018] Optionally, in a ninth implementation according to a third aspect or any implementation thereof, the packet authentication selection criteria adjusts a frequency of packets from the specific flows or in the set of packets that are selected for packet header authentication based on current network security conditions.

[0019] Optionally, in a tenth implementation according to the third aspect or any implementation thereof, the packet authentication selection criteria comprises a flow ID.

[0020] Optionally, in an eleventh implementation according to the third aspect or any implementation thereof, the packet authentication selection criteria adjust a frequency of packets from the specific flows or in the set of packets that are selected for packet header authentication based on a network segment traversed by the packets.

[0021] A third aspect relates to a method implemented by a receiving device to provide packet authentication selection criteria for selecting specific flows or a set of packets of one flow for packet header authentication. The method includes receiving an authentication policy from a controller of a network, wherein the authentication policy provides packet authentication selection criteria for selecting specific flows or a set of packets of one flow for packet header authentication; receiving a packet comprising a packet payload and an encapsulation header encapsulating the packet payload; determining whether the packet is part of the specific flows or the set of packets based on the packet authentication selection criteria; computing, when the packet is part of the specific flows or the set of packets, a first authentication value for authenticating the packet header, obtaining a second authentication value from the encapsulation header, and performing packet header authentication based on the first authentication value and the second authentication value; and skipping, when the packet is not part of the specific flows or the set of packets, packet header authentication of the packet.

[0022] Optionally, in a first implementation according to the third aspect, the second authentication value is encoded in an authentication value field of an HMAC sub-TLV. [0023] Optionally, in a second implementation according to the third aspect or any implementation thereof, the second authentication value is encoded in an authentication value field of a digital signature sub-TLV.

[0024] Optionally, in a third implementation according to the third aspect or any implementation thereof, the method further includes receiving a set of authentication keys associated with the authentication policy; and computing the first authentication value based on an authentication key in the set of authentication keys.

[0025] Optionally, in a fourth implementation according to the third aspect or any implementation thereof, the method further includes obtaining an index from the encapsulation header; and identifying the authentication key in the set of authentication keys based on the index. [0026] Optionally, in a fifth implementation according to the third aspect or any implementation thereof, the encapsulation header is a GENEVE header, an SRv6 header, or an IPinIP header.

[0027] Optionally, in a sixth implementation according to the third aspect or any implementation thereof, the packet authentication selection criteria adjusts a frequency of packets selected from the specific flows or in the set of packets that are for packet header authentication based on current network security conditions.

[0028] Optionally, in a seventh implementation according to the third aspect or any implementation thereof, the packet authentication selection criteria comprises on a flow ID.

[0029] Optionally, in an eighth implementation according to the third aspect or any implementation thereof, the packet authentication selection criteria comprises a network segment traversed by the specific flows or the set of packets.

[0030] A fourth aspect relates to a device comprising a memory configured to store instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the device to perform a method according to any of the preceding aspects or any implementation thereof. [0031] A fifth aspect relates to a computer program product comprising computer-executable instructions stored on a non-transitory computer-readable storage medium, the computerexecutable instructions when executed by a processor of an apparatus, cause the apparatus to perform a method according to any of the preceding aspects or any implementation thereof.

[0032] For clarity, any one of the foregoing embodiments may be combined with any one or more of the other foregoing embodiments to create a new embodiment within the scope of the present disclosure.

[0033] These and other features, and the advantages thereof, will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.

BRIEF DESCRIPTION OF DRAWINGS

[0034] For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

[0035] FIG. 1 is a diagram illustrating a network according to an embodiment of the present disclosure.

[0036] FIG. 2 is a flow chart of a process implemented by a controller according to an embodiment of the present disclosure.

[0037] FIG. 3 is a flow chart of a process implemented by a sending device according to an embodiment of the present disclosure.

[0038] FIG. 4 is a flow chart of a process implemented by a receiving device according to an embodiment of the present disclosure.

[0039] FIG. 5 is a diagram illustrating a packet according to an embodiment of the present disclosure.

[0040] FIG. 6 is a diagram of a GENEVE header according to an embodiment of the present disclosure. [0041] FIG. 7 is a diagram of a multi-segment software-defined wide area network (SD-WAN) option class TLV according to an embodiment of the present disclosure.

[0042] FIG. 8 is a diagram of an HMAC authentication sub-TLV according to an embodiment of the present disclosure.

[0043] FIG. 9 is a diagram of a digital signature (digital-sig) sub-TLV according to an embodiment of the present disclosure.

[0044] FIG. 10 is an apparatus according to an embodiment of the present disclosure.

DESCRIPDEFINTION OF EMBODIMENTS

[0045] It should be understood at the outset that, although illustrative implementations of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

[0046] As stated above, packet authentication is critical in defending against the various network attacks. However, performing packet authentication consumes computation resources of network devices and can therefore affect network performance. The disclosed feature is especially important for fifth-generation (5G) Internet of things (loT) scenario where the computation resource is limited.

[0047] Disclosed herein are various systems and methods for providing packet authentication selection criteria for selecting specific flows or a particular set of packets of a flow for packet header authentication. By performing packet authentication only on specific flows or a particular set of packets of a flow, the disclosed embodiments reduce computation resource use of network devices and improve network performance. Additionally, the disclosed embodiments do not increase security risk because all flows or data packets include the disclosed authentication TLVs. Therefore, a malicious actor is not able to identify flows or packets that are not being authenticated to implement an attack. In an embodiment, a controller can determine an authentication policy to identify the specific flows or the particular set of packets of a flow for packet header authentication. In some embodiments, among thousands of customer premises equipment (CPEs), only a small percentage of CPEs are configured to select specific flows or packets to authenticate, while all other CPEs are configured to authenticate every flow/packet.

[0048] FIG. 1 is a diagram illustrating a network 100 according to an embodiment of the present disclosure. It should be noted that the disclosed embodiments are not limited to the network 100 described in FIG. 1 and may be applicable to data packets or data flows communicated on other types of networks. In the depicted embodiment, the network 100 illustrates multi-segment SD-WAN stitching via a cloud backbone. SD-WAN is an overlay connectivity service that optimizes transport of Internet-Protocol (IP) packets over one or more underlay connectivity services and determines forwarding behavior by applying policies to the IP packets. SD-WAN uses software-defined networking (SDN) principles and centralized control to manage and optimize wide-area networks (WANs). SD-WAN is designed to make WANs more efficient, flexible, and cost-effective compared to traditional WAN architectures that rely heavily on dedicated hardware and leased circuits. SD-WAN is widely deployed to connect CPEs of an enterprise with services in one or more cloud data centers and/or to connect different branch offices. SD-WAN stitching is a method of connecting multiple SD-WAN segments (or regions) through a cloud-based infrastructure. An SD-WAN segment is a logical portion or subset of an SD-WAN network that operates as a distinct domain, typically with its own policies, configurations, and management scope. For example, a large enterprise may have multiple branch offices/locations, each operating as a distinct domain having its own policies, configurations, and management scope. For instance, in FIG. 1, CPE 102, CPE 104, and CPE 106, may be CPEs (e.g., routers or switches) of an enterprise that are located at different branch offices/locations (e.g., CPE 102 may be located in a New York , CPE 104 in California, and CPE 106 in London). Each CPE is responsible for routing traffic from client subnets/domain to a cloud 110. The cloud 110 provides a cloud-based network infrastructure that enables CPE 102, CPE 104, and CPE 106 to communicate with each other and/or to one or more cloud services/applications. The cloud 110 may include one or more gateway (GW) devices (e.g., GW 114 may be a GW for all of the United

States and GW 116 may be a GW for Europe) or edge devices (e.g., edge 112). A GW device is a network device or virtual device that acts as an intermediary (i.e., gatekeeper) to the cloud 110. The GWs often integrate a firewall to ensure that only authorized traffic is sent through the cloud 110. An edge device is a network device that provides one or more cloud services and is located at the edge/border of the cloud network so that the edge device can provide customers faster services.

[0049] CPE 102, CPE 104, and CPE 106 may be connected to the cloud 110 via one or more connections. For example, an SD-WAN controller 120 may be configured to establish control plane sessions (e.g., internal Border Gateway Protocol (iBGP) sessions) with CPE 102, CPE 104, and CPE 106 for exchanging routing and configuration information to establish IP security (IPsec) tunnels between CPE 102 and GW 114, CPE 104 and GW 114, and CPE 106 and GW 116. An IPsec tunnel is a secure, encrypted connection between two endpoints over an untrusted network such as the public Internet. In the depicted embodiment, CPE 102 also has a direct connection to the edge 112 via a provider network or virtual private network (VPN) 108. As shown in FIG. 1, multi-segment SD-WAN stitching via a cloud backbone enables geographic faraway enterprise branches that have established SD-WAN paths to their corresponding cloud GWs to connect those branches via the cloud backbone for enabling the exchange of data between the branches. One advantage of multi-segment SD-WAN stitching via a cloud backbone is that the network paths from CPEs to the Cloud GW have more reliable connections and are constantly monitored by sophisticated network functions, whereas communication via the public internet among those branches might have limited bandwidth, unpredictable connection performance, or be prone to cyber-attacks. However, for simplicity, FIG. 1 only illustrates one or two CPEs connected to each GW of the cloud 110. In practice, each GW may be connected to and receive traffic from thousands of CPEs. As further described herein, data contained in the header of packets is not encrypted. This permits transit devices to forward the packet without having to encrypt and decrypt each packet. However, this also causes a GW to consume lots of computational resources performing authentication on all the packets that the GW receives to verify that the header information has not been altered or that the sender is authorized to send a packet through the GW. As a result, the authentication process can decrease network performance.

[0050] To address the above issue, in an embodiment the SD-WAN controller 120 (or another network controller) is configured to determine an authentication policy that provides packet authentication selection criteria for performing selective packet header authentication. By implementing selective packet header authentication, network performance is improved without increasing security risk. In an embodiment, the authentication policy is transmitted by the SD- WAN controller 120 to CPE 102, CPE 104, and CPE 106 over the control plane sessions.

[0051] FIG. 2 is a flow chart of a process 200 implemented by a controller to provide packet authentication selection criteria for selecting specific flows or a set of packets of one flow for packet header authentication according to an embodiment of the present disclosure. For example, the process 200 may be implemented by the SD-WAN controller 120 (or another network controller) in FIG. 1.

[0052] The controller, at step 202, establishes control plane sessions with a plurality of devices. For example, the controller SD-WAN controller 120 may establish iBGP sessions with the CPEs and GWs in FIG. 1 to distribute routing or policy/control information. The disclosed embodiments are not limited by the protocol used to establish the control plane sessions between the controller and the plurality of devices.

[0053] The controller, at step 204, determines an authentication policy. In an embodiment, the authentication policy provides a packet authentication selection criteria for selecting specific flows or a set of packets of one flow for performing packet header authentication. In an embodiment, a receiving device (e.g., GW 114 in FIG. 1) only performs authentication on packets satisfying the packet authentication selection criteria specified by the authentication policy. By performing authentication on only selective packet flows or sets of packets satisfying the packet authentication selection criteria, the receiving device reduces the amount of computational resources expended on processing a packet and thus, improving network performance. However, as will be further described herein, because not every packet is being authenticated, to reduce malicious activity (e.g., a man-in-the-middle attack where packets are intercepted in the middle of a route and modified), the disclosed embodiments disguise every packet to make packets that are selected for authentication indistinguishable from packets that are not selected for authentication to a malicious actor. For example, as described below, every packet includes an authentication type TLV that carries an authentication value that can be used for authenticating the packet. Nonlimiting examples of authentication type TLVs include Hash-based Message Authentication Code (HMAC) sub-TLV for carrying an HMAC value as described in FIG. 8 and a digital signature (digital-sig) sub-TLV as described in FIG. 9. Thus, by applying the disclosed embodiments, a malicious actor cannot identify packets to modify since the malicious actor will be unable to identify which packets will be authenticated and which packets will not be authenticated. In some embodiments, the authentication value carried in the packet may be a dummy or obscure value (i.e., not a real authentication value (e.g., a value randomly generated) when the packet is not part of a packet flow or not part of a set of packets selected for authentication. This can also reduce computational resources by not having to calculate a real authentication value. However, even when all the packets include a valid authentication value, the controller, using the authentication policy, can determine the packet authentication selection criteria for selecting specific flows or a set of packets of one flow for performing packet header authentication for reducing the computational resource usage of a receiving device.

[0054] In an embodiment, the controller can also adjust or modify the packet authentication selection criteria as needed. In some embodiments, modification of the packet authentication selection may be performed dynamically by the receiving device based on a network alert level. For example, the authentication policy may indicate to the receiving device to authenticate just the first packet of every flow matching the packet authentication selection criteria or every Nth packet (e g., every 100^th packet) of a flow matching the packet authentication selection criteria when the network alert is at level 1 alert, every 10^th packet when the network is at level 2 alert, and so on. In some embodiments, the authentication policy may indicate that all flows from a particular region have to be authenticated if the region is not a secure region, or may indicate that no packets from a certain region needs to be authenticated if that region is highly secure. In some embodiments, only certain receiving devices (e.g., GW 116) designated by the controller are selected to perform the disclosed embodiments while other receiving devices (e.g., GW 114) may operate as normal and authenticate every received packet. For example, if the path from GW 114 to GW 116 is highly secure, once GW 114 verifies the authenticity of every packet it receives and forwards to the GW 116, it is unlikely that the packets have been modified, and thus, GW 116 may be configured to, based on the authentication policy, randomly select packets for authentication to reduce the computational resource usage of GW 114. In some embodiments, the controller may also be configured to apply or adjust one or more mechanisms for handling frames loss such as, but not limited to, dynamically adjusting the frequency of authentication based on packet loss detection (e.g., increase the authentication frequency to ensure that enough authenticated packets are received to maintain security), performing retransmission requests, performing forward error correction (FEC) techniques to send an additional error-correcting code with the packets sequence numbering, sending heartbeat messages, or performing multi-path transmission time-based reconciliation. In some embodiments, the controller may also adjust or modify the authentication policy to handle replay attacks (i.e., man-in-the-middle resending prior captured packet frames) by instructing the plurality of devices to include or use one or more mechanisms to verify that a packet is not a replay packet. Such mechanisms include, but are not limited to, utilizing timestamps, sequence numbers, nonce values, challenge-response mechanisms, session keys, digital signatures with context information, or packet expiry information.

[0055] The controller, at step 206, sends the authentication policy over the control plane sessions to the plurality of devices. This permits the plurality of devices to implement the authentication policy for selecting specific flows or a set of packets of one flow for performing packet header authentication. [0056] FIG. 3 is a flow chart of a process 300 implemented by a first device to provide selective packet header authentication according to an embodiment of the present disclosure. For example, the process 300 may be implemented by CPE 102 in FIG. 1. The first device, at step 302, receives an authentication policy from a controller of a network. As described above, the authentication policy provides packet authentication selection criteria for selecting specific flows or a set of packets of one flow for performing packet header authentication. For example, the packet authentication selection criteria may instruct the device to select packets based on a flow ID, based on information in a particular header field or a combination of header fields, or based on another characteristic of the packet. The packet authentication selection criteria may also indicate a frequency (e.g., select every Nth packet from XYZ flow ID) at which packets are selected for authentication. As stated above, the controller can modify or adjust the packet authentication selection criteria as desired.

[0057] The first device, at step 304, generates a packet. In an embodiment, the generated packet is a packet that encapsulates an original packet carrying a packet payload. The packet payload carries the actual data being transported by the original packet. In an embodiment, the generated packet encapsulates the original packet with one or more additional headers to enable proper delivery of the packet across a network. For example, as will be further described, an Encapsulating Security Payload (ESP) header may be added to provide security and encryption services to the original packet, a GENEVE header may be added to carry tunneling information, and an outer header may be added to indicate the endpoints of the tunnel. Further, in accordance with the disclosed embodiments, an authentication type TLV is included in the generated packet to carry packet header authentication information such as the HMAC value or a digital signature value. Alternatively, in some embodiments, the authentication type TLV may carry an obscure value when the packet is not a packet selected for packet header authentication based on the authentication policy. By including the authentication type TLV and either a real or fake authentication value, the generated packet is indistinguishable from a packet which is selected for packet header authentication and a packet which is not selected for packet header authentication. Thus, an attacker is unable to identify non-selected authentication packets for malicious activities. [0058] For instance, at step 306, the first device determines whether the packet is part of the specific flows or the set of packets based on the authentication policy. As stated above, the controller may specify the criteria for selecting the specific flows or the set of packets. When the first device determines that the packet is selected for authentication based on the authentication policy, the first device, at step 308, computes an authentication value for the packet for authenticating the packet. For example, in an embodiment, the controller, using the control plane sessions, can share a secret key with a sending/first device and a receiving/second device. The first device can execute a cryptographic algorithm (e.g., secure hash algorithm (SHA)-256 hash function) using the shared key to generate the authentication value or generate a digital signature value using asymmetric cryptography and public-private key pairs. Other forms of cryptography, security, or hash algorithms (e.g., SHA-1 or Message-Digest algorithm 5 (MD5)) may also be implemented in accordance with the disclosed embodiments. Alternatively, in some embodiments, when the first device determines that the packet is not selected for authentication based on the authentication policy, the first device, at step 312, generates an obscure/fake authentication value (e.g., using a random number generator). The first device, at step 310, encodes authentication information (e.g., an authentication TLV carrying either the real or fake authentication value) in the header of the packet. At step 314, the first device transmits/forwards the packet to the intended destination device.

[0059] FIG. 4 is a flow chart of a process 400 implemented by a second device to provide selective packet header authentication according to an embodiment of the present disclosure. For example, the process 400 may be implemented by GW 114 and/or GW 116 in FIG. 1. The second device, at step 402, receives an authentication policy from a controller of a network. As described above, the authentication policy provides packet authentication selection criteria for selecting or identifying specific flows or a set of packets of one flow for performing packet header authentication. The second device, at step 404, receives a packet comprising a packet payload and an encapsulation header encapsulating the packet payload. The second device, at step 406, determines whether the packet is part of the specific flows or the set of packets based on the packet authentication selection criteria. As described above, each packet may include an authentication TLV (or sub-TLV) encoding carrying either a real or obscure authentication value so that packet encoding is indistinguishable between packets that are selected for packet header authentication and packets that are not selected for packet header authentication. When the second device determines that the packet is part of the specific flows or the set of packets, the second device, at step 408, computes a first authentication value for authenticating the packet header. For example, the second device may compute the authentication value using a hash function and/or a public key of the sending device. The second device, at step 410, obtains a second authentication value from the packet (e.g., from an authentication sub-TLV in the header information of the packet). The second device, at step 412, performs packet header authentication based on the first authentication value and the second authentication value. For example, when the first authentication value and the second authentication value matches, then the packet header information of the packet is verified, otherwise the packet fails authentication. In an embodiment, when the second device determines that the packet is not part of the specific flows or the set of packets, the second device, at step 414, skips (i.e., does not perform) packet header authentication of the packet. This way, by selectively performing packet header authentication only on specific flows or a set of packets of one flow, the second device reduces computation resource usage, which can improve network performance.

[0060] FIG. 5 is a diagram illustrating a packet 500 according to an embodiment of the present disclosure. The packet 500 is an example of a packet that encapsulates and encrypts an original packet for tunneling the packet through an IPsec tunnel to ensure security (e.g., to provide security for enterprise traffic between CPEs in FIG. 1). For example, the packet 500 may be an example of a packet generated by the CPE 102 and forwarded along an IPsec tunnel to GW 114 in FIG. 1 or by the first device in FIG. 2. The packet 500 includes a packet header 502 and a packet payload 504. The packet header 502 includes an outer header 512, a Generic Network Virtualization Encapsulation (GENEVE) header 514, an ESP header 516, and an inner header 518.

[0061] The outer header 512 includes either an IP version 4 (IPv4) header or an IP version 6 (IPv6) header and a User Datagram Protocol (UDP) header . The outer header 512 contains routing information for the packet 500 such as the source IP address of the sending device at a first end of an IPsec tunnel and the destination IP address of the receiving device at a second end of the IPsec tunnel. For instance, the IPv4/IPV6 header may contain an IPv4/IPV6 address of CPE 102 as the source IP address and an IPv4/IPV6 address of GW 114 as the destination IP address. The IPv4/IPV6 header also encodes the value 17 in a Protocol field (for IPv4 header) or a NxtHdr field (for IPv6 header) to indicate that the UDP header follows the IPv4/IPV6 header in the packet 500. In an embodiment, a source port field of the UDP header is used to carry a flow identifier (e.g., Source Port =xxxx) rather than a true UDP connection and a destination port field of the UDP header is used to identify that the packet is a Geneve packet (e.g., Dst Port = 6081 (GENEVE)). 6081 is the assigned port number designated by the Internet Assigned Numbers Authority (IANA) for Geneve. The source port should be the same for all packets belonging to a single encapsulated flow to prevent reordering due to the use of different paths. In some embodiments, the outer header 512 may include another outer header such as an Ethernet header preceding the IPv4/IPV6 header for transporting the packet 500 over Ethernet.

[0062] The GENEVE header 514 carries information that allows for the tunneling of various types of packets such as in overlay networks for SDN as described in FIG. 1. For example, the GENEVE header 514 indicates a protocol type of the encapsulated packet and includes an identifier that maps to a specific virtual network in overlay architectures. The GENEVE header 514 is described in Internet Engineering Task Force (IETF) Request for Comments: 8926, published November 2020. A format of the GENEVE header 514 is shown and further described in FIG. 6.

[0063] The ESP header 516 is designed to provide a mix of security services (e.g., confidentiality, data origin authentication, connectionless integrity, and anti-replay service) in IPv4 and IPv6. For example, security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. The set of security services provided depends on options selected at the time of Security Association (SA) establishment and on the location of the implementation in a network topology. The ESP header 516 carries a Security Parameters Index (SPI), a sequence number, and other authentication data that are used for performing authentication (e.g., data origin authentication to ensure that the packet is from an authorized sender).

[0064] The inner header 518 includes an encapsulated IP header (i.e., the original IP header) of the packet. The inner header 518 contains the source address of the original sender and the destination address of the destination device that the packet is intended for. The inner header 518 may also include a transport header such as a Transmission Control Protocol (TCP) header. The packet payload 504 carries the actual data to be sent to the destination device. The inner header 518 and the packet payload 504 are encrypted to protect the content of the packet. By not encrypting the other headers in the packet 500, the transit nodes along a path (e.g., GW 114 and GW 116 in FIG. 1) can steer the packet 500 based on the destination IP address in the outer header 512 without the need to decrypt and re-encrypt the packet 500 when forwarding the packet 500, thus optimizing processing resources and enhancing overall efficiency within the cloud 110. However, because the packet 500 may traverse an untrusted network such as the public Internet in route to the destination device, data authentication and integrity check are still needed to verify that the information in the unencrypted fields (i.e., information in the outer header 512, the GENEVE header 514, or the ESP header 516).

[0065] FIG. 6 is a diagram of a GENEVE header 600 according to an embodiment of the present disclosure. As stated above, the GENEVE header 600 is a tunnel header that carries information that allows for the tunneling of various types of packets. Tunneling refers to the process of encapsulating one network protocol within another, which allows data to be securely transmitted over an incompatible or intermediate network. For example, IPv6 packets can be encapsulated in IPv4 packets to traverse an IPv4 network. The GENEVE header 600 is typically used in network virtualization overlays for multi-tenant cloud data centers. The GENEVE header 600 includes a version (Ver) field 602 (2 bits), an options length (Opt Len) field 604 (6 bits), an O field 606 (1 bit), a Critical (C) option field 608 (1 bit), a reserved (Rsvd.) field 610 (6 bits), a Protocol Type field 612 (16 bits), a Virtual Network Identifier (VNI) field 614 (24 bits), a reserved field 616 (8 bits), and an Options field 618 (variable-length). The version (Ver) field 602 is used to indicate the current version of the GENEVE header (e.g., current version number is 0). In an embodiment, packets received by a tunnel endpoint with an unknown version is dropped. Transit devices interpreting GENEVE packets with an unknown version number will treat them as UDP packets with an unknown payload. The options length (Opt Len) field 604 used to indicate the length of the Options field 618, expressed in 4-byte multiples. Thus, the GENEVE header 600 can have a minimum total size of 8 bytes and a maximum total size of 260 bytes. The start of the payload headers (e.g., inner header 518 in FIG. 5) can be found using this offset from the end of the base GENEVE header. The O field 606 is used to indicate that the packet is a control packet containing a control message. Control messages are sent between tunnel endpoints. Tunnel endpoints do not forward the payload of control packets, and transit devices do not attempt to interpret control packets. In an embodiment, because control messages are less frequent, tunnel endpoints direct control packets to a high-priority control queue (for example, to direct the packet to a general purpose central processing unit (CPU) from a forwarding application-specific integrated circuit (ASIC) or to separate out control traffic on a network interface card (NIC)). Transit devices do not alter forwarding behavior on the basis of the bit in the O field 606. The Critical (C) option field 608 is used to indicate that an option is critical. When one or more options has the critical bit set in the Critical (C) option field 608, then tunnel endpoints will parse the options list to interpret any critical options. For tunnel endpoints where option parsing is not supported, the packet is dropped on the basis of the ‘C’ bit being set in the Critical (C) option field 608. If the ‘C’ bit is not set in the Critical (C) option field 608, tunnel endpoints may strip all options using the option length specified in the options length (Opt Len) field 604 and forward the decapsulated packet. Transit devices are not to drop packets on the basis of the ‘C’ bit. The reserved (Rsvd.) field 610 and the reserved field 616 are reserved for future use. The reserved (Rsvd.) field 610 and the reserved field 616 are set to zero on transmission and ignored on receipt. The Protocol Type field 612 is used to indicate the type of protocol data unit appearing after the GENEVE header 600 in the packet. For example, the Protocol Type field 612 would encode the value 50, which is the IANA value assigned to the ESP protocol, to indicate that an ESP header follows the GENEVE header in the packet 500 shown in FIG. 5. The Virtual Network Identifier (VNI) field 614 is used to indicate an identifier for a unique element of a virtual network. In many situations, this may represent a Layer 2 (L2) segment; however, the control plane defines the forwarding semantics of decapsulated packets. In some embodiments, the VNI may be used as part of equal-cost multi-path (ECMP) forwarding decisions or may be used as a mechanism to distinguish between overlapping address spaces contained in the encapsulated packet when load balancing across CPUs. The Options field 618 is used to indicate zero or more tunnel options and are encoded using Type-Length- Value (TLV) format. Each option consists of a 4-byte option header and a variable amount of option data interpreted according to the type. Non-limiting examples of data that may be included in the Options field 618 include metadata or information about a VNI, security data such as encryption keys, security tokens, and information to handle replay/man-in-the-middle attacks (e.g., timestamps, sequence numbers, nonce values, session keys, packet expiration information), quality of service (QoS) requirement data, forwarding information such as information on gateways that the packet should traverse or avoiding forwarding the packet through certain regions or areas, or application specific data for certain applications. Tunnel endpoints must be able to parse the variable-length header, including any options, and take action. Transit devices may optionally be able to interpret the options and take action. However, as nonterminating devices, transit devices are not to insert, modify, or delete options in the Options field 618.

[0066] FIG. 7 is a diagram of a multi-seg-SD-WAN option class TLV 700 according to an embodiment of the present disclosure. The multi-seg-SD-WAN option class TLV 700 may be used to encode a GENEVE option to indicate the endpoints of SD-WAN tunnel that a packet should traverse in a multi-seg-SD-WAN as shown in FIG. 1. The multi-seg-SD-WAN option class TLV 700 may be included in the Options field 618 of the GENEVE header 600 in FIG. 6. The multi-seg-SD-WAN option class TLV 700 comprises a multi-seg-SD-WAN option class type field 702, a Type field 704, R fields 706, Length field 710, SD-WAN Tunnel Endpoint Sub-TLV field 712, Optional SD-WAN Tunnel Originator Sub-TLV field 714, and Optional Type Length Value objects (variable) field 716. The multi-seg-SD-WAN option class type field 702 (Type value= to be determined (TBD)) indicates that the GENEVE option is a multi-seg-SD-WAN option class encoding. The Type field 704 indicates the various types of multi-segment SD-WAN (Type value=TBD) such as Single Hop Transit SD-WAN, Multi-Hop Transit SD-WAN with explicitly specified egress Cloud GW, or Multi-Hop Transit SD-WAN without specified egress Cloud GW. The R fields 706 (3 bits) are reserved. The Length field 710 indicates the length of the multi- seg-SD-WAN option class TLV 700 following the Length field 710. The SD-WAN Tunnel Endpoint Sub-TLV field 712 indicates the destination CPE of the IPsec Tunnel. The Optional SD-WAN Tunnel Originator Sub-TLV field 714 carries zero or more SD-WAN Tunnel Originator Sub-TLV to indicate the originating CPE of the IPsec Tunnel. The Optional TLV objects (variable) field 716 carries zero or more sub-TLVs.

[0067] FIG. 8 is a diagram of an HMAC authentication sub-TLV 800 according to an embodiment of the present disclosure. In an embodiment, the HMAC authentication sub-TLV 800 is an optional sub-TLV for carrying an HMAC authentication value that can be used by a receiving device to perform packet header authentication. HMAC is a mechanism that combines a cryptographic hash function and a secret key to produce an HMAC authentication value. In an embodiment, the HMAC authentication sub-TLV 800 can be included in the Optional TLV objects field 716 of the multi-seg-SD-WAN option class TLV 700 in FIG. 7, which in turn is included in the Options field 618 of the GENEVE header 600 in FIG. 6, which is part of the packet 500 in FIG. 5. The HMAC authentication sub-TLV 800 comprises a Type field 802, a Length field 804, a K field 806, a Reserved field 808, and an HMAC Authentication Value field 810. The type field 802 carries a type value (HMAC-AUTH-VAL)=TBD indicating that the TLV encoding is an HMAC authentication sub-TLV. The Length field 804 carries a value that indicates the remaining length of the HMAC authentication sub-TLV 800 following the Length field 804. In an embodiment, the K field 806 is 2 bits and is used to indicate an index of a set of hash keys distributed by the controller to the plurality of devices and used for computing the HMAC authentication value. For example, in an embodiment, the controller may distribute a set of four hash keys (or other number of keys) periodically (e.g., every hour, every day, etc.). The keys in the set of hash keys may be rotated randomly or according to a schedule or frequency so that HMAC values may be generated by different keys in the set of keys to provide additional security. The value in the K field 806 indicates which keys in the set of key was used in generating the HMAC value carried in the HMAC authentication sub-TLV 800. The reserved field 808 is reserved for future use. The HMAC Authentication Value field 810 carries the HMAC value generated by the first device using the designated hash key. In an embodiment, to produce a 4- byte (32-bit) or 8-byte (64-bit) HMAC value from the standard 32-byte (256-bit) output of HMAC- SHA-256, the first device may utilize an additional hash function on the 32-byte output from HMAC-SHA-256 to condense the hash value to the desired size.

[0068] FIG. 9 is a diagram of a Digital Signature sub-TLV 900 according to an embodiment of the present disclosure. In an embodiment, the Digital Signature sub-TLV 900 is an optional sub-TLV for carrying a digital signature value that can be used by a receiving device to perform packet header authentication. For instance, a digital signature value can be generated using a pair of cryptographic keys (private key and public key) created using a public-key cryptography algorithm such as, but not limited to, Rivest-Shamir-Adleman (RSA). The cryptographic keys may be generated and distributed by the controller as described above. The private key is kept secret and is used to create the signature. The public key is shared with others and is used to verify the signature. Data in a packet (e.g., header information) is passed through a hash function (e.g., SHA-256) to generate a fixed-length hash value that uniquely represents the data. The hash value is encrypted using the sender’s private key to produce a digital signature of the sender. In an embodiment, the digital signature is sent along with the original data to the recipient using the Digital Signature sub-TLV 900. The recipient computes the hash of the received data using the same hash function. The recipient decrypts the digital signature using the sender’s public key to obtain the original hash value that was signed. If the hash value derived from the received data matches the decrypted hash, then the signature is valid. A mismatch indicates that the data has been tampered with or the signature is invalid. Similar to the HMAC authentication sub-TLV 800, the Digital Signature sub-TLV 900 can be included in the Optional TLV objects field 716 of the multi- seg-SD- WAN option class TLV 700 in FIG. 7, which in turn is included in the Options field 618 of the GENEVE header 600 in FIG. 6, which is part of the packet 500 in FIG. 5. The Digital Signature sub-TLV 900 comprises a Type field 902, a Length field 904, a K field 906, a Reserved field 908, and a Digital Signature Value field 910. The type field 902 carries a type value (DIGITAL- SIG)=TBD indicating that the TLV encoding is a Digital Signature sub-TLV. The Length field 904 carries a value that indicates the remaining length of the Digital Signature sub-TLV 900 following the Length field 904. In an embodiment, the K field 906 is 2 bits and is used for the same purpose as the K field 806 in the HMAC authentication sub-TLV 800. The reserved field 908 is reserved for future use. The Digital Signature Authentication Value field 910 carries the digital signature value generated by the first device using the designated key.

[0069] FIG. 10 is a diagram illustrating an apparatus 1000 according to an embodiment of the present disclosure. The apparatus 1000 can be used to implement embodiments of the present disclosure such as, but not limited to, the CPEs or GW devices described in FIG. 1. The apparatus 1000 includes input/output (I/O) 1080 or I/O means, receiver units (RX) 1020 or receiving means, and transmitter units (TX) 1040 or transmitting means. In an embodiment, the RX 1020 is a receiver of a transceiver that is configured to receive data via ingress ports 1010. In an embodiment, the TX 1040 or is a transmitter of the transceiver and is configured to transmit or send data via data egress ports 1050. In an embodiment, the I/O 1080 is configured to manage (receive/output) data between components of the apparatus 1000 such as a central processing unit (CPU) and external devices or peripherals (e.g., keyboard, mouse, display, etc.) connected to the apparatus 1000. [0070] The apparatus 1000 includes a memory 1060 or data storing means for storing the instructions and various data. The memory 1060 can be any type of, or combination of, memory components capable of storing data and/or instructions. For example, the memory 1060 can include volatile and/or non-volatile memory such as read-only memory (ROM), random access memory (RAM), ternary content-addressable memory (TCAM), and/or static random-access memory (SRAM). The memory 1060 can also include one or more disks, tape drives, and solid- state drives. In some embodiments, the memory 1060 can be used as an over-flow data storage device to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution.

[0071] The apparatus 1000 has one or more processors 1030 or other processing means (e.g., a CPU) to process instructions. The one or more processors 1030 may be implemented as one or more CPU chips, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The one or more processors 1030 are communicatively coupled via a system bus with the I/O means 1080, ingress ports 1010, RX 1020, TX 1040, egress ports 1050, and memory 1060. The one or more processors 1030 can be configured to execute instructions stored in the memory 1060. Thus, the one or more processors 1030 provide a means for performing any computational, comparison, determination, initiation, configuration, or any other action corresponding to the claims when the appropriate instruction is executed by the processor. In some embodiments, the memory 1060 can be memory that is integrated with the processor 1030.

[0072] In one embodiment, the memory 1060 stores a selective packet authentication module 1070. The selective packet authentication module 1070 includes data, executable instructions, and/or one more sub-modules for implementing the disclosed embodiments such as, but not limited to, executing the methods described in FIG. 2 - FIG. 4. Thus, the inclusion of the selective packet authentication module 1070 substantially improves the functionality of the apparatus 1000.

[0073] While several embodiments have been provided in the present disclosure, it may be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the disclosure is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

[0074] In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and may be made without departing from the spirit and scope disclosed herein.

Claims

CLAIMS What is claimed is:

1. A method implemented by a network device, the method comprising: receiving an authentication policy from a controller of a network, wherein the authentication policy provides packet authentication selection criteria for selecting specific flows or a set of packets of one flow for packet header authentication; generating a packet comprising a packet payload and an encapsulation header encapsulating the packet payload; determining whether the packet is part of the specific flows or the set of packets based on the authentication policy; computing an authentication value for the packet for authenticating the packet when the packet is part of the specific flows or the set of packets; encoding authentication information in the encapsulation header, wherein the authentication information comprises the authentication value in an authentication value field when the packet is part of the specific flows or the set of packets; and transmitting the packet.

2. The method of claim 1 , wherein the authentication information comprises an obscure value in the authentication value field when the packet is not part of the specific flows or the set of packets.

3. The method of claim 2, wherein the obscure value is randomly generated.

4. The method according to any of claims 1-3, further comprising encrypting the packet payload.

5. The method according to any of claims 1-4, wherein the authentication information is encoded in a hash-based message authentication code (HMAC) Sub-Type Length Value (TLV), and wherein the authentication value field carries a HMAC authentication value.

6. The method according to any of claims 1-4, wherein the authentication information is encoded in a digital signature sub-TLV, and wherein the authentication value field carries a digital signature value.

7. The method according to any of claims 1-6, further comprising: receiving a set of authentication keys associated with the authentication policy; and determining the authentication value based on an authentication key in the set of authentication keys.

8. The method according to claim 7, further comprising rotating the authentication key that is used in the set of authentication keys in determining the authentication value.

9. The method according to any of claims 7-8, wherein the authentication information comprises an index of the authentication key in the set of authentication keys that is used in determining the authentication value.

10. The method according to any of claims 1-9, wherein the encapsulation header is a Generic Network Virtualization Encapsulation (GENEVE) header, a Segment Routing over Internet Protocol (IP) version 6 (SRv6) header, or an IPinIP header.

11. The method according to any of claims 1-10, wherein the packet authentication selection criteria adjusts a frequency of packets from the specific flows or in the set of packets that are selected for packet header authentication based on current network security conditions.

12. The method according to any of claims 1-11, wherein the packet authentication selection criteria comprises a flow identifier (ID).

13. The method according to any of claims 1-12, wherein the packet authentication selection criteria adjusts a frequency of packets from the specific flows or in the set of packets that are selected for packet header authentication based on a network segment traversed by the packets.

14. A method implemented by a network device, the method comprising: receiving an authentication policy from a controller of a network, wherein the authentication policy provides packet authentication selection criteria for selecting specific flows or a set of packets of one flow for packet header authentication; receiving a packet comprising a packet payload and an encapsulation header encapsulating the packet payload; determining whether the packet is part of the specific flows or the set of packets based on the packet authentication selection criteria; computing, when the packet is part of the specific flows or the set of packets, a first authentication value for authenticating a packet header of the packet, obtaining a second authentication value from the encapsulation header, and performing packet header authentication based on the first authentication value and the second authentication value; and skipping, when the packet is not part of the specific flows or the set of packets, packet header authentication of the packet.

15. The method according to claim 14, wherein the second authentication value is encoded in an authentication value field of a hash-based message authentication code (HMAC) Sub-Type Length Value (TLV).

16. The method according to claim 14, wherein the second authentication value is encoded in an authentication value field of a digital signature sub-TLV.

17. The method according to any of claims 14-16, further comprising: receiving a set of authentication keys associated with the authentication policy; and computing the first authentication value based on an authentication key in the set of authentication keys.

18. The method according to claim 17, further comprising: obtaining an index from the encapsulation header; and identifying the authentication key in the set of authentication keys based on the index.

19. The method according to any of claims 14-18, wherein the encapsulation header is a Generic Network Virtualization Encapsulation (GENEVE) header, a Segment Routing over Internet Protocol (IP) version 6 (SRv6) header, or an IPinIP header.

20. The method according to any of claims 14-19, wherein the packet authentication selection criteria adjusts a frequency of packets selected from the specific flows or in the set of packets that are for packet header authentication based on current network security conditions.

21. The method according to any of claims 14-20, wherein the packet authentication selection criteria comprises on a flow identifier (ID).

22. The method according to any of claims 14-21, wherein the packet authentication selection criteria comprises a network segment traversed by the specific flows or the set of packets.

23. A method implemented by a controller of a network, the method comprising: establishing control plane sessions with a plurality of devices in the network; determining an authentication policy based on network conditions, wherein the authentication policy provides packet authentication selection criteria for selecting specific flows or a set of packets of one flow for packet header authentication, and wherein the packet authentication selection criteria adjusts a frequency of packets from the specific flows or in the set of packets that are selected for packet header authentication based on a network segment traversed by the packets; and sending the authentication policy over the control plane sessions to the plurality of devices.

24. The method according to claim 23, wherein the packet authentication selection criteria comprises parameters for dynamically adjusting a frequency of packets from the specific flows or in the set of packets that are selected for packet header authentication based on current network security conditions.

25. The method according to any of claims 23-24, wherein the packet authentication selection criteria comprises a flow identifier (ID).

26. The method according to any of claims 23-25, further comprising: determining a set of authentication keys associated with the authentication policy; and sending the set of authentication keys over the control plane sessions to at least two devices in the plurality of devices.

27. An apparatus comprising: a memory or storage means configured to store instructions; and one or more processors or processing means coupled to the memory or the storage means and configured to execute the instructions to cause the apparatus to perform a method according to any of claims 1-26.

28. A computer program product comprising computer-executable instructions stored on a non-transitory computer-readable storage medium, the computer-executable instructions when executed by one or more processor of an apparatus, cause the apparatus to perform a method according to any of claims 1-26.