Securing packet headers

Abstract

A method performed by a first network node (1900) is disclosed. The method comprises signing (202) at least a first portion of a first header of a transport packet to generate a first signature. The method further comprises transmitting (204) the transport packet comprising the first header to a second network node (2000). The first header comprises: the at least first portion; the first signature; and a second portion comprising a first indication that the first signature is associated with the at least first portion.

Description

[0001] Securing Packet Headers

[0002] Technical field

[0003] Embodiments of the present disclosure relate to securing headers of transport packets, and particularly to methods, apparatuses, and computer-readable media for securing the headers of transport packets.

[0004] Background

[0005] In Radio Access Network (RAN) packet transport networks, multiple simultaneous packet sessions may be ongoing between Medium Access Control (MAC) endpoints or Internet Protocol (IP) endpoints. Each packet session may comprise multiple streams of RAN transport packets (referred to herein as RAN packet streams). The RAN packet streams may have various transport characteristic needs relating, for example, to bitrate, delay, delay variation, drop sensitivity etc.

[0006] The evolution of RANs and mobility services (e.g., Ultra-Reliable Low Latency Communications (URLLC) and Network Reliability, Availability and Redundancy (NRAR)) has increased the need for resilience in RAN packet transport networks. As such, RAN packet transport networks are evolving from simple direct links to more capable, meshed packet transport networks.

[0007] Furthermore, new services (e.g., slicing) and evolved traffic principles (e.g., User Equipment (UE) centric packet stream data) have increased the need for improved RAN packet transport handling.

[0008] Another important aspect of more advanced RAN transport networks is transport security and encryption of traffic.

[0009] In L2 and L3 fronthaul, midhaul, sidehaul, and / or backhaul networks, it is complicated for a Switch / Router (SWR) to identify RAN packet stream data; RAN header data is inserted deep into the packet header. Therefore, the RAN header data is difficult for the SWR to parse (e.g., due to the internal nature of the RAN packet header, possible encryption of the data, etc.).

[0010] In Ethernet or IP RAN packet transport networks (e.g., with a single source / destination address, or just a few source / destination addresses), there are too few known parameters that can be used for controlled traffic distribution or traffic engineering (also referred to herein as “traffic steering”) of packet streams over alternative links between equipment or paths between endpoints in the network. For example, whilst existing technology can be used to calculate a hash on visible (i.e., non-encrypted) packet headers which can be used to distribute packet streams, there are too few unique parameters to hash on for the distribution to be optimal. For example, there is a risk of “elephant flows”, meaning that some links or paths become overloaded whilst others are underutilized, and controlled steering and distribution of the packet streams is limited.

[0011] Controlled traffic distribution and traffic engineering is made more difficult by the fact that, when encryption is applied to RAN packet streams, the headers of the transport packets are no longer visible to the RAN and transport network equipment. Therefore, the RAN and transport network equipment cannot identify packet streams based on the encrypted headers nor act accordingly. This means that RAN nodes are unable to perform first level internal steering of RAN packet streams towards RAN processing elements (e.g., multiple Service Access Points (SAPs)) without first performing decryption of the RAN packet headers.

[0012] A solution to the above problem(s) is to include, in a transport packet, non-encrypted packet headers and / or additional traffic engineering headers such as segment routing headers for IPv6 (as described in Internet Engineering Task Force (IETF) Request For Comments (RFC) 8200, entitled “Internet Protocol, Version 6 (IPv6) Specification”) or headers for Multiprotocol Label Switching (MPLS).

[0013] Adding visible (i.e., un-encrypted) (Ethernet or IP) stream identifiers to a RAN packet stream allows the stream to be identified in a RAN transport network and internally in RAN equipment. This in turn improves RAN traffic handling, particularly traffic engineering of transport packets and load distribution of transport packet networks.

[0014] However, including visible fields in a RAN packet header (for readability purposes) compromises the security of the packet headers; any header data that is visible for the purposes of traffic steering / distribution is exposed to attacks. For example, visible stream identifiers or traffic engineering information in a transport packet may be manipulated, or new packets may be injected with malicious packet headers. These security issues cannot be dealt with using existing security protocols (e.g. IPsec) as they are only designed to protect the payload part of a packet via signing or encryption, and do not protect the packet headers.

[0015] Embodiments of the present disclosure solve this security problem by providing a signature mechanism for packet headers (e.g., Stream ID headers or traffic engineering headers). Adding a signature to / for any visible parts of a packet header allows the visible parts to be authenticated to determine whether they have been tampered with. Therefore, the signature mechanism enables selective parts of packet headers to be both visible and secured. Here, the term “secured” is interchangeable with phrases such as “authenticated”, “integrity checked”, and / or “untampered with”.

[0016] According to a first aspect of the present disclosure, there is provided a method performed by a first network node. The method comprises signing at least a first portion of a first header of a transport packet to generate a first signature; and transmitting the transport packet comprising the first header to a second network node. The first header comprises: the at least first portion; the first signature; and a second portion comprising a first indication that the first signature is associated with the at least first portion.

[0017] According to a second aspect of the present disclosure, there is provided a method performed by a second network node. The method comprises receiving, from a first network node, a transport packet including a first header. The first header includes: a first signature, and a second portion comprising a first indication that the first signature is associated with at least a first portion of the first header. The method further comprises determining an authenticity of the at least first portion based on the first signature.

[0018] According to a third aspect of the present disclosure, there is provided a method performed by a first network node. The method comprises signing at least a first portion of a first header of a transport packet to generate a first signature. The at least first portion comprises an identifier associated with a stream of the transport packet. The method further comprises transmitting the transport packet comprising the first header to a second network node. The first header comprises: the at least first portion; and the first signature.

[0019] According to a fourth aspect of the present disclosure, there is provided a method performed by a second network node. The method comprises receiving, from a first network node, a transport packet including a first header. The first header includes: a first signature. The first signature is associated with at least a first portion of the first header comprising an identifier associated with a stream of the transport packet. The method further comprises determining an authenticity of the at least first portion based on the first signature.

[0020] According to a fifth aspect of the present disclosure, there is provided a first network node. The first network node comprises processing circuitry configured to cause the first network node to perform any embodiment of the first and / or third aspect.

[0021] According to a sixth aspect of the present disclosure, there is provided a second network node. The second network node comprises processing circuitry configured to cause the second network node to perform any embodiment of the second and / or fourth aspect.

[0022] According to a seventh aspect of the present disclosure, there is provided a computer program product comprising a computer readable medium having computer readable code embodied therein. The computer readable code is configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform embodiments of any of the first, second, third, and / or fourth aspects.

[0023] Certain embodiments may provide one or more of the following technical advantage(s). Packet stream identifiers included in transport packets (of a packet stream) are used to perform explicit traffic steering and distribution of the packet stream both in RAN transport networks and in RAN endpoints. Traffic steering and distribution enables the characteristic needs of respective RAN packet streams to be met, particularly those associated with RAN services such as slicing and evolved RAN connection principles such as UE-centric packet streams. Packet stream identifiers also enable a more efficient utilization of a RAN transport network’s resources and lowers the Operating Expense (OPEX) of RAN packet transport networks.

[0024] However, the packet stream identifiers are necessarily visible (i.e. , non-encrypted) in the RAN transport network and at switching functions of RAN endpoints receiving the packet stream (even if encryption is applied to the RAN packet stream as a whole). This introduces a security risk, as the stream identifier (or, for example, other header portions such as those including traffic engineering information) may be manipulated, or new packets may be injected with malicious packet headers. By signing the visible packet stream identifier (and / or other portions or fields of a header), network nodes (e.g., intermediate network nodes along a transport path) receiving the transport packet are able to determine whether headers have been signed by a trusted source node, in order to authenticate / verify whether the header has been tampered with. This helps improve network security whilst still enabling headers of transport packets to include visible portions (such as stream identifies). Furthermore, as the intermediate network nodes do not need to decrypt entire packets to perform this authentication / verification, network latency is reduced. In embodiments of the present disclosure, the payload of a RAN packet stream may only be encrypted / decrypted at the endpoints of a transport path, meaning the intermediate network nodes do not need to be involved in encryption key exchange between said endpoints.

[0025] Embodiments of the present disclosure are not limited to the signing of stream identifiers included in a header of a transport packet only. The advantages of improved security and reduced network latency are realised when any non-secured portion of a transport packet header is signed.

[0026] Brief description of the drawings

[0027] For a better understanding of examples of the present disclosure, and to show more clearly how the examples may be carried into effect, reference will now be made, by way of example only, to the following drawings in which:

[0028] Figure 1 is a schematic diagram illustrating external transport domains of a RAN; Figure 2 is a flowchart showing a method performed by a first network node in accordance with embodiments of the disclosure;

[0029] Figure 3 is a schematic diagram illustrating a first ethernet signature TAG; Figure 4 is a schematic diagram illustrating a first ethernet signature TAG; Figure 5 is a schematic diagram illustrating a second ethernet signature TAG; Figure 6 is a schematic diagram illustrating a first IPv6 Extension header;

[0030] Figure 7 is a schematic diagram illustrating a second IPv6 Extension header;

[0031] Figure 8 is a flowchart showing a method performed by a first network node in accordance with embodiments of the disclosure;

[0032] Figure 9 is a schematic diagram illustrating a third ethernet signature TAG; Figure 10 is a schematic diagram illustrating a third IPv6 Extension header; Figure 1 1 is a schematic diagram illustrating a fourth ethernet signature TAG; Figure 12 is a schematic diagram illustrating a fourth IPv6 Extension header; Figure 13 is a flowchart showing a method performed by a second network node in accordance with embodiments of the disclosure;

[0033] Figure 14 is a flowchart showing a method performed by a second network node in accordance with embodiments of the disclosure;

[0034] Figures 15 to 18 are signalling diagrams illustrating methods for determining the authenticity of a transport packet according to embodiments of the present disclosure;

[0035] Figure 19 is a schematic diagram of a first network node in accordance with embodiments of the disclosure;

[0036] Figure 20 is a schematic diagram of a second network node in accordance with embodiments of the disclosure; and

[0037] Figure 21 is a schematic diagram of a virtualization environment in which embodiments of this disclosure can be implemented.

[0038] Detailed description

[0039] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein. The disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0040] Figure 1 illustrates external transport domains of a RAN. The external domains may include one or more of: a backhaul domain 102 connecting a mobile core 104 to a virtual Centralized Unit (vCU) 106; a midhaul domain 108 connecting the vCU 106 and a first virtual Distributed Unit (vDU) / Distributed Unit (DU) 1 10; a fronthaul domain 112 connecting the first vDU / DU 1 10 and a Radio Unit (RU) 114; and a sidehaul domain 1 16 connecting the first vDU / DU 1 10 and a second vDU / DU 118. In embodiments of the present disclosure, the RAN traffic (e.g., packet streams) may belong to the fronthaul 112 and sidehaul 1 18 domains.

[0041] As RAN packet networks (such as the network illustrated in Figure 1 ) evolve towards more advanced transport topologies, there is a need to distribute RAN packet streams over multiple links between RAN-Transport and Transport-Transport entities, and to perform steering of RAN packet streams over alternative paths in the RAN packet transport network. However, confidentiality and integrity requirements of packet data mean that transport packets are encrypted. This hides RAN packet header information, including any RAN packet stream identifiers included in the packet header that are used to identify the RAN packet stream for the purposes of RAN packet stream handling. Furthermore, the RAN packet stream identifier enables first level RAN packet stream steering within a RAN entity towards an applicable RAN processing element (e.g., a SAP, of which there may be multiple in a RAN entity) without having to first perform decryption of the transport packet. The SAP may be the security processing entity, and can be identified and steered towards.

[0042] Therefore, if the RAN packet stream identifier is made visible (i.e., left un-encrypted), the RAN packet transport network will have improved traffic distribution and reduced latency.

[0043] Embodiments of the present disclosure address the security issues associated with visible stream identifiers by providing a mechanism that enables selective parts of a RAN packet stream header (or other types of packet headers) to be signed such that they can be authenticated and checked for tampering.

[0044] For example, embodiments of the present disclosure enable a network node to determine the authenticity and integrity of a (IP or ethernet) RAN packet stream identifier and / or other (IP or ethernet) headers that are visible (i.e., non-encrypted). In particular embodiments, an IPv6 extension header or ethernet header may comprise a signature. For example, an ethernet header may be signed using an ethernet ethertype TAG. A header of the packet may comprise, in addition to the signature, a "signature type” or “sign type” field indicating what signature algorithm was used to sign the header, and a ’’signed”, ’’sign”, or ’’signature” field indicating what header fields are signed.

[0045] In other words, in embodiments of the present disclosure, at least a first portion of a packet header is signed by a source (sender) network node and transmitted to other (receiver) network nodes along a transport path. The receiver network nodes may then verify the signed portion(s) of the packet header.

[0046] In some embodiments, the receiver network nodes may (re)-sign at the at least first portion of the packet header, after the at least first portion has (optionally) been modified (e.g., if the at least first portion has changed during transport). Whilst embodiments of the present disclosure may focus on the signing of portions of ethernet and IPv6 packet headers, it should be appreciated that they can also be used to add a signature to any non-secured portions of main packet headers (e.g., by adding information on fields included in the signature calculation).

[0047] Figure 2 is a flowchart showing a method in accordance with embodiments of the disclosure. The method may be performed by a first network node (e.g., the first network node 1900 illustrated in figure 19).

[0048] The method may begin at step 202, with the first network node signing at least a first (e.g., un-encrypted) portion of a first header of a transport packet to generate a first signature. Signing the at least first portion may be performed using a first signature algorithm (or process).

[0049] For example, as discussed in more detail below in reference to Figures 15 and 17, Public Key Infrastructure (PKI) and asymmetric signing algorithms may be used to sign the at least first portion. In such embodiments, existing PKI may be used to manage / distribute Public Key (certificates) to nodes in a RAN transport network (e.g., the nodes along a particular transport path) so that network nodes receiving the signed at least first portion can determine the authenticity and integrity of the signed header(s).

[0050] Alternatively, as discussed in more detail below in reference to Figures 16 and 18, Internet Key Exchange (IKE) infrastructure (as described in IETF RFC 7296, entitled “Internet Key Exchange Protocol Version 2 (IKEv2)”) may be used to sign the at least first portion. In such embodiments, existing IKE infrastructure may be used by network nodes in a RAN transport network (e.g., the nodes along a particular transport path) to exchange keys so that network nodes receiving the signed at least first portion can determine the authenticity and integrity of the signed header.

[0051] The at least a first portion may comprise one or more fields of the transport header. For example, the at least first portion may comprise an identifier associated with a stream of the transport packet (e.g., a Stream-ID (when the transport packet is for an Ethernet packet stream, or an IPv6 Flow label when the transport packet is for an IP packet stream). In other examples, the at least first portion may comprise one or more fields indicating any one or more of: a source IP address; a destination IP address; a class; a Segment Routing (SR) Segment Identifier (SID) list; an SR-MPLS SID list; a source MAC address; a destination MAC address; a Virtual Local Area Network (VLAN); a stream identifier (e.g., a Stream-ID); a source address; a destination address; an SR with IPv6 (SRv6) SID list; and an MPLS label stack.

[0052] At step 204, the first network node transmits the transport packet comprising the first header to a second network node (e.g., the second network node 2000 illustrated in figure 20). The first header comprises: the at least first portion; the first signature (e.g., a digital signature, such as those discussed below in relation to Figures 3 - 7 and 9 - 12); and a second portion comprising a first indication that the first signature is associated with the at least first portion. In some embodiments, the second portion defines what fields of the first header are signed. For example, the second portion (which may also be referred to as a “sign”, “signed”, or “signature” field) may correspond to the sign / signed / signature fields discussed below in relation to Figures 3 - 7 and 9 - 12.

[0053] To indicate that the first signature is associated with the at least first portion, the second portion may utilise a first mapping. For example, the first indication may comprise one of: a value or a set bit position in a bit string. The first indication may then be mapped to the at least first portion in a first mapping.

[0054] The second portion may be a field of the packet header. Whilst embodiments of the second portion are discussed below in which the second portion is an 8 bit field, the second portion may be of any size (e.g., 4 bits).

[0055] In some embodiments, 16 values (4 bits) of the second portion may be mapped to signed portions (e.g., signed fields) of the first header according to the following configuration: Value 0: Reserved; Values 1 -15: Represent respective combinations of or individual signed fields.

[0056] Alternatively, 256 values of the second portion may be mapped to different signed portions (e.g., signed fields) of the first header according to the following configuration: Value 0: Reserved; Values 1 -255: Represent combinations of or individual signed fields. In some embodiments, the signed fields may indicate any one of more of the following (particularly when the first header is for an IP stream): a Source IP address; a Destination IP address; a Flow Label; a Class; a Segment Routing SID-list; and an SR-MPLS SID- list.

[0057] In other embodiments, the signed fields may indicate any one of more of the following (particularly when the first header is for an ethernet stream): a Source MAC address; a Destination MAC address; a VLAN; a Stream-ID; and a Class.

[0058] A first example of a first mapping (utilizing 16 values of the second portion) is suitable for IP packet streams and is as follows: Value 0: Reserved; Value 1 : Source IP; address, Destination IP address, Flow Label, Class; Value 2: Source IP address, Flow Label, Class; Value 3: Source IP address, Flow Label; Value 4: Flow Label; Value 5: Source IP address; Value 6: Source IP address, Flow Label, Class, Segment Routing SID-list; Value 7: SR-MPLS SID-list; Values 8-15: additional alternatives.

[0059] If the first mapping utilizes 256 values of the second portion, the first example may be modified such that Values 8-255 indicate the additional alternatives.

[0060] A second example of the first mapping (utilising 16 values of the second portion) is suitable for Ethernet packet streams and is as follows: Value 0: Reserved; Value 1 : Source MAC address, Destination MAC address, VLAN, Stream-ID, Class; Value 2: Source MAC address, Destination MAC, VLAN, Stream-ID; Value 3: Source MAC address, Destination MAC address, Stream-ID; Value 4: Source MAC address, Stream- ID; Value 5: Stream-ID; Value 6: Source MAC address; Value 7-15: additional alternatives.

[0061] If the first mapping utilizes 256 values of the second portion, the second example may be modified such that Values 7-255 indicate the additional alternatives.

[0062] A third example of the first mapping (utilising 8 bits of the second portion) is as follows: Bit 0: Source address; Bit 1 : Destination address; Bit 2: VLAN-ID(s); Bit 3: Flow- label / Stream-ID; Bit 4: Class; Bit 5: Segment Routing SID list; Bit 6: SR-MPLS SID-list; Bit 7: Reserved. In order to configure the first network node and / or the second network node with the first mapping, the method of figure 2 may further comprise the first network node performing one of: receiving the first mapping from the second network node; transmitting the first mapping to the second network node; and negotiating the first mapping with the second network node. For example, the first network node may determine and transmit the first mapping to the second network node, such that the first mapping is consistent between the first network node and the second network node, or vice versa. In some examples, both the first network node and the second network node are configured with the same first mapping by another network node.

[0063] If the at least first portion has been signed using a first signature algorithm, the first header may further comprise a third portion comprising a second indication of the first signature algorithm. In some embodiments, the third portion may define the type of signature included in the first header. For example, the third portion (which may also be referred to as a “sign type” or “signature type” field) may correspond to the sign type / signature type fields discussed below in relation to Figures 3 - 7 and 9 - 12.

[0064] To indicate the first signature algorithm, the third portion may utilize a second mapping. For example, the second indication may comprise one of: a value or a set bit position in a bit string. The second indication may then be mapped to the first signature algorithm in a second mapping.

[0065] The third portion may be a field of the packet header. Whilst embodiments of the third portion are discussed below in which the third portion is an 8 bit field, the third portion may be of any size (e.g., 4 bits).

[0066] In some embodiments, 16 values (4 bits) of the third portion may be mapped to different signature types according to the following configuration: Value 0: Reserved; Values 1 - 15: Represents respective signature types.

[0067] Alternatively, 256 values (8 bits) of the third portion may be mapped to different signature types according to the following configuration: Value 0: Reserved; Values 1 -255: Represent respective signature types. The different signature types may comprise any one of more of the following (particularly when the first header is for an IP packet stream or Ethernet packet stream): a SHA 128 bit; a HMAC-SHA 128; a HMAC-SHA 256; a RSA 1024; and an ED 25519.

[0068] A first example of the second mapping (utilising 16 values of the third portion) may be suitable for IP packet streams or ethernet packet streams and is as follows:

[0069] Value 0: Reserved; Value 1 : SHA 128 bit; Value 2: HMAC-SHA 128; Value 3: HMAC- SHA 256; Value 4: RSA 1024; Value 5: ED 25519; Values 6-15: additional variants.

[0070] If the second mapping utilizes more of the 256 values of the third portion, the first example may be modified such that more of the Values 6-255 indicate the additional variants.

[0071] A second example of the second mapping (utilising 8 bits of the third portion) is suitable for IP packet streams or ethernet packet streams and is as follows: Bit 0: SHA 128 bit; Bit 1 : HMAC-SHA 128; Bit 2: HMAC-SHA 256; Bit 3: RSA 1024; Bit 4: ED 25519; Bit 5: Reserved; Bit 6: Reserved; Bit 7: Reserved

[0072] In order to configure the first network node and / or second network node with the second mapping, the method of figure 2 may further comprise the first network node performing one of: receiving the second mapping from the second network node; transmitting the second mapping to the second network node; and negotiating the second mapping with the second network node. For example, the first network node may determine and transmit the second mapping to the second network node, such that the second mapping is consistent between the first network node and the second network node, or vice versa. In some examples, both the first network node and the second network node are configured with the same second mapping by another network node.

[0073] An example of the first header is provided in Figure 3. Figure 3 is a schematic diagram illustrating a first ethernet header 300 signed using a signature TAG. A stream identifier (e.g., an ethernet RAN packet stream identifier) and / or other non-secured portions (e.g., fields) of the of the first ethernet header 300 may be signed using an ethernet TAG (ethertype).

[0074] The first ethernet header 300 comprises: a signature 302 (corresponding to the first signature) that may also be referred to as a “digital signature”; a sign field 304 (corresponding to the second portion) that may also be referred to as a “signed” or “signature” field and defines the fields of the first header that are signed; a sign type field 306 (corresponding to the third portion) and may also be referred to as a “signature type” field and defines the type of signature; an ethertype field 308, which defines the TAG type; and a reserved field 310, which is reserved for future use.

[0075] Figure 4 is a schematic diagram that also illustrates the first ethernet header 300, but provides examples sizes of each field. In particular, the signature 302 may be 256 bits; the sign field 304 may be 4 bits; the sign type field 306 may be 4 bits; the Ethertype field 308 may be 16 bits; and / or the reserved field 310 may be 8 bits.

[0076] Another example of the first header is provided in Figure 5. Figure 5 is a schematic diagram illustrating a second ethernet header 500 signed using a signature TAG. A stream identifier (e.g., an ethernet RAN packet stream identifier) and / or other nonsecured portions (e.g., fields) of the second ethernet header 500 may be signed.

[0077] The second ethernet header 500 comprises: a signature 502 (e.g., 256 bits) (corresponding to the first signature) that may also be referred to as a “digital signature”; a sign field 504 (e.g., 8 bits) (corresponding to the second portion) that may be referred to as a “signed” or “signature” field and defines the fields of the first header that are signed; a sign type field 506 (e.g., 8 bits) (corresponding to the second indication) that may also be referred to as a “signature type” field and defines the type of signature; and an Ethertype field 508 (e.g., 16 bits) that defines the TAG type.

[0078] Another example of the first header is provided in Figure 6. Figure 6 is a schematic diagram illustrating a first IPv6 extension header 600. A stream identifier (e.g., an IPv6 RAN packet stream identifier) and / or other non-secured portions (e.g., fields) of the first IPv6 extension header 600 may be signed.

[0079] The first IPv6 extension header 600 comprises: a signature 602 (e.g., 256 bits) (corresponding to the first signature) that may be referred to as a “digital signature”; a sign field 604 (e.g., 4 bits) (corresponding to the second portion) that may be referred to as a “signed” or “signature” field and defines the fields of the first header that are signed; a sign type field 606 (e.g., 4 bits) (corresponding to the third portion) that may be referred to as a “signature type” field and defines the type of signature; a next header field 608 (e.g., 8 bits), which may be the default next header for IPv6 extension headers; a header extension length field 610 (e.g., 8 bit), which may be the default header extension length for IPv6 extension headers; and a reserved field 612 (e.g., 8 bit), which is reserved for future use.

[0080] Another example of the first header is provided in Figure 7. Figure 7 is a schematic diagram illustrating a second IPv6 extension header 700. A stream identifier (e.g., an IPv6 RAN packet stream identifier) and / or other non-secured portions (e.g., fields) of the second IPv6 extension header 700 may be signed.

[0081] The second IPv6 extension header 700 comprises: a signature 702 (e.g., 256 bits) (corresponding to the first signature) that may also be referred to as a “digital signature”; a sign field 704 (e.g., 8 bits) (corresponding to the second portion) that may be referred to as a “signed” or “signature” field and defines the fields of the first header that are signed; a sign type field 706 (e.g., 8 bits) (corresponding to the third portion) that may be referred to as a “signature type” field and defines the type of signature; a next header field 708 (e.g., 8 bits), which may be the default next header for IPv6 extension headers; and a header extension length field 710 (e.g., 8 bits) which may be the default header extension length for IPv6 extension headers.

[0082] In Figures 3 to 7, the sign fields 304, 504, 604, 704 may be configured according to a first mapping (e.g., according to any of the above discussed examples of the first mapping). Similarly, the sign type fields 306, 506, 606, 706 may be configured according to a second mapping (e.g., according to any of the above discussed examples of the second mapping).

[0083] However, in some embodiments of the present disclosure, the second portion is not included in the first header. For example, the first network node and the second network node may be configured to assume that the at least first portion comprises specific portions of the header, for example, the identifier associated with a stream of the transport packet, meaning resources in the first header may be conserved by omitting the second portion.

[0084] Figure 8 is a flowchart showing a method in accordance with embodiments of the disclosure, wherein the second portion may be omitted from the first header. The method may be performed by the first network node (e.g., the first network node 1900 illustrated in figure 19). The method may begin at step 802 with the first network node signing at least a first (e.g., un-encrypted) portion of a first header of a transport packet to generate a first signature.

[0085] The at least first portion comprises an identifier associated with a stream of the transport packet. For example, the transport packet may be for an Ethernet packet stream, and the at least first portion may comprise a Stream-ID. In another example, the transport packet may be for an IP packet stream, and the at least first portion may comprise an IPv6 Flow label.

[0086] Signing the at least first portion may be performed using a first signature algorithm (e.g., using existing PKI or IKE infrastructure, as discussed above in relation to Figure 2).

[0087] At step 804, the first network node transmits the transport packet comprising the first header to a second network node (e.g., the second network node 2000 illustrated in figure 20). The first header comprises: the at least first portion; and the first signature.

[0088] The first header may further comprise a second portion comprising a first indication that the first signature is associated with the at least first portion, if the at least first portion further comprises any other fields discussed herein or for improved robustness (e.g., the header fields discussed in relation to Figures 2 and 13). The second portion may define what fields of the first header are signed. For example, the second portion (which may also be referred to as a “sign”, “signed” or “signature” field) may correspond to the second portion discussed in relation to Figure 2, and / or the sign / signed / signature fields discussed in relation to Figures 3 - 7 and 9 - 12.

[0089] To indicate that the first signature is associated with the at least first portion, the second portion may utilise any of the first mapping embodiments discussed above in relation to figure 2.

[0090] If the at least first portion has been signed using a first signature algorithm, the first header may further comprise a third portion comprising a second indication of the first signature algorithm. In some embodiments, the third portion may define the type of signature included in the first header. For example, the third portion (which may also be referred to as a “sign type” or “signature type” field) may correspond to the third portion discussed in relation to Figure 2, and / or to the sign type / signature type fields discussed in relation to Figures 3 - 7 and 9 - 12.

[0091] To indicate the first signature algorithm, the third portion may utilise any of the second mapping embodiments discussed above in relation to figure 2.

[0092] An example of the first header without the second portion is provided in Figure 9. Figure 9 is a schematic diagram illustrating a third ethernet header 900 signed using a signature TAG. A stream identifier (e.g., an ethernet RAN packet stream identifier) and (optionally) other non-secured portions (e.g., fields) of the third ethernet header 900 may be signed.

[0093] The third ethernet header 900 comprises: a signature field 902 (e.g., 256 bits) (corresponding to the first signature) that may also be referred to as a “digital signature”; a sign type field 904 (e.g., 4 or 8 bits) (corresponding to the third portion) that may be referred to as a “signature type” field and defines the type of signature; an ethertype field 906 (e.g.,16 bits) that defines the TAG type; and a reserved field 908, which is reserved for future use.

[0094] Another example of the first header without the second portion is provided in Figure 10. Figure 10 is a schematic diagram illustrating a third IPv6 extension header 1000. A stream identifier (e.g., an IPv6 RAN packet stream identifier) and (optionally) other nonsecured portions (e.g., fields) of the third IPv6 extension header 1000 may be signed.

[0095] The third IPv6 extension header 1000 comprises: a signature 1002 (e.g., 256 bits) (corresponding to the first signature) that may also be referred to as a “digital signature”; a sign type field 1004 (e.g., 4 or 8 bits) (corresponding to the third portion) that may be referred to as a “signature type” field and defines the type of signature; a next header field 1006 (e.g., 8 bits), which may be the default next header for IPv6 extension headers; a header extension length field 1008 (e.g., 8 bits), which may be the default header extension length for IPv6 extension headers; and a reserved field 1010 (e.g., 8 or 12 bits), which is reserved for future use.

[0096] In all of the above discussed embodiments, the headers may have version handling capabilities. For example, the first header may be able to identify the version of the first header and / or versions of any one or more fields of the first header. This may include indicating any one or more of: a version of a signature type indicated by the signature type field, a version of a signed field indicated by the sign field, and a size of a field included in the first header (e.g., the sign field and / or signature type field). For example, a particular version of the first header may indicate the fields included in the first header (e.g., fields relating to the above discussed embodiments for signing headers), the sizes of the fields included in the first header, etc.

[0097] Version handling can increase the security of the first header; certain signature types may not be valid and / or should not be trusted. Therefore, the presence of the first signature should not be taken as an indication / used to determine that the at least first portion is authentic.

[0098] Version handling can also be used to ensure the first header is compatible with future protocols and standards; enabling the first header to identify the version of an indicated signature type and indicated signed fields allows new signature types / fields to be used for the signing of the first header. For example, the lists of allowed / accepted / trusted signature types and signed fields can be updated and / or changed to include new signature types and signed fields, and remove unallowed / unaccepted / non-trusted signature types and signed fields.

[0099] Version handling can also be used to ensure the structure of the first header is flexible; enabling the first header to identify the version of the protocol in use and / or the version of the first header allows the structure (e.g., the included fields, the sizes of the included fields, etc) of the first header to be changed. For example, version handling can be used to account for changes to the structure of standardised headers, such as IPv6 extension headers and / or ethernet signature TAGs used for signing headers.

[0100] Version handling can be applied to any of the headers in Figures 3 - 7, 9, and 10 by modifying them to include a “version” field.

[0101] An example of the first header with version handling is provided in Figure 11 . Figure 1 1 is a schematic diagram illustrating a fourth ethernet header 1100 signed using a signature TAG. A stream identifier (e.g., an ethernet RAN packet stream identifier) and / or other non-secured portions (e.g., fields) of the fourth ethernet header 1100 may be signed. The fourth ethernet header 1100 comprises: a signature 1 102 (e.g., 256 bits) (corresponding to the first signature) that may also be referred to as a “digital signature”; a sign field 1 104 (e.g., 4 or 8 bits) (corresponding to the second portion) that may also be referred to as a “signed” or “signature” field and defines the fields of the first header that are signed; a sign type field 1 106 (e.g., 5 bits) (corresponding to the third portion) that may be referred to as a “signature type” field and defines the type of signature; an ethertype field 1108 (e.g.,16 bit) that defines the TAG type; and a version field 11 10 (e.g., 3 bit), which defines a version of the first header and / or a version of any one of the first header fields (e.g., a version of the sign type field 1106 and / or the sign field 1 104).

[0102] Another example of the first header with version handling is provided in Figure 12. Figure 12 is a schematic diagram illustrating a fourth IPv6 extension header 1200. A stream identifier (e.g., an IPv6 RAN packet stream identifier) and / or other non-secured portions (e.g., fields) of the fourth IPv6 extension header 1200 may be signed.

[0103] The fourth IPv6 extension header 1200 comprises: a signature 1202 (e.g., 256 bits) (corresponding to the first signature) that may be referred to as a “digital signature”; a sign field 1204 (e.g., 4 or 8 bits) (corresponding to the second portion) that may also be referred to as a “signed” or “signature” field and defines the fields of the first header that are signed; a sign type field 1206 (e.g., 5 bits) (corresponding to the third portion) that may be referred to as a “signature type” field and defines the type of signature; a next header field 1208 (e.g., 8 bits), which may be the default next header for IPv6 extension headers; a header extension length field 1210 (e.g., 8 bits), which may be the default header extension length for IPv6 extension headers; and a version field 1212 (e.g., 3 bits), which defines a version of the first header and / or a version of any one of the first header fields (e.g., a version of the sign type field 1206 and / or the sign field 1204).

[0104] As with the headers in figures 3 - 7, 9, and 10, the values or bits of the sign fields 1 104, 1204 may be mapped to different portions / fields of the first header according to a first mapping. The first mapping may be any of the first mappings discussed herein.

[0105] Similarly, as with the headers in figures 3 - 7, 9, and 10, the values or bits of the sign type fields 1106, 1206 may be mapped to different signature types according to a second mapping. The second mapping may be any of the second mappings discussed herein. However, a fourth example of the second mapping (utilizing 32 values of a 5 bit signature type field) is as follows: Value 0: Reserved; Value 1 : SHA 128 bit; Value 2: HMAC-SHA 128; Value 3: HMAC-SHA 256; Value 4: RSA 1024; Value 5: ED 25519; Values 6-31 : additional variants.

[0106] The version fields 1 110, 1212 may utilize a third mapping to indicate a particular version (e.g., of the first header and / or one or more fields of the first header. An example of the third mapping (using 8 values of a 3 bit version field) is as follows: Value 0: Version 1 ; Values 1 -7: Additional versions.

[0107] Once the transport packet (including the signed first header) has been transmitted to the second network node, the second network node may verify the authenticity / check the integrity of the signature included in the first header (e.g., by using a certificate or public key associated with the first network node). As discussed in the embodiments below, this verification can be performed even if (non-signed) parts of the headers are updated on a hop-by-hop basis (e.g., for the purposes of segment routing). For example, a “next hop address” in a packet header (which is excluded from a signature calculation) may be updated, whilst the segment list information (which is included in the signature calculation) is not updated.

[0108] The second network node may also (re-)sign the packet header (to generate a second signature), particularly if the signed part of the packet header has been updated (e.g., for the purposes of segment routing). The second network node may then append header integrity and authentication data (including the second signature) to, for example, the first header of the transport packet before the transport packet is (re-)transmitted to the next network node along a transport path. This supplements known security measures for transport packets (e.g. IPsec Authentication Headers (AH) and Encapsulating Security Payload (ESP)) that may protect the packet payload (thus protecting the RAN packet stream). Each network node in the transport path that receives the transport packet and updates the first header may (re-)sign the first header to enable its peer / next hop network node to verify the first header.

[0109] Figure 13 is a flowchart showing a method in accordance with embodiments of the disclosure, wherein the authenticity of the first header is verified. The method may be performed by the second network node (e.g., the second network node 2000 illustrated in figure 20). The method may begin at step 1302, with the second network node receiving, from a first network node (e.g., the first network node 1900 illustrated in figure 19), a transport packet. The transport packet includes a first header. Step 1302 may be considered to correspond / be complementary to step 204 of Figure 2. The first header comprises a first signature, a first portion and a second portion as described with reference to Figure 2. The first header may also comprise a third portion as described with reference to Figure 2. The first, second and third mappings may also be utilized as described with reference to Figure 2.

[0110] In order to configure the first network node and / or second network node with the first, second or third mapping, the method of Figure 13 may further comprise the second network node performing any one of the following: receiving the first, second and / or third mapping from the first network node; transmitting the first, second and / or third mapping to the first network node; and negotiating the first, second and / or third second mapping with the first network node.

[0111] At step 1304, the second network node determines an authenticity (i.e., checks the integrity) of the at least first portion based on the first signature. Determining the authenticity of the at least first portion may further be performed based on a first signature algorithm (e.g., a PKI or IKE algorithm) used to sign the at least first portion (e.g., by using the second indication).

[0112] If the at least first portion is determined to be inauthentic, the method may further comprise dropping the transport packet.

[0113] If the at least first portion is determined to be authentic, the method may further comprise accepting the transport packet or forwarding the transport packet to a third network node.

[0114] If the at least first portion is determined to be authentic, the method may further comprise signing the at least first portion to generate a second signature and transmitting, to a third network node, an updated transport packet. The updated first header of the updated transport packet may comprise: the at least first portion, the second signature, and a fourth portion comprising a third indication that the second signature is associated with the at least first portion. Prior to signing the at least first portion to generate the second signature, the second network node may modify the at least first portion to generate a modified at least first portion. For example, the at least first portion may be modified for segment routing purposes. The modified at least first portion may then be included in the updated transport packet. It should be appreciated that, in this case, signing the at least first portion comprises signing the modified at least first portion, so that the third network node may determine the authenticity of the modified at least first portion based on the second signature.

[0115] The third network nodes discussed above may perform similar embodiments to those discussed in relation to Figures 13 and 14 to determine the authenticity of the received transport packet.

[0116] As discussed in relation to Figure 8, in some embodiments of the present disclosure, the second portion is not included in the first header. Figure 14 is a flowchart showing a method in accordance with embodiments of the disclosure, wherein the authenticity of the first header omitting the second portion can be verified. The method may be performed by the second network node (e.g., the second network node 2000 illustrated in figure 20).

[0117] The method may begin at step 1402, with the second network node receiving, from a first network node (e.g., the first network node 1900 illustrated in figure 19), a transport packet. The transport packet includes a first header. The first header includes: a first signature, wherein the first signature is associated with at least a first (e.g., un-encrypted) portion of the first header comprising an identifier associated with a stream of transport packet. For example, the transport packet may be for an Ethernet packet stream, and the at least first portion may comprise a Stream-ID. In another example, the transport packet may be for an IP packet stream, and the at least first portion may comprise an IPv6 Flow label. Step 1402 may be considered to correspond / be complementary to step 804 of Figure 2. The first header may also comprise a second portion and / or a third portion as described with reference to Figure 8. The first, second and third mappings may also be utilized as described with reference to Figure 8.

[0118] In order to configure the first network node and / or second network node with the first, second and / or third mapping, the method of Figure 14 may further comprise the second network node performing any one of the following: receiving the first, second and / or third mapping from the first network node; transmitting the first, second and / or third mapping to the first network node; and negotiating the first, second and / or third mapping with the first network node.

[0119] At step 1404, the second network node determines an authenticity of the at least first portion based on the first signature. Determining the authenticity of the at least first portion may further be performed based on a first signature algorithm (e.g., a PKI or IKE algorithm) used to sign the at least first portion (e.g., by using the second indication).

[0120] If the at least first portion is determined to be inauthentic, the method may further comprise dropping the transport packet. If the at least first portion is determined to be authentic, the method may further comprise accepting the transport packet or forwarding the transport packet to a third network node.

[0121] If the at least first portion is determined to be authentic, the method may further comprise signing the at least first portion to generate a second signature and transmitting, to a third network node, an updated transport packet. The updated first header of the updated transport packet may comprise: the at least first portion, the second signature, and (optionally) a fourth portion comprising a third indication that the second signature is associated with the at least first portion.

[0122] Prior to signing the at least first portion to generate the second signature, the second network node may modify the at least first portion to generate a modified at least first portion. For example, the at least first portion may be modified for segment routing purposes. The modified at least first portion may then be included in the updated transport packet. It should be appreciated that, in this case, signing the at least first portion comprises signing the modified at least first portion, so that the third network node may determine the authenticity of the modified at least first portion based on the second signature.

[0123] The third network nodes discussed above may perform similar embodiments to those discussed in relation to Figures 13 and 14 to determine the authenticity of the received transport packet. Figures 15 - 18 are signalling diagrams illustrating embodiments of the present disclosure, including embodiments of the methods discussed in relation to figures 2, 8, 13, and 14.

[0124] Figure 15 is a signalling diagram illustrating a method for determining (utilising existing PKI) the authenticity of a transport packet according to embodiments of the present disclosure. The method involves a RAN sender node 1502 (corresponding to the first network node discussed above), an intermediate transport node 1504 (corresponding to the second network node discussed above), and a RAN receiver node 1506 (corresponding to the second or third network nodes discussed above). The RAN sender node 1502 is configured to communicate with the intermediate transport node 1504 and the RAN receiver node 1506, and the intermediate transport node 1504 is further configured to communicate with the RAN receiver node 1506.

[0125] At step 1508, the RAN sender node 1502 creates and uploads a public key (e.g., to a server).

[0126] At step 1510, the RAN sender node 1502 instructs the intermediate transport node 1504 to use PKI (particularly the public key of the RAN sender node 1502) for determining the authenticity of a transport packet transmitted from the RAN sender node 1502.

[0127] At step 1512, the intermediate transport node 1504 downloads the public key of the RAN sender node 1502 (e.g., from a server).

[0128] At step 1514, the RAN sender node 1502 instructs the RAN receiver node 1506 to use PKI (particularly the public key of the RAN sender node 1502) for determining the authenticity of a transport packet transmitted from the RAN sender node 1502 (via the intermediate node 1504).

[0129] At step 1516, the RAN receiver node 1506 downloads the public key of the RAN sender node 1502 (e.g., from a server).

[0130] At step 1518, the RAN sender node 1502 signs (at least a first portion of) a packet header of a transport packet. This step may correspond to step 202 of Figure 2 and / or step 802 of Figure 8. At step 1520, the RAN sender node 1502 transmits the (signed) transport packet to the intermediate transport node 1504. This step may correspond / be complementary to step 204 of Figure 2, step 804 of Figure 8, step 1302 of Figure 13, and / or step 1402 of Figure 14.

[0131] At step 1522, the intermediate transport node 1504 verifies the header of the transport packet (using the public key of the RAN sender node 1502). This step may correspond to step 1304 of Figure 13 or step 1404 of Figure 14. Based on the result of the verification of the header of the transport packet, the intermediate transport node 1504 determines whether to drop or forward the packet to the RAN receiver node 1506.

[0132] If the header is not verified as being authentic (i.e., the verification process failed, the header was determined to be inauthentic, the integrity was not verified, a version of the first header and / or a version of one or more fields of the first header are not accepted as secure by the receiver etc.), the intermediate transport node 1504 determines to drop the transport packet.

[0133] If the header is verified as being authentic, the intermediate transport node 1504 determines to forward the transport packet to the RAN receiver node 1506 and, at step 1524, transmits the transport packet to the RAN receiver node 1506.

[0134] At step 1526, the RAN receiver node 1506 verifies the header of the transport packet (using the public key of the RAN sender node 1502). This step may correspond to step 1304 of Figure 13 or step 1404 of Figure 14.

[0135] If the header is not verified as being authentic (i.e., the verification process failed, the header was determined to be inauthentic, the integrity was not verified, a version of the first header and / or a version of one or more fields of the first header are not accepted as secure by the receiver, etc.), the RAN receiver node 1506 drops the transport packet.

[0136] Dropping a transport packet may comprise adding to a counter maintained by the node which drops the transport packet (e.g., the intermediate transport node 1504), wherein the counter tracks the number of dropped, non-authentic packets. Additionally or alternatively, dropping the transport packet may comprise the node which drops the transport packet reporting that the transport packet has been dropped to the network. Reporting that the transport packet has been dropped may comprise sending, to a collector node of the network (e.g., the RAN sender node 1502, the RAN receiver node 1506, a management system, an automation system, etc) a reporting message that includes the reason the transport packet was considered to be inauthentic and / or includes the counter.

[0137] If the header is verified as being authentic, the RAN receiver node 1506 accepts the transport packet.

[0138] Figure 16 is a signalling diagram illustrating a method for determining (utilising existing IKE infrastructure) the authenticity of a transport packet according to embodiments of the present disclosure. The method involves a RAN sender node 1602 (corresponding to the first network node discussed above), an intermediate transport node 1604 (corresponding to the second network node discussed above), and a RAN receiver node 1606 (corresponding to the second or third network node discussed above). The RAN sender node 1602 is configured to communicate with the intermediate transport node 1604 and the RAN receiver node 1606, and the intermediate transport node 1604 is further configured to communicate with the RAN receiver node 1606.

[0139] At step 1608, the RAN sender node 1602 creates an (IKE) signing key (and, optionally, an authentication key, if asymmetric IKE is used).

[0140] At step 1610, the RAN sender node 1602 sets up a Security Association (SA) with the intermediate transport node 1604 and distributes, to the intermediate transport node 1604, the signing key (if symmetric IKE is used) or the authentication key (if asymmetric IKE is used) of the RAN sender node 1602.

[0141] At step 1612, the intermediate transport node 1604 prepares to use the received key of the RAN sender node 1602.

[0142] At step 1614, the RAN sender node 1602 sets up a Security Association (SA) with the RAN receiver node 1606 and distributes, to the RAN receiver node 1606, the signing key (if symmetric IKE is used) or the authentication key (if asymmetric IKE is used) of the RAN sender node 1602.

[0143] At step 1616, the RAN receiver node 1606 prepares to use the received key of the RAN sender node 1602. At step 1618, the RAN sender node 1602 signs (at least a first portion of) a packet header of a transport packet. This step may correspond to step 202 of Figure 2 and / or step 802 of Figure 8.

[0144] At step 1620, the RAN sender node 1602 transmits the (signed) transport packet to the intermediate transport node 1604. This step may correspond / be complementary to step 204 of Figure 2, step 804 of Figure 8, step 1302 of Figure 13, and / or step 1402 of Figure 14.

[0145] At step 1622, the intermediate transport node 1604 verifies the header of the transport packet (using the received key of the RAN sender node 1602). This step may correspond to step 1304 of Figure 13 and / or step 1404 of Figure 14. Based on the result of the verification of the header of the transport packet, the intermediate transport node 1604 determines whether to drop or forward the packet to the RAN receiver node 1606.

[0146] If the header is not verified as being authentic (i.e., the verification process failed, the header was determined to be inauthentic, the integrity was not verified, a version of the first header and / or a version of one or more fields of the first header are not accepted as secure by the receiver, etc.), the intermediate transport node 1604 determines to drop the transport packet. Dropping a transport packet may comprise any of the above discussed embodiments of dropping a transport packet.

[0147] If the header is verified as being authentic, the intermediate transport node 1604 determines to forwards the transport packet to the RAN receiver node 1606 and, at step 1624, transmits the transport packet to the RAN receiver node 1606.

[0148] At step 1626, the RAN receiver node 1606 verifies the header of the transport packet (using the received key of the RAN sender node 1602). This step may correspond to step 1304 of Figure 13 and / or step 1404 of Figure 14.

[0149] If the header is not verified as being authentic (i.e., the verification process failed, the header was determined to be inauthentic, the integrity was not verified, a version of the first header and / or a version of one or more fields of the first header are not accepted as secure by the receiver, etc.), the RAN receiver node 1606 drops the transport packet. If the header is verified as being authentic, the RAN receiver node 1606 accepts the transport packet.

[0150] Figure 17 is a signalling diagram illustrating a method for determining (utilising existing PKI) the authenticity of a transport packet according to embodiments of the present disclosure. The method involves a RAN sender node 1702 (corresponding to the first network node discussed above), an intermediate transport node 1704 (corresponding to the second network node discussed above), and a RAN receiver node 1706 (corresponding to the second or third network nodes discussed above). The RAN sender node 1702 is configured to communicate with the intermediate transport node 1704, and the intermediate transport node 1704 is further configured to communicate with the RAN receiver node 1706.

[0151] At step 1708, the RAN sender node 1702 creates and uploads a public key (e.g., to a server).

[0152] At step 1710, the RAN sender node 1702 instructs the intermediate transport node 1704 to use PKI (particularly the public key of the RAN sender node 1702) for determining the authenticity of a transport packet transmitted from the RAN sender node 1702.

[0153] At step 1712, the intermediate transport node 1704 downloads the public key of the RAN sender node 1702 (e.g., from a server).

[0154] At step 1714, the intermediate transport node 1704 creates and uploads a public key (e.g., to a server).

[0155] At step 1716, the intermediate transport node 1704 instructs the RAN receiver node 1706 to use PKI (particularly the public key of the intermediate transport node 1704) for determining the authenticity of a transport packet transmitted from the intermediate transport node 1704.

[0156] At step 1718, the RAN receiver node 1706 downloads the public key of the intermediate transport node 1704 (e.g., from a server). At step 1720, the RAN sender node 1702 signs (at least a first portion of) a packet header of a transport packet. This step may correspond to step 202 of Figure 2 and / or step 802 of Figure 8.

[0157] At step 1722, the RAN sender node 1702 transmits the (signed) transport packet to the intermediate transport node 1704. This step may correspond / be complementary to step 204 of Figure 2, step 804 of Figure 8, step 1302 of Figure 13, and / or step 1402 of Figure 14.

[0158] At step 1724, the intermediate transport node 1704 verifies the header of the transport packet (using the public key of the RAN sender node 1702). This step may correspond to step 1304 of Figure 13 and / or step 1404 of Figure 14. Based on the result of the verification of the header of the transport packet, the intermediate transport node 1704 determines whether to drop or (re-sign and) forward the packet to the RAN receiver node 1706.

[0159] If the header is not verified as being authentic (i.e., the verification process failed, the header was determined to be inauthentic, the integrity was not verified, a version of the first header and / or a version of one or more fields of the first header are not accepted as secure by the receiver, etc.), the intermediate transport node 1704 determines to drop the transport packet. Dropping a transport packet may comprise any of the above discussed embodiments of dropping a transport packet.

[0160] If the header is verified as being authentic, the intermediate transport node 1704 determines to (re-sign and) forward the transport packet to the RAN receiver node 1706 and, at step 1726, transmits the transport packet to the RAN receiver node 1706. Resigning the transport packet may correspond to any of the above embodiments for (resigning at least a first portion of the first header, and may occur in response to the intermediate transport node 1704 modifying the header of the transport packet.

[0161] At step 1728, the RAN receiver node 1706 verifies the header of the transport packet (using the public key of the intermediate transport node 1704). This step may correspond to step 1304 of Figure 13 and / or step 1404 of Figure 14.

[0162] If the header is not verified as being authentic (i.e., the verification process failed, the header was determined to be inauthentic, the integrity was not verified, a version of the first header and / or a version of one or more fields of the first header are not accepted as secure by the receiver, etc.), the RAN receiver node 1706 drops the transport packet.

[0163] If the header is verified as being authentic, the RAN receiver node 1706 accepts the transport packet.

[0164] Figure 18 is a signalling diagram illustrating a method for determine (utilising existing IKE infrastructure) the authenticity of a transport packet according to embodiments of the present disclosure. The method involves a RAN sender node 1802 (corresponding to the first network node discussed above), an intermediate transport node 1804 (corresponding to the second network node discussed above), and a RAN receiver node 1806 (corresponding to the second or third network nodes discussed above). The RAN sender node 1802 is configured to communicate with the intermediate transport node 1804, and the intermediate transport node 1804 is further configured to communicate with the RAN receiver node 1806.

[0165] At step 1808, the RAN sender node 1802 creates an (IKE) signing key (and, optionally, an authentication key, if asymmetric IKE is used).

[0166] At step 1810, the intermediate transport node 1804 creates an (IKE) signing key.

[0167] At step 1812, the RAN sender node 1802 sets up a Security Association (SA) with the intermediate transport node 1804 and distributes, to the intermediate transport node 1804, the signing key (if symmetric IKE is used) or the authentication key (if asymmetric IKE is used) of the RAN sender node 1802.

[0168] At step 1814, the intermediate transport node 1804 prepares to use the received key of the RAN sender node 1802.

[0169] At step 1816, the intermediate transport node 1804 sets up a Security Association (SA) with the RAN receiver node 1806 and distributes, to the RAN receiver node 1806, the signing key (if symmetric IKE is used) or the authentication key (if asymmetric IKE is used) of the intermediate transport node 1804.

[0170] At step 1818, the RAN receiver node 1806 prepares to use the received key of the intermediate transport node 1804. At step 1820, the RAN sender node 1802 signs (at least a first portion of) a packet header of a transport packet. This step may correspond to step 202 of Figure 2 and / or step 802 of Figure 8.

[0171] At step 1822, the RAN sender node 1802 transmits the (signed) transport packet to the intermediate transport node 1804. This step may correspond / be complementary to step 204 of Figure 2, step 804 of Figure 8, step 1302 of Figure 13, and / or step 1402 of Figure 14.

[0172] At step 1824, the intermediate transport node 1804 verifies the header of the transport packet (using the received key of the RAN sender node 1802). This step may correspond to step 1304 of Figure 13 and / or step 1404 of Figure 14. Based on the result of the verification of the header of the transport packet, the intermediate transport node 1804 determines whether to drop or (re-sign and) forward the packet to the RAN receiver node 1806.

[0173] If the header is not verified as being authentic (i.e., the verification process failed, the header was determined to be inauthentic, the integrity was not verified, a version of the first header and / or a version of one or more fields of the first header are not accepted as secure by the receiver, etc.), the intermediate transport node 1804 determines to drop the transport packet. Dropping a transport packet may comprise any of the above discussed embodiments of dropping a transport packet.

[0174] If the header is verified as being authentic, the intermediate transport node 1804 determines to (re-sign and) forward the transport packet to the RAN receiver node 1806 and, at step 1826, transmits the transport packet to the RAN receiver node 1806. Resigning the transport packet may correspond to any of the above embodiments for (resigning at least a first portion of the first header, and may occur in response to the intermediate transport node 1804 modifying the header of the transport packet.

[0175] At step 1828, the RAN receiver node 1806 verifies the header of the transport packet (using the received key of the intermediate transport node 1804). This step may correspond to step 1304 of Figure 13 and / or step 1404 of Figure 14. If the header is not verified as being authentic (i.e., the verification process failed, the header was determined to be inauthentic, the integrity was not verified, a version of the first header and / or a version of one or more fields of the first header are not accepted as secure by the receiver, etc.), the RAN receiver node 1806 drops the transport packet.

[0176] If the header is verified as being authentic, the RAN receiver node 1806 accepts the transport packet.

[0177] Figure 19 is a schematic diagram of a first network node 1900. The first network node comprises memory 1902, processing circuitry 1904, and interface(s) 1906. The processing circuitry 1904 may be configured such that the first network node 1900 may be operable to perform method steps discussed in relation to Figures 2, 8 and 13 - 18.

[0178] It will be appreciated that the first network node 1900 may comprise one or more virtual machines running different software and / or processes. The first network node 1900 may therefore comprise, or be implemented in or as one or more servers, switches and / or storage devices and / or may comprise cloud computing infrastructure that runs the software and / or processes.

[0179] The processing circuitry 1904 controls the operation of the first network node 1900 to implement the relevant part of the methods described herein. The processing circuitry 1904 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the first network node 1900 in the manner described herein. In particular implementations, the processing circuitry 1904 can comprise a plurality of software and / or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the first network node 1900.

[0180] The interface(s) / communications interface(s) 1906 is for use in enabling communications with other apparatus, network nodes, computers, servers, etc. For example, the communications interface 1906 can be configured to transmit to and / or receive from other apparatus or nodes requests, acknowledgements, information, data, signals, or similar. The communications interface 1906 can use any suitable communication technology. The processing circuitry 1904 may be configured to control the communications interface 1906 to transmit to and / or receive from other nodes, etc. requests, acknowledgements, information, data, signals, or similar, according to the methods described herein.

[0181] In some embodiments, the memory 1902 can be configured to store program code that can be executed by the processing circuitry 1904 to perform the methods described herein. Alternatively or in addition, the memory 1902 can be configured to store any requests, acknowledgements, information, data, signals, or similar that are described herein. The processing circuitry 1904 may be configured to control the memory 1902 to store such information therein.

[0182] Figure 20 is a schematic diagram of a second network node 2000. The second network node comprises memory 2002, processing circuitry 2004, and interface(s) 2006. The processing circuitry 2004 may be configured such that the second network node 2000 may be operable to perform method steps discussed in relation to Figures 2, 8 and 13 - 18.

[0183] It will be appreciated that the second network node 2000 may comprise one or more virtual machines running different software and / or processes. The second network node 2000 may therefore comprise, or be implemented in or as one or more servers, switches and / or storage devices and / or may comprise cloud computing infrastructure that runs the software and / or processes.

[0184] The processing circuitry 2004 controls the operation of the second network node 2000 to implement the relevant part of the methods described herein. The processing circuitry 2004 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the second network node 2000 in the manner described herein. In particular implementations, the processing circuitry 2004 can comprise a plurality of software and / or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the second network node 2000.

[0185] The interface(s) / communications interface(s) 2006 is for use in enabling communications with other apparatus, network nodes, computers, servers, etc. For example, the communications interface 2006 can be configured to transmit to and / or receive from other apparatus or nodes requests, acknowledgements, information, data, signals, or similar. The communications interface 2006 can use any suitable communication technology.

[0186] The processing circuitry 2004 may be configured to control the communications interface 2006 to transmit to and / or receive from other nodes, etc. requests, acknowledgements, information, data, signals, or similar, according to the methods described herein.

[0187] In some embodiments, the memory 2002 can be configured to store program code that can be executed by the processing circuitry 2004 to perform the methods described herein. Alternatively or in addition, the memory 2002 can be configured to store any requests, acknowledgements, information, data, signals, or similar that are described herein. The processing circuitry 2004 may be configured to control the memory 2002 to store such information therein.

[0188] Figure 21 is a block diagram illustrating a virtualization environment 2100 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 2100 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 2100 includes components defined by the O-RAN Alliance, such as an Ci- Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host.

[0189] Applications 2102 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. Hardware 2104 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 2106 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 2108a and 2108b (one or more of which may be generally referred to as VMs 2108), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 2106 may present a virtual operating platform that appears like networking hardware to the VMs 2108.

[0190] The VMs 2108 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 2106. Different embodiments of the instance of a virtual appliance 2102 may be implemented on one or more of VMs 2108, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0191] In the context of NFV, a VM 2108 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 2108, and that part of hardware 2104 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 2108 on top of the hardware 2104 and corresponds to the application 2102.

[0192] Hardware 2104 may be implemented in a standalone network node with generic or specific components. Hardware 2104 may implement some functions via virtualization. Alternatively, hardware 2104 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 2110, which, among others, oversees lifecycle management of applications 2102. In some embodiments, hardware 2104 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 2112 which may alternatively be used for communication between hardware nodes and radio units.

[0193] Although the computing devices described herein may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0194] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hardwired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0195] It should be noted that the above-mentioned examples illustrate rather than limit the disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended embodiments. The word “comprising” does not exclude the presence of elements or steps other than those listed in an embodiment or claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the embodiments. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

CLAIMS1 . A method performed by a first network node (1900), the method comprising: signing (202) at least a first portion of a first header of a transport packet to generate a first signature; and transmitting (204) the transport packet comprising the first header to a second network node (2000), wherein the first header comprises: the at least first portion; the first signature; and a second portion comprising a first indication that the first signature is associated with the at least first portion.

2. The method of claim 1 , wherein the first indication comprises one of: a value or a set bit position in a bit string, wherein the first indication is mapped to the at least first portion in a first mapping.

3. The method of claim 2 wherein the method further comprises one of: receiving the first mapping from the second network node; transmitting the first mapping to the second network node; and negotiating the first mapping with the second network node.

4. The method of any one of claims 1 to 3, wherein signing the at least first portion is performed using a first signature algorithm, and the first header further comprises a third portion comprising a second indication of the first signature algorithm.

5. The method of claim 4, wherein the second indication comprises one of: a value or a set bit position in a bit string, wherein the second indication is mapped to the first signature algorithm in a second mapping.

6. The method of claim 5, wherein the method further comprises one of: receiving the second mapping from the second network node; transmitting the second mapping to the second network node; and negotiating the second mapping with the second network node.

7. The method of any of claims 1 -6, wherein the at least first portion comprises an identifier associated with a stream of the transport packet.

8. The method of claim 7, wherein, the transport packet is for an Ethernet packet stream, and the at least first portion comprises a Stream-ID.

9. The method of claim 7, wherein the transport packet is for an Internet Protocol, IP, packet stream, and the at least first portion comprises an IPv6 Flow label.

10. The method of any of claims 1 -6, wherein the at least first portion comprises one or more fields indicating any one or more of: a source IP; a destination IP; a flow label; a class; a Segment Routing, SR, Segment Identifier, SID, list; an SR Multiprotocol Label Switching, MPLS, SID-list; a source Medium Access Control, MAC; a destination MAC; a Virtual Local Area Network, VLAN; a stream identifier; a source address; a destination address; an SR with IPv6, SRv6, SID list; an MPLS label stack.

11. The method of any of claims 1 -10, wherein the at least first portion is unencrypted.

12. A method performed by a second network node (2000), the method comprising: receiving (1302), from a first network node (1900), a transport packet including a first header, wherein the first header includes: a first signature, and a second portion comprising a first indication that the first signature is associated with at least a first portion of the first header; and determining (1304) an authenticity of the at least first portion based on the first signature.

13. The method of claim 12, wherein the first indication comprises one of: a value or a set bit position in a bit string, wherein the first indication is mapped to the at least first portion in a first mapping.

14. The method of claim 13, wherein the method further comprises one of: receiving the first mapping from the first network node; transmitting the first mapping to the first network node; and negotiating the first mapping with the first network node.

15. The method of claim 12 to 14, wherein if the at least first portion is determined to be inauthentic, the method further comprises dropping the transport packet.

16. The method of any of claims 12-15, wherein if the at least first portion is determined to be authentic, the method further comprises accepting the transport packet or forwarding the transport packet to a third network node.

17. The method of any of claims 12-15, wherein if the at least first portion is determined to be authentic, the method further comprises:- signing the at least first portion to generate a second signature; and- transmitting, to a third network node, an updated transport packet, wherein a updated first header of the updated transport packet comprises: the at least first portion, the second signature, and a fourth portion comprising a third indication that the second signature is associated with the at least first portion.

18. The method as claimed in claim 17, further comprising, prior to signing the at least first portion to generate a second signature, modifying the at least first portion to generate a modified at least first portion, and including the modified at least first portion in the updated transport packet.

19. The method of any of claims 12-18, wherein determining the authenticity of the at least first portion is further performed based on a first signature algorithm used to sign the at least first portion.

20. The method of claim 19, wherein the first header further includes a third portion comprising a second indication of the first signature algorithm used to sign the at least first portion.21 . The method of claim 20, wherein the second indication comprises one of: a value or a set bit position in a bit string, wherein the second indication is mapped to the first signature algorithm in a second mapping.

22. The method of claim 21 , wherein the method further comprises one of: receiving the second mapping from the first network node; transmitting the second mapping to the first network node; and negotiating the second mapping with the first network node.

23. The method of any of claims 12-22, wherein the at least first portion comprises an identifier of a stream associated with the transport packet.

24. The method of claim 23, wherein, the transport packet is for an Ethernet packet stream, and the at least first portion comprises a Stream-ID.

25. The method of claim 23, wherein, the transport packet is for an Internet Protocol, IP, packet stream, and the at least first portion comprises an IPv6 Flow label.

26. The method of any of claims 12-22, wherein the at least first portion comprises one or more fields indicating any one or more of: a source IP; a destination IP; a flow label; a class; a Segment Routing, SR, Segment Identifier, SID, list; an SR Multiprotocol Label Switching, MPLS, SID-list; a source Medium Access Control, MAC; a destination MAC; a Virtual Local Area Network, VLAN; a stream identifier; a source address; a destination address; an SR with IPv6, SRv6, SID list; an MPLS label stack.

27. The method of any of claims 12-26, wherein the at least first portion is unencrypted.

28. A method performed by a first network node (1900), the method comprising: signing (802) at least a first portion of a first header of a transport packet to generate a first signature, wherein the at least first portion comprises an identifier associated with a stream of the transport packet; and transmitting (804) the transport packet comprising the first header to a second network node (2000), wherein the first header comprises: the at least first portion; and the first signature.

29. The method as claimed in claim 28, wherein the transport packet further comprises a second portion comprising a first indication that the first signature is associated with the at least first portion.

30. The method as claimed in claim 28 or 29, wherein signing the at least first portion is performed using a first signature algorithm, and the first header further comprises a third portion comprising a second indication of the first signature algorithm.31 . The method of any one of claims 28 to 30, wherein, the transport packet is for an Ethernet packet stream, and the at least first portion comprises a Stream-ID.

32. The method of any one of claims 28 to 30, wherein the transport packet is for an Internet Protocol, IP, packet stream, and the at least first portion comprises an IPv6 Flow label.

33. The method of any of claims 28-32, wherein the at least first portion is unencrypted.

34. A method performed by a second network node (2000), the method comprising: receiving (1402), from a first network node (1900), a transport packet including a first header, wherein the first header includes: a first signature, wherein the first signature is associated with at least a first portion of the first header comprising an identifier associated with a stream of the transport packet; and determining (1404) an authenticity of the at least first portion based on the first signature.

35. The method as claimed in claim 34, wherein the first header further comprises a second portion comprising a first indication that the first signature is associated with the at least first portion.

36. The method as claimed in claim 34 or 35, wherein the first header further comprises a third portion comprising a second indication of a first signature algorithm used to generate the first signature.

37. The method of any one of claims 34 to 36, wherein, the transport packet is for an Ethernet packet stream, and the at least first portion comprises a Stream-ID.

38. The method of any one of claims 34 to 36, wherein the transport packet is for an Internet Protocol, IP, packet stream, and the at least first portion comprises an IPv6 Flow label.

39. The method of any of claims 34 to 38, wherein the at least first portion is unencrypted.

40. A first network node (1900), the first network node comprising processing circuitry (1904) configured to cause the first network node to perform any of claims 1 -11 and / or any of claims 28-32.41 . A second network node (2000), the second network node comprising processing circuitry (2004) configured to cause the second network node to perform any of claims 12-27 and / or any of claims 34-39.

42. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of claims 1 -39.

Images