Key distribution over IP / UDP

Abstract

To provide a transmitting node, a receiving node, and a method for transmitting an encryption key over Internet Protocol (IP) and User Datagram Protocol (UDP).SOLUTION: A system 100 includes a pair of communication devices 110-A (a transmitting node) and 110-Z (a receiving node) which communicate over a communication path 120. The transmitting node and the receiving node support security for communications exchanged between the transmitting node and the receiving node over the communication path. The transmitting node and the receiving node support security for communications based on use of communication security elements 111-A, 111-Z and support encryption and authentication functions. Each IP flow to be encrypted has its own encryption key for use by IEEE 802.1AE.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] [Reference to Related Applications] This application is a continuation-in-part of co-pending application Serial No. 17 / 514,046, filed October 29, 2021 as 323876-US-NP (the '046 application), the teachings of which are incorporated herein by reference in their entirety.

[0002] [Field of Disclosure] Various exemplary embodiments relate generally to communication networks and, more particularly, but not exclusively, to security for communication protocols within communication networks. [Background technology]

[0003] In a communication system, various communication techniques may be used to support communications, including the use of communication security capabilities to support security for communications of the communication system. Summary of the Invention

[0004] In at least some example embodiments, a transmitting (TX) node comprises at least one processor and at least one memory containing computer program code that causes the TX node to at least (i) generate a Media Access Control Security (MACsec) Key Agreement (MKA) packet containing a Layer 2 header, an Internet Protocol (IP) header, a User Datagram Protocol (UDP) header, an IEEE 802.1x header, and an MKA payload containing an encryption key for encrypting a packet flow transmitted from the TX node to a receiving (RX) node, and (ii) transmit the MKA packet over Layer 3 transport to the RX node.

[0005] In at least some of the above transmitting (TX) node embodiments, the encryption key may be a Secure Association Key (SAK).

[0006] In at least some of the above transmitting (TX) node embodiments, the TX node is configured to receive the SAK from the key server using Advanced Encryption Standard (AES) key wrapping.

[0007] In at least some of the above transmitting (TX) node embodiments, the TX node is configured to encrypt the encryption key in the MKA packet using AES Key Wrap.

[0008] In at least some of the above transmitting (TX) node embodiments, the IEEE 802.1x header includes a security channel identification (SCI) that uniquely identifies the packet flow and the encrypting TX node.

[0009] In at least some of the above transmitting (TX) node embodiments, the SCI includes an encryption segment identifier (SID) for identifying the encryption TX node and a unique identifier for the tunnel on the encryption TX node.

[0010] In at least some of the above transmitting (TX) node embodiments, the TX node is configured to locally generate the unique identifier and transmit the SCI to the RX node using an MKA over IP / UDP header.

[0011] In at least some of the above transmit (TX) node embodiments, the TX node is configured to encrypt packets of the packet flow using an encryption key and transmit the encrypted packets to the RX node over Layer 2.5 / 3 transport.

[0012] In at least some of the above transmit (TX) node embodiments, the Layer 2.5 / 3 transport may be a Layer 2.5 Multiprotocol Label Switching (MPLS) transport.

[0013] In at least some of the above transmit (TX) node embodiments, the layer 2.5 / 3 transport may be a layer 3 Internet Protocol (IP) transport.

[0014] In at least some of the above transmit (TX) node embodiments, the Layer 3 transport may be an IP transport.

[0015] In at least some example embodiments, a receiving (RX) node comprises at least one processor and at least one memory containing computer program code that uses the at least one processor to at least (i) receive from a transmitting (TX) node over Layer 3 transport an MKA packet containing a Layer 2 header, an IP header, a UDP header, an IEEE 802.1x header, and an MKA payload containing an encryption key for decrypting a packet flow sent from the TX node to the RX node, and (ii) process the MKA packet to obtain an SAK.

[0016] In at least some of the above receiving (RX) node embodiments, the encryption key may be a SAK.

[0017] In at least some of the receiving (RX) node embodiments described above, the encryption key is encrypted within the MKA packet using AES key wrap.

[0018] In at least some of the receiving (RX) node embodiments described above, the IEEE 802.1x header includes an SCI that uniquely identifies the packet flow and the encrypting TX node.

[0019] In at least some of the receiving (RX) node embodiments described above, the SCI includes an encryption SID to identify the encryption TX node and a unique identifier for the tunnel on the encryption TX node.

[0020] In at least some of the above receiving (RX) node embodiments, the RX node is configured to receive SCI from the TX node using an MKA over IP / UDP header.

[0021] In at least some of the receiving (RX) node embodiments described above, the RX node is configured to receive encrypted packets of the packet flow from the TX node over Layer 2.5 / 3 transport and to use an encryption key to decrypt the encrypted packets.

[0022] In at least some of the above receiving (RX) node embodiments, the layer 2.5 / 3 transport may be a layer 2.5 MPLS transport.

[0023] In at least some of the above receiving (RX) node embodiments, the layer 2.5 / 3 transport may be a layer 3 IP transport.

[0024] In at least some of the above receiving (RX) node embodiments, the Layer 3 transport may be an IP transport.

[0025] The teachings herein can be readily understood by considering the following detailed description in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0026] [Figure 1] 1 illustrates an example embodiment of a system configured to support security for communications. [Figure 2]1 illustrates an exemplary embodiment of a packet format to illustrate the application of encryption and authentication to packets in a manner to support MPLS security using some aspects of IEEE 802.1AE. [Figure 3A] 1 illustrates an exemplary embodiment of a packet format to illustrate the application of encryption and authentication to packets in a manner to support IP security using some aspects of IEEE 802.1AE. [Figure 3B] 1 illustrates an exemplary embodiment of a packet format to illustrate the application of encryption and authentication to packets in a manner to support IP security using some aspects of IEEE 802.1AE. [Figure 3C] 1 illustrates an exemplary embodiment of a packet format to illustrate the application of encryption and authentication to packets in a manner to support IP security using some aspects of IEEE 802.1AE. [Figure 4A] 1 illustrates an exemplary embodiment of a packet format to illustrate the application of encryption and authentication to packets in a manner to support IP security using some aspects of IEEE 802.1AE. [Figure 4B] 1 illustrates an exemplary embodiment of a packet format to illustrate the application of encryption and authentication to packets in a manner to support IP security using some aspects of IEEE 802.1AE. [Figure 4C] 1 illustrates an exemplary embodiment of a packet format to illustrate the application of encryption and authentication to packets in a manner to support IP security using some aspects of IEEE 802.1AE. [Figure 5] 1 illustrates an exemplary embodiment of a method for supporting security for communications. [Figure 6] 1 illustrates an exemplary embodiment of a computer suitable for use in performing various functions presented herein. [Figure 7]10 illustrates an exemplary embodiment of a packet format for indicating a new MKA packet transported over EAPoL.

[0027] For ease of understanding, the same reference numbers have been used herein, wherever possible, to designate identical elements that are common to the various figures. DETAILED DESCRIPTION OF THE INVENTION

[0028] Various exemplary embodiments for supporting security for communications are presented, which may be configured to support security for communications of communication protocols at various Open Systems Interconnection (OSI) layers.

[0029] Various exemplary embodiments for supporting security for communications may be configured to support security for communications of a communications protocol operating above Layer 2 using a Layer 2 network security protocol. Various exemplary embodiments for supporting security for communications may be configured to support security for communications of a communications protocol operating at Layer 2.5 (e.g., a Multiprotocol Label Switching (MPLS) protocol or other suitable Layer 2.5 protocol) using some aspects of an IEEE (Institute of Electrical and Electronics Engineers) 802 protocol, such as a Layer 2 network security protocol (e.g., IEEE 8021AE or other suitable type of Layer 2 network security protocol).

[0030] Various example embodiments for supporting security for communications may be configured to support security for communications of a communications protocol operating at Layer 3 (e.g., Internet Protocol (IP), such as IP version 4 (IPv4) or IP version 6 (IPv6), or other suitable Layer 3 protocol) using Layer 2 network security protocols.

[0031] Various example embodiments for supporting security for communications may be configured to support security for communications of communication protocols operating above Layer 2 using some aspects of Layer 2 network security protocols.

[0032] Various exemplary embodiments for supporting communications security may enable devices on a communications path operating using a communications protocol at Layer 2 or higher to use a Layer 2 network security protocol to support communications security for a communications protocol operating at Layer 2 or higher in a manner that allows devices on the communications path operating using the communications protocol at Layer 2 or higher to operate on the headers of the communications protocol at Layer 2 or higher (e.g., manipulating the headers, such as reading and modifying the headers, so that a Layer 2.5 MPLS-enabled router can make decisions based on the MPLS header, and so that a Layer 3 IP-enabled router can make decisions based on the IP header).

[0033] Various exemplary embodiments for supporting security for communications are configured to support security for communications of a communications protocol operating above Layer 2 using aspects of a Layer 2 network security protocol configured to support encryption and authentication functions (e.g., an IEEE (Institute of Electrical and Electronics Engineers) 802 protocol such as IEEE 802.1AE or other suitable type of Layer 2 network security protocol).

[0034] It will be appreciated that these and various other exemplary embodiments and advantages or potential advantages of supporting network security for packets may be further understood with reference to the various figures, which are further described below.

[0035] FIG. 1 illustrates an exemplary embodiment of a system configured to support security for communications.

[0036] System 100 includes a pair of communication devices 110-A and 110-Z (collectively, communication devices 110) that can communicate via communication path 120. Communication device 110 may be any device that can communicate via a communication path, and communication path 120 may be any path along which communication devices may communicate; thus, communication device 110 and communication path 120 may be associated with various communication contexts. For example, communication device 110 may include an end-user device, a router, a switch, etc. For example, communication path 120 may represent a single link, multiple links, a portion of a communication network, a communication network, multiple communication networks, etc. For example, communication devices 110-A and 110-Z may each be a customer router and a provider router, a pair of provider routers, a pair of customer routers communicating over a communication network (e.g., a customer router associated with an enterprise network, a customer router associated with a data center network, etc.), etc. It will be understood that the foregoing examples are merely a few of the ways in which exemplary embodiments may be used to support security for communication device communications.

[0037] The communication devices 110 are configured to support security for communications exchanged between the communication devices 110 over the communication network 120. The communication devices 110 may be configured to support security for communications based on a network security protocol that supports encryption and authentication functions. For example, for a packet transmitted from communication device 110-A to communication device 110-Z, the communication device 110-A may apply encryption and authentication to the packet based on the network security protocol, and the communication device 110-Z may verify the authentication and perform decryption based on the network security protocol. Similarly, for a packet transmitted from communication device 110-Z to communication device 110-A, the communication device 110-Z may apply encryption and authentication to the packet based on the network security protocol, and the communication device 110-A may verify the authentication and perform decryption based on the network security protocol.

[0038] The communication device 110 may be configured to support security for communication of a communication protocol operating on Layer 2 using a Layer 2 network security protocol. The communication device 110 may be configured to support security for communication of a communication protocol operating at Layer 2.5 (e.g., a Multiprotocol Label Switching (MPLS) protocol or other suitable Layer 2.5 protocol) using a Layer 2 network security protocol. The communication device 110 may be configured to support security for communication of a communication protocol operating at Layer 3 (e.g., an Internet Protocol (IP), such as IP version 4 (IPv4) or IP version 6 (IPv6), or other suitable Layer 3 protocol) using a Layer 2 network security protocol.

[0039] Communication device 110 may be configured to support security for communications of communication protocols operating on Layer 2 using a Layer 2 network security protocol, where the communications of the communication protocols operating on Layer 2 are transported using a communication protocol operating at Layer 2 (e.g., Ethernet or other suitable Layer 2 communication protocol). Communication device 110 may be configured to support security for communications of communication protocols operating on Layer 2 using some aspects of a Layer 2 network security protocol, where the Layer 2 network security protocol is configured to support encryption and authentication functions (e.g., an IEEE (Institute of Electrical and Electronics Engineers) 802 protocol such as IEEE 802.1AE or other suitable type of Layer 2 network security protocol). Communication device 110 may be configured to support security for communications in a manner that allows portions of packets to remain in the clear (i.e., not encrypted or authenticated) so that devices along communication path 120 can process packets based on the portions of the packets left in the clear (e.g., MPLS label switching where the packet is an MPLS packet, IP address-based routing where the packet is an IP packet, etc., as well as various combinations thereof).

[0040] Communication device 110 may be configured to support security for communications based on use of communication security element 111. More specifically, communication device 110-A may be configured to support security for packets transmitted toward and received from communication device 110-Z (e.g., encryption and authentication computation functions) based on communication security element 111-A, and similarly, communication device 110-Z may be configured to support security for packets transmitted toward and received from communication device 110-A (e.g., decryption and authentication verification functions) based on communication security element 111-Z. Communication security element 111 may be configured to support various other functions for supporting security for communications according to various exemplary embodiments presented herein.

[0041] While system 100 is presented primarily within the context of a relatively simple arrangement of elements, it will be understood that system 100 may be any system including any elements (e.g., devices, networks, etc.) that may support secure communications in accordance with the various exemplary embodiments presented herein.

[0042] Various exemplary embodiments for supporting security for communications may be configured to support security for communications of a communications protocol operating at Layer 2.5 (e.g., MPLS) using some aspects of a Layer 2 network security protocol (e.g., IEEE 802.1AE).

[0043] Various exemplary embodiments for supporting security for communications may support security for communications of a Layer 2.5 communications protocol, such as MPLS, using some aspects of a Layer 2 network security protocol, such as IEEE 802.1AE, in a manner that allows devices on a communications path operating using the Layer 2.5 communications protocol to operate on the Layer 2.5 communications protocol header (e.g., by reading, modifying, etc., such that a Layer 2.5 MPLS-enabled router can make decisions based on the MPLS header). In this manner, throughout the network, the MPLS header remains in the clear and unauthenticated, and thus any LSR router can read and modify the MPLS header in order to forward a packet from one PE to the next. It will be understood that this operation can be highly dynamic, and that a user can indicate, via configuration, which MPLS tunnels or services should be encrypted (although it will be understood that this type of selective application of embodiments for supporting security for MPLS communications can also be automated in various ways).

[0044] Many networks use MPLS as a transport layer, and therefore mobility, security, and encryption are expected to be important for MPLS transport in many situations. For example, as the number of cyber attacks increases, the need for low-latency and high-throughput encryption to protect the MPLS transport layer increases. However, encryption consumes a significant amount of resources in the network (e.g., increased Central Processing Unit (CPU) power usage, increased latency added to the transport to perform encryption actions, etc.) and is therefore a relatively expensive operation in the network. In addition, MPLS encryption is generally not used in networks because most encryption is performed in Layer 3 IP (i.e., IPSec) and Layer 2 Ethernet (i.e., MACSec).

[0045] Various exemplary embodiments may be configured to support MPLS security using some aspects of IEEE 802.1AE in a manner that supports MPLS data path security, supporting encryption and authentication of MPLS packets at line rate at the tunnel layer or service layer with relatively low CPU resource usage and the introduction of relatively little or no additional latency for the encryption and authentication functions. MPLS encryption can encrypt any MPLS packet at the tunnel layer or service layer using some aspects of the IEEE 802.1AE standard (which is typically used in Layer 2 Ethernet encryption (i.e., MACSec)) and the Advanced Encryption Standard Galois / Counter Mode (AES-GCM) algorithm (e.g., based on AES-128, AES-256, etc.).

[0046] In various exemplary embodiments, the following capabilities may be used to enable MPLS security via certain aspects of IEEE 802.1AE.

[0047] To support MPLS security using some aspects of IEEE 802.1AE, desired tunnels or services to be encrypted may be identified. The desired tunnels or services to be encrypted may be identified based on label values. If the tunnel is encrypted, the service label may be encrypted or left in clear text. If the service is encrypted, the service label must be in clear text. For example, hardware used for encryption may be configured to lock onto the tunnel's label stack or the tunnel and service's label stack, identify the tunnel or service as being encryption-capable (e.g., an encryption-capable tunnel or encryption-capable service), and encrypt that tunnel or service only via AES-GCM-128 / 256.

[0048] To support MPLS security using some aspects of IEEE 802.1AE, the MPLS label stack for a tunnel or tunnels and services is placed on top of the 802.1AE header and is not encrypted or authenticated, allowing the MPLS network to read and operate on the MPLS header.

[0049] For example, by leaving the MPLS header unencrypted and unauthenticated, the MPLS network can read the MPLS label stack and make appropriate forwarding decisions based on the MPLS label stack. If the MPLS label stack is encrypted, the MPLS network cannot read the MPLS label stack to read the label values and make appropriate forwarding decisions based on the label values.

[0050] For example, leaving the MPLS header unencrypted and unauthenticated allows the MPLS network to manipulate the MPLS label stack as needed, such as removing labels from the MPLS label stack or adding labels to the MPLS label stack (e.g., popping or pushing specific labels along the path of an LSP based on MPLS forwarding standards such as MPLS fast re-route (FRR) or segment routing (SR)). If authentication is calculated on the MPLS label stack and the MPLS label stack changes along the path of the MPLS packet, the CRC calculated at the destination will fail. To avoid this type of authentication failure while still allowing manipulation of the MPLS label stack, as described above, authentication is not calculated across the MPLS label stack.

[0051] To support MPLS security using some aspects of IEEE 802.1AE, when MPLS packets are transported over Ethernet technology, the Ethernet header may also be left unencrypted and unauthenticated, thereby allowing operations on the Ethernet header without causing a CRC check failure at the destination.

[0052] It will be appreciated that the application of encryption and authentication to packets in a manner to support MPLS security using some aspects of IEEE 802.1AE may be further understood with reference to the packet format of FIG. 2.

[0053] 2 illustrates an exemplary embodiment of a packet format for illustrating the application of encryption and authentication to a packet in a manner to support MPLS security using aspects of IEEE 802.1AE. As shown in FIG. 2, packet 200 includes a payload, an 802.1AE header attached to the payload, an MPLS header attached to the 802.1AE header (including a first label attached to the 802.1AE header and a second label attached to the first label), an Ethernet header attached to the MPLS header (including an EtherType MPLS field attached to the Second Label, an SMAC field attached to the EtherType MPLS field, and a DMAC field attached to the SMAC field), an Integrity Check Value (ICV) field attached to the payload, and a Cyclic Redundancy Check (CRC) field attached to the ICV field.

[0054] Packet 200 includes a first portion (including the payload) that is encrypted, a second portion (including the payload and the 802.1AE header) that is authenticated, and a third portion (including the MPLS header, Ethernet header, and ICV and CRC fields) that is neither encrypted nor authenticated. While presented primarily with respect to an exemplary embodiment in which certain types of MPLS labels remain unencrypted and unauthenticated to support MPLS security using some aspects of IEEE 802.1AE, it will be understood that various other types of MPLS labels may remain unencrypted and unauthenticated to support MPLS security using some aspects of IEEE 802.1AE for various types of MPLS solutions (e.g., Border Gateway Protocol (BGP)-Labeled Unicast (BGP-LU) labels, Entropy Label Indicator (ELI) labels, Entropy Labels (EL), etc., as well as various combinations thereof). As shown herein, this leaves the MPLS header unencrypted and unauthenticated, thereby allowing devices along the path to operate on the MPLS header as needed.

[0055] To support MPLS security using some aspects of IEEE 802.1AE, label edge routers (LERs) involved in communicating MPLS packets, i.e., ingress LERs (ILERs) and egress LERs (ELERs), may be configured to support various functions to support MPLS security using some aspects of IEEE 802.1AE.

[0056] To support MPLS security using some aspects of IEEE 802.1AE, the ILER is configured to encrypt and authenticate a specific MPLS tunnel or service. The ILER pushes the appropriate MPLS label for the MPLS tunnel or service onto the packet. The ILER programs the hardware with this MPLS label stack to be encrypted and authenticated, and programs the appropriate AES-GCM-128 / 256 key to identify and encrypt this MPLS tunnel or service as an encrypted MPLS tunnel or service. The packet is constructed with the appropriate MPLS label and goes through 802.1AE MPLS encryption (e.g., using 802.1AE MPLS encryption-enabled hardware). The ILER examines each MPLS packet and, if the MPLS packet matches the MPLS label stack for this specific MPLS tunnel or service, encrypts the packet. The ILER adds an 802.1AE header after the MPLS label stack in accordance with some aspects of the IEEE 802.1AE standard, and then encrypts the packet's payload (i.e., the data after the MPLS stack) using AES-GCM-128 / 256 in accordance with some aspects of IEEE 802.1AE. The ILER also performs authentication on the 802.1AE header and payload (e.g., using an authentication algorithm), but does not perform any authentication on the MPLS label stack or Ethernet header, thereby allowing the MPLS label stack to be inspected and manipulated via the MPLS LSR routers that connect the MPLS encryption and decryption routers.

[0057] To support MPLS security using some aspects of IEEE 802.1AE, the ILER may support the use of encryption and authentication offsets to apply encryption and authentication to portions of a packet that should be encrypted and authenticated, respectively. The encryption and authentication offsets may be specified in various ways (e.g., using a start byte / bit position and length, a start and end byte / bit position, etc.). The ILER may support the use of programmable and flexible encryption and authentication offsets to identify portions of a packet to be encrypted and authenticated, respectively. The ILER may calculate the encryption and authentication offsets based on the set of MPLS labels included in the MPLS header of an MPLS tunnel or service (e.g., software calculates the encryption and authentication offsets). The ILER (e.g., hardware and / or software) may be flexible and programmable enough to allow programming of any offset for encryption and any offset for authentication, thereby allowing any packet to be encrypted and authenticated at the appropriate offsets based on the flow encryption and authentication needs. Given various network scenarios that may apply to a given MPLS tunnel or service, the ILER may maintain multiple sets of encryption and authentication offsets for a given MPLS tunnel or service to support appropriate application of encryption and authentication to the MPLS tunnel or service for the various network scenarios that may apply to the given MPLS tunnel or service. It will be appreciated that fewer or more encryption and authentication offsets, as well as for different network scenarios, may be maintained by the ILER for the various MPLS tunnels or services supported by the ILER.

[0058] To support MPLS security using some aspects of IEEE 802.1AE, encrypted packets are forwarded from the ILER to the ELER through the MPLS transport network, and LSR routers can perform various operations on the encrypted packets based on the appropriate OSI layer headers, which are in the clear. For example, these LSR routers can make switching decisions based on the MPLS label stack. For example, these LSR routers can manipulate the MPLS label stack (e.g., remove and / or add labels for FRR, traffic engineering (TE), etc., as well as various combinations thereof) as needed and in accordance with IETF MPLS standards. It will be appreciated that LSR routers may be capable of performing these and various other operations on encrypted packets based on unencrypted and unauthenticated MPLS headers.

[0059] To support MPLS security using some aspects of IEEE 802.1AE, the ELER is configured to decrypt a specific MPLS tunnel or service and support authentication for the specific MPLS tunnel or service. When a packet arrives at the ELER, the MPLS label stack identifies this router as an ELER router. The ELER identifies the IEEE 802.1AE so that it can decrypt the MPLS tunnel or service packet. The ELER is programmed with the incoming MPLS label stack so that the incoming MPLS label stack can be used by the ELER to identify the MPLS tunnel or service as an encrypted MPLS tunnel or service. Based on identifying an MPLS label stack in the packet that matches the incoming MPLS label stack, indicating that the MPLS label stack is associated with an MPLS tunnel or service, and based on the presence of an IEEE 802.1AE header, the ELER decrypts the packet using some aspects of IEEE 802.1AE procedures and performs authentication on the 802.1AE header and payload to ensure there are no CRC errors. The ELER can then process the packet via the normal MPLS data path.

[0060] It will be appreciated that various exemplary embodiments for supporting MPLS security using aspects of IEEE 802.1AE allow MPLS-capable routers to selectively use a Layer 2.5 MPLS header to forward encrypted packets throughout an MPLS domain (e.g., between provider edge routers) by performing encryption and authentication on portions of the packet excluding the MPLS header (as opposed to encrypting any bytes after the 802.1AE header and performing authentication on the entire packet, even if it includes IP and MPLS headers).

[0061] Although MPLS security using aspects of IEEE 802.1AE is presented primarily with respect to exemplary embodiments that include encryption and authentication, it will be understood that in at least some exemplary embodiments, MPLS security using aspects of IEEE 802.1AE may include authentication without encryption.

[0062] It will be appreciated that various exemplary embodiments for supporting security for communications may be configured to support security for communications of communication protocols operating at Layer 2.5 using Layer 2 network security protocols, and may be configured to support various other functions for supporting security for communications of communication protocols operating at Layer 2.5 based on the use of Layer 2 network security protocols.

[0063] Various exemplary embodiments for supporting security for communications may be configured to support security for communications of a communications protocol operating at Layer 3 (e.g., IP) using some aspects of a Layer 2 network security protocol (e.g., IEEE 802.1AE).

[0064] Various exemplary embodiments for supporting security for communications may use aspects of Layer 2 network security protocols, such as IEEE 802.1AE, to enable support of security for communications of Layer 3 communications protocols, such as IP, in a manner that allows devices along a communications path operating using the Layer 3 communications protocol to operate on the Layer 3 communications protocol header (e.g., by reading, modifying, etc., such that a Layer 3 IP-enabled router can make decisions based on the IP header). In this manner, throughout the network, the IP header remains in the clear and unauthenticated, and thus any IP router can read and optionally modify the IP header in order to forward the packet from one PE to the next. It will be appreciated that while IP headers are typically not modified except in segment routing over IPv6 (SRv6) networks, packets may still be tunneled via MPLS and IP tunneling technologies, which may require header modification. It will be appreciated that this operation may be highly dynamic, and that users may be able to indicate, via configuration, which IP flows should be encrypted (although it will be appreciated that this type of selective application of embodiments to support security for IP communications may also be automated in various ways).

[0065] Many networks that use IP provide security for IP based on the use of security protocols such as IP Security (IPSec) and IPSec Encapsulating Security Payload (ESP). However, IPSec generally consumes significant CPU resources without providing true hardware encryption support, is not line-rate, and IPSec ESP introduces relatively high latency in packet forwarding. This makes IPSec unsuitable for latency-sensitive networking applications such as time-sensitive networking (TSN), where relatively low latency is required.

[0066] Various exemplary embodiments may be configured to support IP security using some aspects of IEEE 802.1AE in a manner that supports IP data path security, supporting encryption and authentication of IP packets at line rates for selected IP flows with relatively low CPU resource usage and the introduction of relatively little additional latency for the encryption and authentication functions. IP encryption can encrypt any IP packet at the IP flow layer using some aspects of the IEEE 802.1AE standard (which is typically used in Layer 2 Ethernet encryption (i.e., MACSec)) and the AES-GCM algorithm (e.g., based on AES-128, AES-256, etc.).

[0067] In various exemplary embodiments, the following capabilities may be used to enable IP security through certain aspects of IEEE 802.1AE.

[0068] To support IP security using some aspects of IEEE 802.1AE, desired IP flows to be encrypted can be identified based on various IP flow matching techniques, such as IP header matching in the form of tuple matching or byte matching (e.g., source IP address and destination IP address matching, destination IP address matching, etc.), deep packet inspection, etc. For example, hardware used for encryption can match some portions of an IP packet (e.g., based on a hardware ternary content addressable memory (TCAM)) to determine whether the IP packet belongs to an IP flow to which IP security using some aspects of IEEE 802.1AE should be applied.

[0069] To support IP security using some aspects of IEEE 802.1AE, the IP header of an IP flow is placed over the 802.1AE header and is not encrypted or authenticated, allowing the IP network to read and operate on the IP header.

[0070] For example, leaving the IP header unencrypted and unauthenticated allows the IP network to read the IP header and make appropriate routing decisions based on the IP header. If the IP header is encrypted, the IP network cannot read the IP header to read the IP header fields and make appropriate forwarding decisions based on the IP header fields.

[0071] For example, leaving the IP header unencrypted and unauthenticated allows the IP network to manipulate the IP header as needed, such as by modifying header fields in the IP header as needed (e.g., decrementing the Time-to-Live (TTL) field, modifying the Differentiated Services Code Point (DSCP) field based on the Quality-of-Service (QoS) settings of transit IP routers, and various combinations thereof). If authentication is calculated on the IP header and the IP header changes along the path of the IP packet, the CRC calculated at the destination will fail.

[0072] To support IP security using some aspects of IEEE 802.1AE, when an IP flow is transported over MPLS technology (e.g., shortcuts, VPRNs, etc.), the MPLS header is also left unencrypted and unauthenticated, thereby allowing operations on the MPLS header (e.g., based on MPLS forwarding standards such as MPLS FRR or SR where specific labels are popped and / or pushed onto the path) without causing a CRC check failure at the destination.

[0073] To support IP security using some aspects of IEEE 802.1AE, when an IP flow is transported via dot1q technology, the dot1q header is left unencrypted and unauthenticated, thereby allowing operations on the dot1q tag (e.g., adding and / or removing dot1q tags) without causing a CRC check failure at the destination.

[0074] To support IP security using some aspects of IEEE 802.1AE, when an IP flow is transported over Ethernet technology, the Ethernet header is left unencrypted and unauthenticated, thereby allowing operations on the Ethernet header without causing a CRC check failure at the destination.

[0075] It should be noted that leaving the MPLS and Ethernet headers in the clear allows transport (e.g., IP transport and tunneling) of IP flows over any technology (e.g., dot1q VLAN switched networks, MPLS networks by tunneling IP packets through MPLS tunnels, etc., as well as various combinations thereof).

[0076] It will be appreciated that the application of encryption and authentication to packets in a manner to support IP security using some aspects of IEEE 802.1AE may be further understood by reference to the packet formats of Figures 3A-3C and 4A-4C.

[0077] 3A-3C illustrate exemplary embodiments of packet formats for illustrating the application of encryption and authentication to packets in a manner to support IP security using aspects of IEEE 802.1AE. The packet formats of FIG. 3 are configured to support encryption and authentication of IP packet payloads via aspects of IEEE 802.1AE in a manner that leaves behind a Layer 3 header, a Layer 2.5 header, and a Layer 2 header in the clear and unauthenticated so that the packet is routable through the IP network and devices along the path can perform operations based on any of these unencrypted and unauthenticated fields without any issues or failures in the decrypting routers (e.g., removal, modification, and / or addition of various fields or headers at various layers).

[0078] 3A illustrates an exemplary embodiment of a packet format for illustrating the application of encryption and authentication to a packet in a manner to support IP security for IPv4 packets using some aspects of IEEE 802.1AE. As shown in FIG. 3A, packet 300-A includes a payload, an EtherType (ETYPE) field prepended to the payload, an 802.1AE header prepended to the ETYPE field, an IPv4 header prepended to the 802.1AE header, an Ethernet header prepended to the IPv4 header (including an EtherType IPv4 field prepended to the IPv4 header and an SMAC field prepended to the EtherType IPv4 field), an 802.1AE header, an Ethernet header prepended to the IPv4 header (including an EtherType IPv4 field prepended to the IPv4 header, an SMAC field prepended to the EtherType IPv4 field, and a DMAC field prepended to the SMAC field), an Integrity Check Value (ICV) field prepended to the payload, and a Cyclic Redundancy Check (CRC) field prepended to the ICV field. Packet 300-A includes a first portion that is encrypted (including the payload and ETYPE field), a second portion that is authenticated (including the payload, ETYPE field, and 802.1AE header), and a third portion that is neither encrypted nor authenticated (including the IPv4 header and Ethernet header, and the ICV and CRC fields). As shown herein, this leaves the IPv4 header and Ethernet header unencrypted and unauthenticated, thereby allowing devices along the path to operate on the IPv4 header and / or Ethernet header as appropriate.

[0079] 3B illustrates an exemplary embodiment of a packet format for illustrating the application of encryption and authentication to a packet in a manner to support IP security for IPv6 packets using some aspects of IEEE 802.1AE. As shown in FIG. 3B, packet 300-B includes a payload, an EtherType (ETYPE) field attached to the payload, an 802.1AE header attached to the ETYPE field, an IPv6 header attached to the 802.1AE header, an Ethernet header attached to the IPv6 header (including an EtherType IPv6 field attached to the IPv6 header, an SMAC field attached to the EtherType IPv6 field, and a DMAC field attached to the SMAC field), an Integrity Check Value (ICV) field attached to the payload, and a Cyclic Redundancy Check (CRC) field attached to the ICV field. Packet 300-B includes a first portion that is encrypted (including the payload and ETYPE field), a second portion that is authenticated (including the payload, ETYPE field, and 802.1AE header), and a third portion that is neither encrypted nor authenticated (including the IPv6 header and Ethernet header, and the ICV and CRC fields). As shown herein, this leaves the IPv6 header and Ethernet header unencrypted and unauthenticated, thereby allowing devices along the path to operate on the IPv6 header and / or Ethernet header as appropriate.

[0080] 3C illustrates an exemplary embodiment of a packet format to illustrate the application of encryption and authentication to packets in a manner to support IP security for IP packets using some aspects of IEEE 802.1AE where the IP packets are transported based on MPLS. For example, the IP packets may be transported across a portion of a network or across the entire network via an MPLS tunnel. As shown in FIG. 3C, packet 300-C includes a payload, an EtherType (ETYPE) field prepended to the payload, an 802.1AE header prepended to the ETYPE field, an IP header (which may be IPv4 or IPv6) prepended to the 802.1AE header, an MPLS header prepended to the 802.1AE header (including a first label prepended to the IP header and a second label prepended to the first label), an Ethernet header prepended to the MPLS header (including an EtherType MPLS field prepended to the EtherType MPLS field), the 802.1AE header (including a first label prepended to the IP header and a second label prepended to the first label), an Ethernet header prepended to the MPLS header (including an EtherType MPLS field prepended to the second label, an SMAC field prepended to the EtherType MPLS field, and a DMAC field prepended to the SMAC field), an integrity check value (ICV) field prepended to the payload, and a cyclic redundancy check (CRC) field prepended to the ICV field. Packet 300-C includes an encrypted first portion (including the payload and ETYPE field), an authenticated second portion (including the payload, ETYPE field, and 802.1AE header), and an unencrypted and unauthenticated third portion (including the IP header, MPLS header, and Ethernet header, as well as the ICV and CRC fields).As shown herein, this leaves the IP header, MPLS header, and Ethernet header unencrypted and unauthenticated, thereby allowing devices along the path to operate on one or more of the IP header, MPLS header, and / or Ethernet header as needed.

[0081] 4A-4C illustrate exemplary embodiments of packet formats for illustrating the application of encryption and authentication to packets in a manner to support IP security using aspects of IEEE 802.1AE. The packet formats of FIGS. 4A-4C are configured to support encryption and authentication of IP packet payloads via aspects of IEEE 802.1AE in a manner that leaves behind a Layer 3 header, a Layer 2.5 header, and a dot1q tag. The Layer 2 header is then left clear and unauthenticated so that the packet is routable through an IP network and devices can perform operations based on any of these unencrypted and unauthenticated fields without any issues or failures in the decryption router (e.g., removing, modifying, and / or adding various fields or headers at various layers). The packet formats of FIGS. 4A-4C are similar to the packet formats of FIGS. 3A-3C, except that the packet formats of FIGS. 4A-4C also include a dot1q tag between the Layer 3 IP header and the Layer 2 Ethernet header (illustratively, an 802.1Q tag on the IP header and an EtherType dot1q tag on the 802.1Q tag, followed by SMAC and DMAC in the Layer 2 header).

[0082] 4A shows an exemplary embodiment of a packet format for illustrating the application of encryption and authentication to a packet in a manner to support IP security for IPv4 packets using some aspects of IEEE 802.1AE, where the packet also includes a dot1q tag. As shown in FIG. 4A, packet 400-A includes a payload, an EtherType (ETYPE) field prepended to the payload, an 802.1AE header prepended to the ETYPE field, an IPv4 header prepended to the 802.1AE header, an 802.1Q tag prepended to the IPv4 header, an Ethernet header prepended to the 802.1Q tag (including an EtherType dot1q field prepended to the 802.1Q tag, an SMAC field prepended to the EtherType dot1q field, and a DMAC field prepended to the SMAC field), an Integrity Check Value (ICV) field added to the payload, and a Cyclic Redundancy Check (CRC) field added to the ICV field. Packet 400-A includes a first portion that is encrypted (including the payload and ETYPE field), a second portion that is authenticated (including the payload, ETYPE field, and 802.1AE header), and a third portion that is neither encrypted nor authenticated (including the IPv4 header, 802.1Q tag, and Ethernet header, as well as the ICV and CRC fields). As shown herein, this leaves the IPv4 header, 802.1Q tag, and Ethernet header unencrypted and unauthenticated, thereby allowing devices along the path to operate on the IPv4 header, 802.1Q tag, and / or Ethernet header, as needed.

[0083] 4B shows an exemplary embodiment of a packet format to illustrate the application of encryption and authentication to a packet in a manner to support IP security for IPv6 packets using some aspects of IEEE 802.1AE, where the packet also includes a dot1q tag. As shown in FIG. 4B, packet 400-B includes a payload, an EtherType (ETYPE) field prepended to the payload, an 802.1AE header prepended to the ETYPE field, an IPv6 header prepended to the 802.1AE header, an 802.1Q tag prepended to the IPv6 header, an Ethernet header prepended to the 802.1Q tag (which includes an EtherType dot1q field prepended to the 802.1Q tag, an SMAC field prepended to the EtherType dot1q field, and a DMAC field prepended to the SMAC field), an Integrity Check Value (ICV) field prepended to the payload, and a Cyclic Redundancy Check (CRC) field prepended to the ICV field. Packet 400-B includes a first portion that is encrypted (including the payload and ETYPE field), a second portion that is authenticated (including the payload, ETYPE field, and 802.1AE header), and a third portion that is neither encrypted nor authenticated (including the IPv6 header, 802.1Q tag, and Ethernet header, as well as the ICV and CRC fields). As shown herein, this leaves the IPv6 header, 802.1Q tag, and Ethernet header unencrypted and unauthenticated, thereby allowing devices along the path to operate on the IPv6 header, 802.1Q tag, and / or Ethernet header, as needed.

[0084] FIG. 4C illustrates an exemplary embodiment of a packet format to illustrate the application of encryption and authentication to packets in a manner to support IP security for IP packets using some aspects of IEEE 802.1AE, where the IP packets are transported based on MPLS and the packets also include dot1q tags. As shown in FIG. 4C, packet 400-C includes a payload, an Ethertype (ETYPE) field prepended to the payload, an 802.1AE header prepended to the ETYPE field, an IP header (which may be IPv4 or IPv6) prepended to the 802.1AE header, an MPLS header prepended to the 802.1AE header (including a first label attached to the IP header and a second label attached to the first label), an 802.1Q tag prepended to the MPLS header, an Ethernet header prepended to the 802.1Q tag (including an EtherType dot1q field prepended to the 802.1Q tag, an SMAC field prepended to the EtherType dot1q field, and a DMAC field prepended to the SMAC field), an ICV (Integrity Check Value) field prepended to the payload, and a CRC (Cyclic Redundancy Check) field prepended to the ICV field. Packet 400-C includes a first portion that is encrypted (including the payload and the ETYPE field), a second portion that is authenticated (including the payload, the ETYPE field, and the 802.1AE header), and a third portion that is neither encrypted nor authenticated (including the IP header, the MPLS header, the 802.1Q tag, and the Ethernet header, as well as the ICV and CRC fields). As shown herein, this leaves the IP header, the MPLS header, the 802.1Q tag, and the Ethernet header unencrypted and unauthenticated, thereby allowing devices along the path to operate on one or more of the IP header, the MPLS header, the 802.1Q tag, and / or the Ethernet header as appropriate.

[0085] To support IP security using some aspects of IEEE 802.1AE, IP routers involved in communicating IP packets, i.e., ingress IP routers and egress IP routers, may be configured to support various functions to support IP encryption using some aspects of IEEE 802.1AE.

[0086] To support IP security using some aspects of IEEE 802.1AE, an ingress IP router is configured to support encrypting and authenticating specific IP flows for routing through a Layer 3 network. IP flows to which IP security using some aspects of IEEE 802.1AE should be applied can be configured in various ways, such as by a user or automatically. IP flows to which IP security using some aspects of IEEE 802.1AE should be applied can be identified based on various criteria (e.g., a combination of source and destination IP addresses, the destination IP address alone, etc.). The ingress IP router is programmed with IP flow matching criteria related to the application of IP security (e.g., software can program the IP flow matching criteria into hardware so that the hardware can match packets passing through the hardware based on the IP flow matching criteria). The ingress IP router is programmed with an IEEE 802.1AE Secure Association Key (SAK) for encryption (e.g., the hardware is also programmed with an IEEE 802.1AE SAK via 802.1AE procedures). It will be appreciated that each IP flow to be encrypted may be configured to have its own encryption key for use by the IEEE 802.1AE method.

[0087] To support IP security using some aspects of IEEE 802.1AE, an ingress IP router may support the use of encryption and authentication offsets to apply encryption and authentication to the portions of a packet that are encrypted and authenticated, respectively. The encryption and authentication offsets may be specified in various ways (e.g., using a start byte / bit position and length, a start and end byte / bit position, etc.). The ingress IP router may support programmable and flexible use of encryption and authentication offsets. The ingress IP router may calculate the encryption and authentication offsets based on the IP address family (e.g., IPv4 or IPv6) of the IP flow (e.g., software calculates the encryption and authentication offsets). The ingress IP router can determine whether an IP packet is encapsulated over an MPLS tunnel (e.g., IP over MPLS, IP Fast Reroute (FRR) over MPLS for Loop-Free Alternate (LFA), or Topology Independent-LFA (TILFA), etc.) and can program the appropriate encryption and authentication offsets for the MPLS tunnel (e.g., a user or software can indicate whether an IP packet is encapsulated over an MPLS tunnel, and software can program the appropriate encryption and authentication offsets for the MPLS tunnel into hardware). The ingress IP router (e.g., hardware and / or software) can be flexible and programmable enough to allow programming of any offset for encryption and any offset for authentication, thereby allowing any packet to be encrypted and authenticated with the appropriate offsets based on the flow encryption and authentication needs. The ingress IP router can maintain multiple sets of encryption and authentication offsets for a given IP flow to support the appropriate application of encryption and authentication to the IP flow for various network scenarios that may apply to the given IP flow.For example, an ingress IP router may maintain encryption and authentication offsets such as (1) encryption and authentication offsets for MAC+IP header alone (if the IP flow egresses an untagged interface), (2) MAC+dot1q vlan tag+IP header encryption and authentication offsets (if the IP flow egresses a dot1q tagged interface), or (3) MAC+MPLS+IP header encryption and authentication offsets if the IP flow is being fast rerouted or resolved through an MPLS tunnel (e.g., tunneling or IP FRR over MPLS). It will be appreciated that fewer or more encryption and authentication offsets may be maintained by the ingress IP router for the various IP flows supported by the ingress IP router, as well as for different network scenarios.

[0088] To support IP security using some aspects of IEEE 802.1AE, encrypted packets are forwarded through an IP network from an ingress IP router to an egress IP router, with transit IP routers capable of performing various operations on the encrypted packets based on the appropriate OSI layer headers being in the clear. For example, the transit IP router may remove header fields (e.g., a MAC header and optionally a dot1q tag) from the packet to make a Layer 3 routing decision, and then add header fields (e.g., a MAC header and optionally a dot1q tag for the next segment) to the packet after the Layer 3 routing decision. For example, the transit IP router may modify one or more fields in the IP header (e.g., decrementing the TTL field, changing the DSCP field based on the QoS configuration of the transit IP router, etc.). For example, the transit IP router may add or remove an MPLS label to tunnel an IP packet through MPLS or to tunnel an IP FRR through MPLS. For example, the transit IP router may add or remove a dot1q tag depending on the input and output ports. It will be appreciated that the transit IP router may be capable of performing these and various other operations on encrypted packets based on unencrypted and unauthenticated IP, MPLS, and Ethernet headers.

[0089] To support IP security using some aspects of IEEE 802.1AE, an egress IP router is configured to decrypt specific IP flows and support authentication of the specific IP flows for routing through a Layer 3 network. An egress IP router, such as an ingress IP router, can be programmed with the appropriate IP flows that need to be decrypted on the data path so that the data path can match the IP flows and initiate decryption procedures using some aspects of IEEE 802.1AE procedures. This programming of the IP flows to be decrypted can be done manually, via signaling, etc. Upon matching the IP flows when the packets of the IP flows are received at the egress IP router, the egress IP router can identify the IP flows as encrypted flows and decrypt the packets of the IP flows based on the IEEE 802.1AE header and some aspects of IEEE 802.1AE procedures. The egress IP router can then forward the cleartext packets based on the egress IP router's forwarding rules.

[0090] Although primarily described with respect to exemplary embodiments in which IP flows are encrypted and authenticated using certain aspects of IEEE 802.1AE, it will be appreciated that various exemplary embodiments for supporting IP security using certain aspects of IEEE 802.1AE may be selectively applied such that at least some of the IP flows supported by the network may be encrypted and authenticated, but at least some of the IP flows supported by the network may not be encrypted and authenticated.

[0091] It will be understood that various exemplary embodiments for supporting IP security using aspects of IEEE 802.1AE encrypt and authenticate any MPLS header that may be present on portions of the packet excluding the IP header (as opposed to encrypting any bytes after the 802.1AE header, even if it includes IP and MPLS headers and performs authentication over the entire packet), thereby enabling IP-enabled routers to selectively use Layer 3 IP headers to forward encrypted packets through IP domains (e.g., between provider edge routers), MPLS-enabled routers to selectively use Layer 2.5 MPLS headers to forward encrypted packets through MPLS domains, where IP packets are transported over MPLS, and Ethernet-enabled devices to selectively use L2 Ethernet headers to forward encrypted packets through Ethernet domains, where IP packets are transported over Ethernet.

[0092] It will be appreciated that various exemplary embodiments for supporting security for communications may be configured to support security for communications of communication protocols operating at Layer 3 using Layer 2 network security protocols, and may be configured to support various other functions for supporting security for communications of communication protocols operating at Layer 3 based on the use of Layer 2 network security protocols.

[0093] 5 illustrates an exemplary embodiment of a method for supporting security for communications. While presented herein as primarily performed sequentially, it will be understood that at least some of the functions of method 500 may be performed simultaneously or in a different order than that illustrated in FIG.

[0094] At block 501, method 500 begins. At block 510, supporting communication of a packet includes a payload, a header of a first communication protocol at a first communication layer, and a header of a second communication protocol at a second communication layer above the first communication layer, wherein a first portion of the packet including the payload is encrypted based on the first communication protocol, a second portion of the packet including the payload and the header of the first communication protocol is authenticated based on the first communication protocol, and a third portion of the packet including the header of the second communication protocol remains unencrypted based on the first communication protocol and unauthenticated based on the first communication protocol.

[0095] The first portion of the packet, the second portion of the packet, and the third portion of the packet may be identified based on an encryption offset associated with the packet and an authentication offset associated with the packet. Supporting communication of the packet may include performing, by the encryption node, encryption of the first portion of the packet and authentication via the second portion of the packet, and transmitting, by the encryption node, the packet toward a destination node. Supporting communication of the packet may include receiving, by the node, the packet and determining, by the node, processing of the packet at the node based on the third portion of the packet. Supporting communication of the packet may include modifying, by the node, at least one aspect of the third portion of the packet to form a modified packet, and transmitting, by the node, the modified packet toward the destination node. Supporting communication of the packet may include receiving, by a decryption node, the packet and performing, by the decryption node, authentication on the second portion of the packet and decryption of the first portion of the packet.

[0096] The first communication layer may be at Layer 2. The first communication protocol may be a network security protocol configured to support encryption and authentication functions. The network security protocol supports features of the IEEE 802.1AE protocol.

[0097] The second communication layer may be above Layer 2. The second communication layer may be at Layer 2.5 or Layer 3. The second communication protocol may be a Layer 2.5 protocol or a Layer 3 protocol. The second communication protocol may support MPLS features or IP features. The second communication protocol may be a Layer 2.5 protocol. The second communication protocol may support MPLS features. The header of the second communication protocol may include a set of MPLS labels. The packet may include a header of a third communication protocol in the first communication layer. The header of the third communication protocol may be included in a third portion of the packet. The third communication protocol may support Ethernet features.

[0098] The second communication protocol may be a Layer 3 protocol. The second communication protocol may support IP features. The packet may include a header of a third communication protocol at the first communication layer. The header of the third communication protocol may be included in a third portion of the packet. The third communication protocol may support Ethernet features. The header of the third communication protocol may include source and destination MAC addresses. The header of the third communication protocol may include at least one Ethernet-related tag. The packet may include a header of the third communication protocol at the third communication layer. The third communication layer may be at Layer 2.5.

[0099] The third communication protocol may be a Layer 2.5 protocol. The third communication protocol may support MPLS features. A header of the third communication protocol may be included in a third portion of the packet. The packet may include a header of a fourth communication protocol in the first communication layer. A header of the fourth communication protocol may be included in the third portion of the packet. The fourth communication protocol may support Ethernet features. The header of the fourth communication protocol may include source and destination MAC addresses. The header of the fourth communication protocol includes at least one Ethernet-related tag. It will be understood that the packet may include various other portions, headers, fields, values, configurations, etc., as well as various combinations thereof.

[0100] Method 500 ends at block 599. It is understood that support for communication of packets may also be described as supporting communication of packets, where the packets include a payload, a header of a first communication protocol at a first communication layer, and a header of a second communication protocol at a second communication layer above the first communication layer, where a first portion of the packet that is encrypted based on the first communication protocol includes the payload, where a second portion of the packet that is authenticated based on the first communication protocol includes the payload and the header of the first communication protocol, and where a third portion of the packet that is not encrypted based on the first communication protocol and not authenticated based on the first communication protocol includes the header of the second communication protocol.

[0101] Various exemplary embodiments for supporting security for communications may provide various advantages or potential advantages. For example, various exemplary embodiments for supporting security for communications may enable a Layer 2 network security protocol to be used to support security for communications of a communication protocol operating above Layer 2 in a manner that enables devices on a communication path operating using a communication protocol above Layer 2 to operate based on the header of the communication protocol operating above Layer 2 (e.g., a Layer 2.5 MPLS-enabled router can make decisions based on the MPLS header, a Layer 3 IP-enabled router can make decisions based on the IP header, etc.).

[0102] For example, various exemplary embodiments for supporting security for communications enable a Layer 2 network security protocol to be used to support security for communications of a communications protocol operating above Layer 2, allowing devices along a communications path operating using a communications protocol operating above Layer 2 to operate on the headers of the communications protocol operating above Layer 2 without first decrypting the packet to access the headers of the communications protocol operating above Layer 2 and re-encrypting the packet before forwarding (e.g., such that the Layer 2 network security protocol does not apply encryption to the headers of the communications protocol operating above Layer 2).

[0103] For example, various exemplary embodiments for supporting security for communications may enable using a Layer 2 network security protocol to support security for communications of a communications protocol operating above Layer 2 in a manner that enables devices along a communications path operating using a communications protocol above Layer 2 to operate on the headers of the communications protocol operating above Layer 2 (e.g., modify fields in the headers) without causing CRC failures and packet drops. For example, various exemplary embodiments for supporting security for communications may enable the application of IEEE 802.1AE in a manner suitable for use in encrypting / authenticating and forwarding end-to-end MPLS tunnels or services, may enable the application of IEEE 802.1AE in a manner suitable for use in encrypting / authenticating and forwarding end-to-end IP flows, or may enable such methods, as well as various combinations thereof.

[0104] For example, various exemplary embodiments for supporting communications security may enable application of IEEE 802.1AE in a manner that enables support of multi-hop Layer 3 encryption using IEEE 802.1AE (e.g., based on leaving Layer 3 IP headers, Layer 2.5 MPLS headers, and Layer 2 headers (e.g., Ethernet MAC headers, 802.1X headers, etc.) in the clear), which is useful in many types of applications, such as Generic Routing Encapsulation (GRE) transport tunnels (e.g., Layer 2 Ethernet Virtual Private Networks (EVPNs) over Virtual Extensible Local Area Networks (VXLANs) or Layer 3 GRE Virtual Private Routed Networks (VPRNs) can carry customer data with multi-hop encryption), applications that are sensitive to transmission delays (e.g., Precision Time Protocol (PTP) G.8275.2 where synchronization information over IP can traverse networks in multi-hops), and the like, and various combinations thereof. For example, various exemplary embodiments for supporting security for communications may enable the application of IEEE 802.1AE to communications of various communication protocols above Layer 2 in a manner that allows various relatively strong attributes of IEEE 802.1AE (e.g., low latency, line-rate throughput, compatibility with Time Sensitive Networking (TSN), etc.) to be leveraged while protecting the communications of the communication protocols above Layer 2. Various exemplary embodiments for supporting security for communications may provide various other advantages or potential advantages.

[0105] FIG. 6 illustrates an exemplary embodiment of a computer suitable for use in performing various functions presented herein.

[0106] Computer 600 includes a processor 602 (e.g., a central processing unit (CPU), a processor, a processor having a set of processor cores, a processor core of a processor, etc.) and memory 604 (e.g., random access memory, read-only memory, etc.). Processor 602 and memory 604 may be communicatively coupled. In at least some exemplary embodiments, computer 600 may include at least one processor and at least one memory including computer product code configured to cause computer 600, with the at least one processor, to perform various functions presented herein.

[0107] Computer 600 may also include cooperating elements 605. Cooperating elements 605 may be hardware devices or processes that may be loaded into memory 604 and executed by processor 602 to implement various functions presented herein (in which case, for example, cooperating elements 605 (including associated data structures) may be stored in a non-transitory computer-readable storage medium such as a storage device or other suitable type of storage element (e.g., magnetic drive, optical drive, etc.)).

[0108] The computer 600 may also include one or more input / output devices 606. The input / output devices 606 may include one or more of user input devices (e.g., a keyboard, keypad, mouse, microphone, camera, etc.), user output devices (e.g., a display, speakers, etc.), one or more network communication devices or elements (e.g., input ports, output ports, receivers, transmitters, transceivers, etc.), one or more storage devices (e.g., a tape drive, floppy drive, compact disk drive, hard disk drive, solid state drive, etc.), etc., as well as various combinations thereof.

[0109] It will be understood that computer 600 may represent a general architecture and functionality suitable for implementing the functional elements described herein, portions of the functional elements described herein, etc., and various combinations thereof. For example, computer 600 may provide a general architecture and functionality suitable for implementing one or more elements presented herein, such as communication device 110, portions of communication device 110, communication security element 111, portions of communication security element 111, etc., and various combinations thereof.

[0110] Key Distribution IEEE 802.1AE was originally designed for Layer 2 encryption only. The techniques described above, hereafter referred to as ANYSec, allow some aspects of IEEE 802.1AE to be used to encrypt Layer 2.5 MPLS networks and Layer 3 IP networks.

[0111] As mentioned above, to support IP / MPLS security using some aspects of IEEE 802.1AE, a transmitting (TX) node (e.g., an ingress IP / MPLS router) is configured with a Secure Association Key (SAK) that is used to encrypt a particular IP / MPLS flow and support authentication of that particular IP flow for routing through the Layer 3 / 2.5 network from the TX node to the receiving (RX) node (e.g., an egress IP / MPLS router). In order for the RX node to decrypt the IP / MPLS flow, the RX node must have the same SAK that the TX node used to encrypt the IP / MPLS flow.

[0112] IEEE 802.1AE proposes using the Media Access Control Security (MACsec) Key Agreement (MKA) described in IEEE 802.1x2010 for key distribution between nodes. MKA provides a secure, fully distributed, point-to-point or multipoint-to-multipoint transport and several applications for its transport, including distribution of security association keys by a selected key server using Advanced Encryption Standard (AES) key wrap, such as Cipher-based Message Authentication Code (CMAC)-AES-128 or CMAC-AES-256. MKA uses the Layer 2 Extensible Authentication Protocol over LAN (EAPoL) protocol as its transport. Unfortunately, MKA transport over Layer 2 headers is not available in MPLS / IP networks. This disclosure provides transport of the SAK from the TX node to the RX node over Internet Protocol (IP) and User Datagram Protocol (UDP) to meet the needs of ANYSec.

[0113] Additionally, this disclosure details how an encrypted flow and its corresponding SAK can be identified via a security channel identifier (SCI) in the case of ANYSec. In MACsec, the SCI is constructed from the MAC address and the VLAN being encrypted. In the case of ANYSec and MPLS / IP encryption, the SCI uniquely identifies an MPLS link state protocol (LSP) tunnel or IP flow. The SCI includes an encryption segment identifier (SID) to identify the encrypting TX node and a unique identifier for the tunnel on the encrypting TX node. The SCI can be used on the RX node to (i) uniquely identify the encrypting TX node and the TX node flow and (ii) determine the appropriate SAK to use to decrypt the encrypted flow received from the TX node.

[0114] Section 9 of IEEE 802.1x-2010 describes the MACsec Key Agreement (MKA) protocol in detail. Section 9.4, the last paragraph, points out that MKA is designed for mutual authentication of participants in a connectivity association (CA) and can be used for any application. Therefore, since ANYSec uses some aspects of IEEE 802.1AE to encrypt IP and MPLS flows, MKA is used to authenticate ANYSec peers. One drawback of MKA is how it identifies SCIs in the data path and the fact that SCIs are transported as EAPoL packets (i.e., Layer 2 headers only).

[0115] Section 9 also points out that: · MKA allows nodes to discover and authenticate each other via a CA Key (CAK) and agree on a secret Security Association Key that will be used to encrypt communications; · MKA protects distributed security-related keys via AES (Advanced Encryption Standard) key wrap; ·Security association keys are created by the key server negotiated via MKA; · The MKA manages the installation and use of security-associated keys by MAC security entities (SecYs) that protect the data being transmitted and received. Each SecY uses the MKA to communicate the lowest packet number (PN) used for transmission with the SAK within the last 2 seconds, allowing the receiver to limit transmission delays; Systems implementing MKA satisfy (i) random number generation and (ii) SCI, which is a unique MAC address and port ID within the system for MACsec implementation. (In ANYSec, SCI can be modified to include a globally unique identifier: the node chassis MAC and encrypted segment); The root of the key hierarchy for any given instance of MKA is the secure CAK key. Each CAK key is identified by a CA Key Name (CKN) that allows each MKA participant to select which CAK key to use to process received MKA packets.

[0116] Most of the above criteria for MACsec are also useful for ANYSec to encrypt MPLS or IP flows, as long as (i) the MKA can be transported over IP, and (ii) the SCI is changed to uniquely identify the encrypted flow via a new identifier as described above.

[0117] EAP over IP To solve the MPLS / IP flow encryption problem using MKA for ANYSec, MKA signaling and key distribution should be done in IP, i.e., using Extensible Authentication Protocol over IP (EAPoIP). In this case, IP routes MKA packets from the originating TX node to the destination RX node of the ANYSec flow. To process an MKA packet, the destination node must identify the packet as an MKA packet. UDP and a specific UDP port assigned to MKA are used to identify a protocol data unit (PDU) as a unique MKA PDU in the network. This UDP port can be configurable or can be a well-known UDP port assigned by the Internet Assigned Numbers Authority (IANA).

[0118] UDP is ideal for this MKA identification because it is a best-effort protocol and does not have a retransmission mechanism in case of lost packets, as TCP (Transmission Control Protocol) does. This is ideal for MKA, where MKA packets are sent periodically (based on a configured timer). If several MKA packets are lost, the MKA receiver will terminate the MKA session. This periodic packet transmission is known as the heartbeat.

[0119] EAP packets 7 illustrates an exemplary embodiment of a packet format to show what a new MKA packet 700 and MKA transported over EAPoL (i.e., EAP over IP / UDP) look like. As shown in FIG. 7, MKA packet 700 includes a Layer 2 header 702, an IP header 704, a UDP header 706, an IEEE 802.1x header 708, and an MKA payload 710. A conventional MKA packet includes a Layer 2 header, an IEEE 802.1x header, and an MKA payload similar to the Layer 2 header 702, the IEEE 802.1x header 708, and the MKA payload 710 of FIG. 7, respectively. The new MKA packet 700 adds an IP header 704 and a UDP header 706 to enable the MKA packet 700 to be sent over IP / UDP at Layer 3. This Layer 3 MKA may be used to signal the appropriate security association key for MPLS encryption via some aspects of IEEE 802.1AE and IP encryption via some aspects of IEEE 802.1AE. MKA packet 700 sent over IP / UDP may be used to deliver an SAK that may be used for encryption of Layer 2.5 (MPLS) and / or Layer 3 (IP) packets.

[0120] EAP over IP / UDP can identify the MKA application across the network using a configurable UDP port. This UDP port may be configurable via a command line interface (CLI) or any other suitable means. An MKA packet 700 is generated with a UDP header 706, and the destination UDP port identified in the UDP header 706 is set to this configured UDP port. MKA packets 700 arriving at a destination RX node to this destination UDP port are identified and processed by the node, illustratively through the same conventional MKA code as any other MKA packet (i.e., EAPoL). The source UDP port identified in the UDP header 706 can be randomly assigned. Note that this destination UDP port may be a well-known port that will be assigned by the Internet Assigned Number Authority (IANA) in the future.

[0121] The source IP address identified in IP header 704 should be the IP address of the node that generated the MKA packet 700. As an example, in the case of MPLS and segment routing (SR), the source IP address is the IP address to which the SR label is advertised or the IP address to which the MPLS label is bound. The destination IP address identified in IP header 704 should be an IP address residing on the node where the LSP (MPLS tunnel) terminates. As previously explained, when the MKA packet 700 arrives at this destination IP address and the RX node inspects the destination UDP port and identifies the port to be assigned to the MKA process, the RX node processes the packet as an MKA to obtain an SAK.

[0122] As mentioned above, in MACsec, a Secure Channel Identifier (SCI) is used when there are multiple encrypted flows (e.g., VLANs) on a single port. Each VLAN must be uniquely identified to ensure the correct SAK is used to encrypt and decrypt the flow. In MACsec, the SCI is constructed from the port MAC and the VLAN ID.

[0123] Note that the SCI is optional and is only required if there are multiple flows on the same port, since each flow must be encrypted with a different key and a security channel identifier (SCI) for that key.

[0124] The SCI and its corresponding SAK are signaled between nodes, e.g., between the encryption node and the decryption node, via the MKA. With the same token, the SCI and its corresponding SAK are installed in the data path on both nodes. The encryption node uses the SAK to encrypt packets, and each encrypted packet has an IEEE 802.1AE header that includes the SCI. When the encrypted packet arrives at the decryption node, the decryption node reads the SCI in the IEEE 802.1AE header and uses the SCI to identify and apply the corresponding SAK to decrypt the encrypted packet.

[0125] In ANYSec, port MAC addresses or VLANs cannot be used to identify flows because they are MPLS or IP. ANYSec uses an encryption segment identifier (SID) to uniquely identify encryption nodes within the network. Therefore, this encryption SID can also uniquely identify encryption nodes within the SCI. There may be many different MPLS flows that need to be encrypted within this TX node. Therefore, a second identifier is used to uniquely identify flows within the node. As an example, this second identifier could be a tunnel ID or another unique identifier for that tunnel or IP flow. To ensure that the SCI does not collide with any other MAC addresses for MPLS or IP, the SCI can start with an invalid byte such as

[01] , which is a multicast MAC and is never used by MACsec.

[0126] In general, for MPLS and IP security via MKA and some aspects of IEEE 802.1AE, the SCI must uniquely identify the MPLS or IP flow to be secured and the node that is securing the tunnel.

[0127] In one possible embodiment, the 8-byte SCI has the following format: [01 RR RR RX XX XX YY YY] where each letter represents a 4-bit nibble, [RRRRR] are 20 reserved bits, [XXXXX] is a 20-bit local Ethernet Segment (ES) label, and [YYYY] is a 16-bit unique ID per encryption flow, generated locally, for example, on the encryption TX node. This is another reason why the encryption SID needs to uniquely identify per node or encryption group.

[0128] Although embodiments of the present disclosure have been described in the context of SAK distribution using MKA packets over Layer 2.5 MPLS transport or Layer 3 IP transport, the disclosure is not so limited. In general, the present disclosure can be implemented for distribution of any encryption key using MKA packets over any Layer 2.5 / 3 transport identified via a UPD port.

[0129] It will be understood that at least some of the functionality presented herein may be implemented in software (e.g., via implementation of the software on one or more processors for execution on a general-purpose computer (e.g., via execution by one or more processors) to provide a special-purpose computer), and / or in hardware (e.g., using a general-purpose computer, one or more application-specific integrated circuits, and / or any other hardware equivalents).

[0130] It will be understood that at least some of the functionality presented herein may be implemented in hardware, for example, as circuitry that cooperates with a processor to perform various functions. Portions of the functions / elements described herein may be implemented as a computer program product, where computer instructions, when processed by a computer, adapt the operation of the computer such that the methods and / or techniques described herein are invoked or otherwise provided. Instructions for invoking various methods may be stored on fixed or removable media (e.g., non-transitory computer-readable media), transmitted via a data stream in a broadcast or other signal-bearing medium, and / or stored in memory within a computing device that operates according to the instructions. The term "or" as used herein will be understood to refer to a non-exclusive "or" unless otherwise indicated (e.g., use of "or" or "or alternatively").

[0131] While various embodiments incorporating the teachings presented herein have been shown and described in detail herein, it will be understood that those skilled in the art could readily devise many other various embodiments which still incorporate these teachings.

Claims

1. A transmit (TX) node comprising at least one processor and at least one memory containing computer program code, The at least one memory and the computer program code are configured by at least one processor to transmit to the transmitting node at least: generating a MACsec (Media Access Control Security) Key Agreement (MKA) packet including a Layer 2 header, an IP (Internet Protocol) header, a UDP (User Datagram Protocol) header, and an IEEE 802.1x header, the payload of the MKA packet including an encryption key for encrypting a packet flow transmitted from the transmitting node to a receiving (RX) node; causing the receiving node to transmit the MKA packet over Layer 3 transport; the IEEE 802.1x header includes a Security Channel Identification (SCI) that uniquely identifies the packet flow and the encrypting sending node; The SCI includes an encryption segment identifier (SID) for identifying the encryption sending node and a unique identifier of a tunnel on the encryption sending node; The sending node: locally generating the unique identifier; A sending node that sends the SCI to the receiving node using an MKA over IP / UDP header.

2. 2. The sending node according to claim 1, wherein the encryption key is a Secure Association Key (SAK).

3. 3. The sending node of claim 2, wherein the sending node is configured to receive the SAK from a key server using Advanced Encryption Standard (AES) Key Wrap.

4. 2. The sending node of claim 1, wherein the sending node is configured to encrypt the encryption key in the MKA packet using AES Key Wrap.

5. 2. The transmitting node of claim 1, wherein the transmitting node uses the encryption key to encrypt packets of the packet flow and transmits the encrypted packets to the receiving node via Layer 2.5 / 3 transport.

6. 6. The sending node of claim 5, wherein the Layer 2.5 / 3 transport is a Layer 2.5 Multi-Protocol Label Switching (MPLS) transport.

7. 6. The sending node of claim 5, wherein the layer 2.5 / 3 transport is a layer 3 Internet Protocol (IP) transport.

8. 2. The sending node of claim 1, wherein the Layer 3 transport is an IP transport.

9. A receive (RX) node comprising at least one processor and at least one memory containing computer program code, The at least one memory and the computer program code are configured to, using at least one processor, cause the receiving node to: receiving, from a transmitting (TX) node via Layer 3 transport, an MKA (Media Access Control Security) Key Agreement (MACsec) packet including a Layer 2 header, an Internet Protocol (IP) header, a User Datagram Protocol (UDP) header, and an IEEE 802.1x header, the payload of the MKA packet including an encryption key for decrypting a packet flow transmitted from the transmitting node to the receiving node; processing the MKA packet to obtain the encryption key; the IEEE 802.1x header includes a Security Channel Identification (SCI) that uniquely identifies the packet flow and the encrypting sending node; The SCI includes an encryption segment identifier (SID) for identifying the encryption sending node and a unique identifier of a tunnel on the encryption sending node; The receiving node is configured to receive the SCI from the sending node using an MKA over IP / UDP header.

10. 10. The receiving node of claim 9, wherein the encryption key is a SAK.

11. 10. The receiving node of claim 9, wherein the encryption key is encrypted within the MKA packet using AES Key Wrap.

12. receiving encrypted packets of the packet flow from the sending node via Layer 2.5 / 3 transport; 10. The receiving node of claim 9, wherein the receiving node uses the encryption key to decrypt the encrypted packet.

13. 13. The receiving node of claim 12, wherein the layer 2.5 / 3 transport is a layer 2.5 MPLS transport.

14. 13. The receiving node of claim 12, wherein the layer 2.5 / 3 transport is a layer 3 IP transport.

15. 10. The receiving node of claim 9, wherein the Layer 3 transport is an IP transport.

16. generating, by a transmitting (TX) node, a Media Access Control Security (MACsec) Key Agreement (MKA) packet including a Layer 2 header, an Internet Protocol (IP) header, a User Datagram Protocol (UDP) header, and an IEEE 802.1x header, the payload of the MKA packet including an encryption key for encrypting a packet flow transmitted from the transmitting node to a receiving (RX) node; transmitting, by the transmitting node, the MKA packet to the receiving node via Layer 3 transport; the IEEE 802.1x header includes a Security Channel Identification (SCI) that uniquely identifies the packet flow and the encrypting sending node; The SCI includes an encryption segment identifier (SID) for identifying the encryption sending node and a unique identifier of a tunnel on the encryption sending node; The sending node: locally generating the unique identifier; The method of claim 1, further comprising transmitting the SCI to the receiving node using an MKA over IP / UDP header.

17. receiving, by a receiving (RX) node from a transmitting (TX) node via Layer 3 transport, an MKA (Media Access Control Security) Key Agreement (MACsec) packet including a Layer 2 header, an Internet Protocol (IP) header, a User Datagram Protocol (UDP) header, and an IEEE 802.1x header, the payload of the MKA packet including an encryption key for decrypting a packet flow transmitted from the transmitting node to the receiving node; and processing, by the receiving node, the MKA packet to obtain an encryption key; the IEEE 802.1x header includes a Security Channel Identification (SCI) that uniquely identifies the packet flow and the encrypting sending node; The SCI includes an encryption segment identifier (SID) for identifying the encryption sending node and a unique identifier of a tunnel on the encryption sending node; The method of claim 1, wherein the receiving node is configured to receive the SCI from the sending node using an MKA over IP / UDP header.

Images