Methods and apparatuses for managing internet key exchange between internet protocol security endpoints

Abstract

Embodiments descried herein relate to a method and apparatus for managing internet key exchange between internet protocol security endpoints. A method, performed by a first Radio Access Network, RAN, entity, for applying transport security in transmitting data between the first RAN entity and a second RAN entity, the first RAN entity being associated with a plurality of first entity IP addresses, and the second RAN entity being associated with a plurality of second entity IP addresses. The method comprises setting up a first internet key exchange, IKE, security association, SA, between a first Internet Protocol, IP, address of the first entity IP addresses and a second IP address of the second entity IP addresses; and utilizing the first IKE SA to negotiate a plurality of first child SA pairs, wherein the plurality of first child SA pairs are set up between first child IP addresses of the plurality of first entity IP addresses and second child IP addresses of the plurality of second entity IP addresses.

Description

[0001] METHODS AND APPARATUSES FOR MANAGING INTERNET KEY EXCHANGE

[0002] BETWEEN INTERNET PROTOCOL SECURITY ENDPOINTS.

[0003] Technical Field

[0004] Embodiments described herein relate to methods and apparatuses for managing Internet Key Exchange (IKE) between RAN entities to limit the number of IKE Security Associations (SAs) required.

[0005] Background

[0006] Figure 1 illustrates an Internet Protocol (IP) security (IPsec) setup and use for secure data transfer between two endpoints in an IP network, wherein the two endpoints comprise a first endpoint 110 and a second endpoint 120. The first endpoint 1 10 comprises an IP address at port 1 12 and the second endpoint comprises an IP address at port 122. The ports 112 and 122 may each comprise a physical port or a logical port. A logical port may comprise, for example, a Virtual LAN (VLAN) or Link Aggregation Group (LAG) port. It will be appreciated that a port can be associated with a plurality of IP addresses.

[0007] An security association (SA) is required to be established between two IPsec endpoints before secure data transmission may be implemented. An IPsec endpoint comprises an IP address. In IPsec tunnel mode, the IPsec endpoint (e.g. the IP addresses 100.3.2.2 and 100.3.2.1 ) may protect and hide any endpoint 110, 120 inner IP-addresses (e.g. IP addresses 10.10.10.1 , 10.10.10.2, 10.10.10.3, 10.10.10.1 1 , 10.10.10.12, and 10.10.10.13) and protocols (as illustrated in Figure 1 ). In IPsec Transport mode the IPsec endpoint (e.g. IP address 100.3.2.2 or 100.3.2.1 ) may protect and hide any endpoint’s 110, 120 inner Protocols. . An SA is an agreement between two entities which details how the entities will use security services to implement secure data transmission. The SA may be used to manage information exchanged between the two IP endpoints.

[0008] Current technologies applying transport security on Internet Protocol (IP) transport networks using IPsec use a scheme that may be described in two steps.

[0009] In a first step, there is a secure Key exchange procedure, which comprises setting up (or initializing) an IKE SA between two applicable IPsec endpoints. In the example of Figure 1 , an IKE SA for key exchange is set up between an IP address on port 1 12 (e.g. IPaddress 100.3.2.1 ) of the first endpoint 1 10 and an IP address of port 122 (e.g. IP Address 100.3.2.2) of the second endpoint 120.

[0010] In a second step, a Child SA pair for the data traffic between the two IPsec endpoints is set up, using the IKE SA for Key handling. A Child SA comprises an SA that is negotiated by the IKE SA. A Child SA pair comprises a Child SA in each of the two data transmission directions (illustrated by the two arrows in opposite directions depicting each Child SA herein). As shown in Figure 1 , a Child SA pair for data is set up between an IP address on port 1 12 of the first endpoint 1 10 and an IP address on port 122 of the second endpoint 120.

[0011] It will be appreciated that in IKE v2 the first and second steps outlined above may be performed as part of a single logical step.

[0012] Figure 2 shows IKE SAs and Child SA pairs between IP address pairs within two Radio Access Network, RAN, entities, wherein the two RAN entities comprise a first RAN entity 210 and a second RAN entity 220. The first RAN entity 210 comprises a plurality of ports, 212, 214, 216 and 218, and the second RAN entity comprises a plurality of ports, 222 and 224.

[0013] Applying IPsec between RAN entities in an IP Network may be with, for example, Open RAN (ORAN) Radio unit (O-RU), and an ORAN distributed unit (O-DU) (e.g. a baseband unit) or virtual Distributed Unit (vDU). In one example, the first RAN entity 210 may comprise the O-DU and the second RAN entity 220 may comprise the O-RU.

[0014] For applying IPsec between RAN entities in an IP Network, each RAN entity IP address pair has its own IKE SA for key exchange and all other IKE negotiations for each Child SA pair used for data transfer. This leads to a high number of SAs, wherein the SAs may comprise IKE SAs and IPsec Child SA pairs. As shown in Figure 2, an IKE SA for key exchange and a Child SA pair for data is set up between IP addresses 100.3.2.1 and 100.3.2.5 on ports 212 and 222, IP addresses 100.3.2.2 and 100.3.2.5 on ports 214 and 222, IP address 100.3.2.3 and 100.3.2.6 on ports 216 and 224, and IP addresses 100.3.2.4 and 100.3.2.6 on ports 218 and 224. Therefore, in the example shown in Figure 2, 12 SAs (4 IKE SAs and 4 Child SA pairs, thus 8 child SAs) are set up between the first RAN entity 210 and the second RAN entity 220. In a product implementation there will be limitations on the number of sessions and table sizes. Furthermore, the processing of many SAs in an entity generates a high cost. Additionally, a high cost is generated due to requiring memory and tables for many SAs.

[0015] Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges. For example, embodiments of the disclosed techniques disclose methods for limiting the number of Internet Key Exchange (IKE) SAs between Radio Access Network (RAN) entities. In one embodiment, a method comprises using one single IKE SA to manage the Key exchange and all other IKE negotiations for a plurality of Child SA pairs distributed over a plurality of Internet Protocol (IP) address pairs related to the applicable RAN entity pair.

[0016] According to some embodiments there is provided a method, performed by a first RAN entity, for applying transport security in transmitting data between the first RAN entity and a second RAN entity, the first RAN entity being associated with a plurality of first entity IP addresses, and the second RAN entity being associated with a plurality of second entity IP addresses. The method comprises setting up a first IKE security association, SA, between a first IP address of the first entity IP addresses and a second IP address of the second entity IP addresses. The method further comprises utilising the first IKE SA to negotiate a plurality of first child SA pairs, wherein the plurality of first child SA pairs are set up between first child IP addresses of the plurality of first entity IP addresses and second child IP addresses of the plurality of second entity IP addresses.

[0017] According to some embodiments there is provided a first RAN entity for applying transport security in transmitting data between the first RAN entity and a second RAN entity, the first RAN entity being associated with a plurality of first entity IP addresses, and the second RAN entity being associated with a plurality of second entity IP addresses. The first RAN entity comprises processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the first RAN entity is operable to: set up a first IKE security association, SA, between a first IP address of the first entity IP addresses and a second IP address of the second entity IP addresses. The memory contains further instructions executable by the processing circuitry whereby the first RAN entity is operable to utilise the first IKE SA to negotiate a plurality of first child SA pairs, wherein the plurality of first child SA pairs are set up between first child IP addresses of the plurality of first entity IP addresses and second child IP addresses of the plurality of second entity IP addresses.

[0018] According to some embodiments there is provided a computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method described above.

[0019] According to some embodiments there is provided a carrier containing the computer program described above, wherein the carrier comprises one of an electronic signal, optical signal, radio signal or computer readable storage medium.

[0020] According to some embodiments there is provided a computer-readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method described above.

[0021] According to some embodiments there is provided a computer program product comprising non transitory computer readable media having stored thereon a computer program as described above.

[0022] Certain embodiments may provide one or more of the following technical advantages. For example, one technical advantage may be that certain embodiments provide for limiting the number of IKE SAs. In a product implementation this will therefore reduce the required memory and table size. Furthermore, it will limit the costly processing of many IKE SAs. As another example, a technical advantage may be that certain embodiments provide support for simplifying IPsec configuration and management. Additionally, certain embodiments enable the possibility to terminate the IKE SA on a separate IP address, which can further simplify configuration and management.

[0023] Other advantages may be readily apparent to one having skill in the art. Certain embodiments may have none, some, or all of the recited advantages.

[0024] Brief Description of the Drawings Figure 1 illustrates IPsec setup and use for secure data transfer between two endpoints in an IP network.

[0025] Figure 2 illustrates IKE SAs and Child SA pairs between IP address pairs within two RAN entities.

[0026] Figure 3 illustrates an example method for managing IKE between IP endpoints, according to certain embodiments.

[0027] Figure 4 illustrates one IKE SA for all Child SA pairs between IP address pairs within two RAN entities.

[0028] Figure 5 illustrates one IKE SA between central processing units, for all Child SA pairs between IP address pairs within two RAN entities.

[0029] Figure 6 illustrates one IKE SA for all Child SA pairs between IP address pairs within two RAN entities, wherein the two RAN entities each comprise a port comprising a plurality of IP addresses.

[0030] Figure 7a is a signalling diagram showing an example implementation of step 320 of Figure 3.

[0031] Figure 7b is a signalling diagram illustrating an example implementation of step 730 of Figure 7a;

[0032] Figure 8 illustrates an example of an IKEv2 Header Format.

[0033] Figure 9 illustrates an example of an IKEv2 Next Payload Type.

[0034] Figure 10 illustrates an example of an IKEv2 Notify Payload Format.

[0035] Figure 1 1 illustrates a RAN entity comprising processing circuitry (or logic).

[0036] Detailed Description Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

[0037] The following sets forth specific details, such as particular embodiments or examples for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and / or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and / or using software programs and data in conjunction with one or more digital microprocessors or general-purpose computers. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer- readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[0038] Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and / or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions. Certain aspects of the present disclosure and their embodiments may provide solutions to the challenges mentioned above or other challenges.

[0039] Particular embodiments are 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] Some embodiments include methods and apparatuses for managing IKE between IPsec endpoints.

[0041] Figure 3 is a flowchart illustrating a method 300 for managing IKE SAs between IPsec endpoints, according to certain embodiments.

[0042] The method 300 may be performed by a first RAN entity. The first RAN entity may apply transport security in transmitting data between the first RAN entity and a second RAN entity, and wherein the first RAN entity is associated with a plurality of first entity IP addresses and the second RAN entity is associated with a plurality of second entity IP addresses. In particular, a RAN entity may comprise any distributed unit in O-RAN deployment, for example, an O-RU or an O-DU.

[0043] In step 310, a first IKE SA between a first IP address of the first entity IP addresses and a second IP address of the second entity IP addresses is set up. The first IKE SA may be set up between the first IP address and the second IP address and then manage IKE negotiations for defined IP addresses. For example, the first IKE SA may be set up by being negotiated between the first RAN entity and the second RAN entity.

[0044] In step 320, the first RAN entity utilises the first IKE SA to negotiate a plurality of first child SA pairs, wherein the plurality of first child SA pairs are set up between first child IP addresses of the plurality of first entity IP addresses and second child IP addresses of the plurality of second entity IP addresses. It will be appreciated that the first child IP addresses may therefore be a subset of the first entity IP addresses available at the first RAN entity. Similarly, the second child IP addresses may be a subset of the second entity IP addresses available at the second RAN entity. It will be appreciated that the negotiation in step 320 may be initiated by the first RAN entity or the second RAN entity. It will be appreciated that the steps 310 and 320 may be performed in any applicable order, or in a single logical step.

[0045] It will also be appreciated that the method of Figure 3 may be utilized to set up a Child SA allowing for data traffic in only one direction, rather than a Child SA pair. It will also be appreciated that the method of Figure 3 may be utilized by respective endpoints to set up respective uni-directional child SAs, in opposite directions.

[0046] It will be appreciated, that each of the first Child SA pairs may be set up between a pair of IP addresses (e.g. one of the first child IP addresses and one of the second child IP addresses) in the RAN entities. In the examples depicted in Figure 4 and Figure 5, 4 Child SA pairs for data transfer are negotiated using the first IKE SA.

[0047] It will therefore be appreciated that by performing the method of Figure 3 (e.g. at least steps 310 and 320), only one IKE SA is needed in order to provide a plurality of child SA pairs. In particular, the IKE SA may be utilized to provide a plurality of child SA pairs between IP addresses that are not involved in the IKE SA itself.

[0048] It will be appreciated, as described further below, that there may be circumstances in which more than one IKE SA is provided between RAN entities. In these examples, there may be a plurality of child SA pairs managed by each IKE SA. For example, a plurality of first child SA pairs managed by a first IKE SA and a plurality of second child SA pairs managed by a second IKE SA.

[0049] The method 300 may optionally further comprise, steps 330 and 340. Steps 330 and 340 may be performed for each Child SA pair.

[0050] In step 330, the method may comprise for each first child SA pair, the first RAN entity and the second RAN entity negotiate one or more security keys using the first IKE SA. The method 300 may optionally further comprise, in step 340, the first RAN entity and the second RAN entity utilising the one or more security keys to transmit data between the first RAN entity and the second RAN entity using the first child SA pair. Performing steps 330 and 340 for each first child SA pair may enable data to be transmitted securely between the first RAN entity and the second RAN entity using the plurality of first child SA pairs whilst only utilising one first IKE SA.

[0051] Figure 4 illustrates and example result of the method of Figure 3 in which one IKE SA 402 is utilised for all Child SA pairs 404a to 404d between the two RAN entities, wherein the two RAN entities comprise a first RAN entity 410 and a second RAN entity 420. In particular, it will be appreciated that Figure 4 illustrates an example of the resulting IKE SA and Child SA pairs when the first RAN entity 410 and second RAN entity 420 have both performed the method of Figure 3.

[0052] In the example of Figure 4, it will be appreciated that the first IP address of step 310 comprises an IP address 100.3.2.1 of a first port 412 of the first RAN entity 410 and the second IP address of step 310 comprises an IP address 100.3.2.5 of a second port 422 of the second RAN entity 420. In other words, in this example, the IKE SA is set up between IP addresses associated with ports of the respective RAN entities. As discussed above, the ports of the respective RAN identities may each comprise a physical port or a logical port.

[0053] The first RAN entity 410 comprises a plurality of ports, 412, 414, 416 and 418, and the second RAN entity comprises a plurality of ports, 422 and 424. In this example, each port in the first RAN entity 410 and the second RAN entity 420 is associated with a single IP address. However, it will be appreciated that in some examples a port may be associated with more than one IP address (e.g. as illustrated in Figure 6).

[0054] In this example, Child SA pair 404a is set up between the IP addresses 100.3.2.1 .and 100.3.2.5 at ports 412 and 422, Child SA pair 404b is set up between the IP addresses 100.3.2.2 and 100.3.2.5 at ports 414 and 422, Child SA pair 404c is set up between the IP addresses 100.3.2.3 and 100.3.2.6 at ports 416 and 424 and Child SA pair 404d is set up between the IP addresses 100.3.2.4 and 100.3.2.6 at ports 418 and 424.

[0055] It will be appreciated that the child SA pairs that are managed by a single IKE SA may be required to be set up between differing pairs of IP addresses. In other words, two of the child SA pairs may share a common IP address endpoint, but both IP address endpoints may not be the same. In the example of Figure 4, the first RAN entity 410 may comprise the 0-Dll and the second RAN entity 420 may comprise the 0-Rll.

[0056] Typically (although not always) an O-DU would comprise more ports than an O-RU. In the example of Figure 4 therefore first RAN entity 410 comprises more ports (4 in the illustrative example) than the second RAN entity 420 (2 in the illustrative example). It will be appreciated however that the first RAN entity 410 and second RAN entity 420 may each comprise any suitable number of ports.

[0057] For capacity and / or resiliency reasons, each port on the second RAN entity 420 may have, via the packet Fronthaul network, connectivity to multiple ports on the first RAN entity 410. As shown in Figure 4, in this example, ports 422 and 424 in the second RAN entity 420 have connectivity to 2 ports each. As shown in Figure 4, port 422 in the second RAN entity 420 has connectivity to ports 412 and 414 in the first RAN entity 410, and port 424 in the second RAN entity 420 has connectivity to ports 416 and 418 in the first RAN entity 410.

[0058] In some embodiments, the IP addresses in the first RAN entity 410 or in the second RAN entity 420 utilised for the Child SA pairs may belong to the same IP subnet. This may ensure tighter security, as all defined IP addresses may belong to an IP subnet that is trusted. There may also be administrative and / or signalling advantages. Alternatively, in other embodiments, the IP addresses in the first RAN entity 410 or in the second RAN entity 420 utilised for the Child SA pairs may be specific IP addresses in an IP subnet or specific IP addresses in separate IP subnets, such that the IKE SA manages IKE negotiations for these specified IP addresses. This allows for entities and / or ports to be separated into different IP subnets. Additionally, this may increase flexibility, by allowing a Child SA pair to be set up between a wider range of IP address endpoints.

[0059] Figure 5 illustrates an example result of the method of Figure 3 in which the first IKE SA 502 is set up between IP addresses associated with CPUs of the first RAN entity and the second RAN entity.

[0060] The first RAN entity 410 and the second RAN entity 420 comprise the same port structure as described with reference to Figure 4. The ports have therefore been given consistent numbering. The Child SA pairs have also been set up in a similar manner to as illustrated in Figure 4.

[0061] The first CPU 51 1 is associated with an IP address 100.3.2.7 and the second CPU 521 is associated with an IP address 100.3.2.8.

[0062] In the example of Figure 5 therefore, the first IP address of step 310 may comprise thelP address 100.3.2.7 of the first central processing unit (CPU) 511 of the first RAN entity and the second IP address of step 310 may comprise the IP address 100.3.2.8 of the second CPU 521 of the second RAN entity. In some embodiments, the first CPU 511 and the second CPU 521 are each associated with a plurality of IP addresses. In some embodiments, the first IP address of step 310 comprises an IP address of a control processor of the first RAN entity and the second IP address of step 310 comprises an IP address of a control processor of the second RAN entity. It will be appreciated that a CPU may be considered a type of control processor.

[0063] In the example of Figure 5 therefore the first IKE SA 502 is set up between IP addresses associated with the CPUs of the RAN entities.

[0064] Figure 5 depicts the first RAN entity 410 and the second RAN entity 420 each comprising one CPU. However, the RAN entities each comprising one CPU is purely for illustrative purposes. The first RAN entity 410 and the second RAN entity 420 may each comprise a plurality of CPUs.

[0065] Figure 6 illustrates an example result of the method of Figure 3 in which one IKE SA 402 for all Child SA pairs 404a to 404d and 404e between two RAN entities. The first RAN entity 410 and the second RAN entity 420 comprise the same port structure as described with reference to Figure 4. The ports have therefore been given consistent numbering. The IKE SA has also been set up in a similar manner to as illustrated in Figure 4. The Child SA pairs 404a to 404d are similar to as described in Figure 4, however, Figure 6 illustrates an extra child SA pair 404e set up between IP addresses 100.3.2.7 and 100.3.2.8 of the ports 412 and 422.

[0066] In other words, in the example of Figure 6 the first child IP addresses comprise a plurality of IP addresses of the first port (e.g. for the child SA pairs 404a and 404e) of the first RAN entity and the second child IP addresses comprises a plurality of IP addresses (e.g. for the child SA pairs 404a and 404e) of the second port of the second RAN entity.

[0067] It will be appreciated that the examples given in Figures 4 to 6 are non-limiting, and other examples may be possible.

[0068] For example, it will be appreciated, that there may be some IP address available at each of the first RAN entity 410 and / or the second RAN entity that are not used to set up a child SA pair. For example, the second RAN entity could comprise an extra port for which the IKE SA does not negotiate further Child SA pairs. In some examples, the first RAN entity and second RAN entity may indicate to each other which of the first entity IP address and second entity IP addresses are useable as child IP addresses. An example of this procedure is described later with reference to Figure 7.

[0069] In some examples, there may also be two or more IKE SAs set up between two RAN entities. For example, a first IKE SA may manage a plurality of first Child SA pairs and a second IKE SA may manage a one or more second Child SA pairs. In this example, the method of Figure 3 may further comprise setting up the second IKE SA between a third IP address of the first entity IP addresses and a fourth IP address of the second entity IP addresses; and utilising the second IKE SA to negotiate one or more second child SA pairs, wherein each of the one or more second child SA pairs is set up between a third child IP address of the first entity IP addresses and a fourth child IP address of the second entity IP addresses. It will be appreciated that at least one of the third IP address and the fourth IP address used for the second IKE SA may be required to be different to both the first IP address and the second IP address used for the first IKE SA.

[0070] By setting up one or more further IKE SAs between IP addresses in RAN entities, in addition to the first IKE SA, this may increase flexibility in the method for applying IPsec between RAN entities in an IP network.

[0071] As mentioned above, it will be appreciated that the child SA pairs that are managed by a single IKE SA may be required to be set up between differing pairs of IP addresses. In other words, two of the child SA pairs may share a common IP address endpoint, but both IP address endpoints may not be the same. However, a first child SA pair managed by the first IKE SA may be set up between the same pair of IP addresses as a second child SA pair managed by the second IKE. Figure 7a is a signalling diagram illustrating an example implementation of step 320 of Figure 3. In this example, the method of step 320 of Figure 3 is performed individually by both an Initiator RAN entity 701 and a Responder RAN entity 702. In this example the Initiator RAN entity is initiating the setup of the IKE SA and the Child SAs. However, it will be appreciated that at different times, both entities involved (e.g. the first RAN entity and the second RAN entity) may act as Initiator or Responder.

[0072] In some embodiments, the Initiator RAN entity 701 may comprise the first RAN entity of step 320 and the Responder RAN entity 702 may comprise the second RAN entity of step 320. In other embodiments, the Initiator RAN entity 701 may comprise the second RAN entity of step 320 and the Responder RAN entity 702 may comprise the first RAN entity of step 320. Hence, the entities comprising the Initiator RAN entity and the Responder RAN entity may both perform the method 300 of Figure 3.

[0073] It will be appreciated that the Initiator RAN entity 701 may comprise the first RAN entity 401 of Figures 4 to 6 and the Responder RAN entity 702 may comprise the second RAN entity 402 of Figures 4 to 6, or vice versa.

[0074] The example implementation begins at step 710, wherein, the Initiator RAN entity 701 transmits, to the Responder RAN entity 702 an IKE protocol packet comprising a first indication of a plurality of applicable IP addresses. The applicable IP addresses are supported by the Initiator RAN entity 701 for use providing multiple child SA pairs managed by the first IKE SA. It will be appreciated that, in some cases, not all IP addresses available at the Initiator RAN entity are applicable IP addresses. For example, in some cases only a particular subset of IP addresses are supported for providing multiple Child SA pairs managed by the first IKE SA.

[0075] It will be appreciated that where the signalling of Figure 7a is utilised to provide the results illustrated in Figures 4 to 6 (or set up the child SA pairs as described in step 320 of Figure 3) the first child IP addresses (and in some examples the second child IP addresses)are comprised within the plurality of applicable IP addresses.

[0076] It will be appreciated that step 710 could also be worded as the Responder RAN entity receiving the IKE protocol packet as described. Step 710 may be considered to implement part of step 320 of Figure 3. In step 720, the Responder RAN entity 702 transmits a second indication to the initiator RAN entity 701 that the second child IP addresses (and in some examples the first IP addresses) are supported by the responder for use in providing multiple child SA pairs managed by the first IKE SA. In other words, where the signalling of Figure 7a is utilised as an example implementation of step 320 of Figure 3, the Responder RAN entity 702 and the Initiator RAN entity 701 are both able to support the first child IP addresses and the second child IP addresses for use in providing multiple child SA pairs managed by the first IKE SA. It will be appreciated that the Responder RAN entity 702 may not be able to support all of the applicable IP addresses for the Initiator RAN entity 701. Furthermore, the Responder RAN entity 702 may be able to support other IP addresses outside of the applicable IP addresses.

[0077] In some examples, the second indication may indicate that the first child IP addresses are supported by the responder for use in providing multiple child SA pairs managed by the first IKE SA using multiple IP addresses. In certain embodiments, the second indication may comprise an indication that the plurality of applicable IP addresses are supported by the second RAN entity for use providing multiple child SA pairs managed by the first IKE SA. For example, the second indication may comprise a form of flag that indicates that all applicable IP addresses are supported.

[0078] In certain embodiments, the second indication comprises an indication that a subset of the plurality of applicable IP addresses are supported by the second RAN entity for use providing multiple child SA pairs managed by the first IKE SA. In other words, this type of second indication may in some way specifically call out which of the applicable IP addresses are supported by the second RAN entity. For example, the second indication may indicate one or more subnet of IP addresses that are supported, and / or specific IP addresses within a subnet or across multiple subnets that are supported.

[0079] In some examples, the steps 710 and 720 may be implemented as part of an IKE INIT and an IKE INIT Response message respectively.

[0080] In step 730, the Initiator RAN entity 701 and the Responder RAN entity 702 utilise the first IKE SA to negotiate the plurality of first child SA pairs, responsive to the Initiator RAN entity 701 receiving the second indication from the responder RAN entity 702 that the first child IP addresses and the second child IP addresses are supported by the responder RAN entity 702 for use in providing multiple child SA pairs managed by the first IKE SA. It will be appreciated that at least one of the first child IP address and the second child IP address may not be used in the provision of the first IKE SA.

[0081] It will be appreciated that in some circumstances, the Responder RAN entity 702 may not be able to support a plurality of the applicable IP addresses. In these examples, the Responder RAN entity 702 may transmit a second indication to the Initiator RAN entity 701 indicating that the applicable IP addresses are not support by the Responder RAN entity for use in providing multiple child SA pairs using multiple IP addresses managed by the first IKE SA. The Initiator RAN entity 701 and the Responder RAN entity 702 may then refrain from utilising the first IKE SA to negotiate the plurality of first child SA pairs, responsive to the Initiator RAN entity 701 receiving the second indication. In some examples the second indication comprises an indication of second child IP addresses supported by the Responder RAN entity 702, and in cases in which the Initiator RAN entity 701 does not support one or more of those second child IP addresses supported by the Responder RAN entity 702, the Initiator RAN entity 701 may refrain from utilizing the first IKE SA to negotiate the plurality of first child SA pairs using those one or more of the second child IP addresses that the Initiator RAN entity 701 does not support.

[0082] For example, when the capability proposed by the Initiator RAN entity 701 in a Notify payload (e.g. included in an Auth message) is not supported by the Responder RAN entity 702, the Responder RAN entity may not reply to the Notify payload and Initiator RAN entity 701 may then refrain from utilizing the capability. If a subset of the capability is supported by the Responder RAN entity 702, it may reply indicating the subset of the capability that it supports.

[0083] Enabling the RAN entities to refrain from utilising the first IKE SA to negotiate the plurality of first child SA pairs on multiple IP addresses if the Responder RAN entity 702 indicates that it does not support multiple IP addresses or any of the applicable IP addresses besides the IKE SA IP address for use in providing multiple Child SA pairs to be managed by the first IKE SA may increase the efficiency of applying IPsec between RAN entities in an IP network, as the first RAN entity may not needlessly consume resources attempting to negotiate a plurality of first child SA pairs that are not supported by the second RAN entity. It will be appreciated that Figure 7a is only one example of how the IKE SA may be utilized to negotiate the plurality of child SA pairs using multiple IP addresses. In other examples, it may be that the Initiator RAN entity indicates to the Responder RAN entity 702 that it is capable of providing multiple Child SA pairs using multiple IP addresses managed by the first IKE SA, without indicating the applicable IP addresses (e.g. with an new “Notfiy Message Type” value (e.g. Multiple Child SA type) as described below containing no information in the payload (notification data), or a flag in the payload indicating that the capability is supported). In this case, the Responder RAN entity 702 may respond with its applicable IP addresses (i.e. those IP addresses that the Responder RAN entity could support in providing multiple Child SA pairs). The Initiator RAN entity may then indicate to the Responder RAN entity which of the applicable IP address of the Responder RAN entity (if any) the Initiator RAN entity is able to support. It will be appreciated that there may be a number of ways in which the Initiator RAN entity and Responder RAN entity could negotiate which IP addresses at the two RAN entities can be supported for use in providing the multiple Child SA pairs.

[0084] In some embodiments, the first indication of step 710 comprises an indication of a subnet of IP addresses and / or an indication of the applicable IP addresses in one or more subnets of IP addresses. In some examples, the first indication indicates that any IP address is an applicable IP address. For example, when the Initiator RAN entity sends a first indication, the first indication may comprise IP-addresses supported by the Initiator and optionally a proposal on IP-addresses to be used by the Responder. The Initiator RAN entity IP addresses may be the specific addresses, and the proposed responder addresses may also be specific listed addresses or may indicate “Any addresses”, thus it’s up to Responder to decide and reply back in the second indication as to which IP addresses it wishes to use. It will appreciated that the equivalent may be utilized for the second indication, in that the Responder RAN entity may indicate specific IP-addresses and optionally the supported Initiator specific IP-addresses or all Initiator proposed IP- addresses.

[0085] In some embodiments, the first indication is comprised in a notify payload. The notify payload may comprise a notify message type field indicating that the notify payload comprises the first indication. Figures 8 to 10 illustrate an example implementation of how the first indication may be passed between the first RAN entity and the second RAN entity. In some embodiments, the second indication comprises an indication of a subnet of IP addresses and / or an indication of IP addresses in one or more subnets of IP addresses. In certain embodiments, the second indication is comprised in a notify payload. The notify payload may comprise a notify message type field indicating that the notify payload comprises the second indication.

[0086] Figure 7b illustrates an example implementation of the step 730 of Figure 7. In this example, step 730 is performed partly in an IKE AUTH message exchange, and partly in one or more Create Child SA message exchanges.

[0087] In step 740, the Initiator RAN entity 701 transmits an IKE AUTH message to the Responder RAN entity 702. The IKE AUTH message may indicate a specific IP address of the Initiator RAN entity for setting up a first Child SA. The Responder RAN entity may then transmit, in step 750 an IKE AUTH response message comprising a specific IP address of the Responder RAN entity 702 for setting up the first Child SA. The IKE AUTH message and response may comprise further information to authorize the IKE SA.

[0088] Steps 760 and 770 may then be performed for each of the remaining plurality of first Child SAs. In step 760, the Initiator RAN entity 701 transmits a Create Child SA message to the Responder RAN entity 702 comprising an indication of a specific IP address(es) of the Initiator RAN entity 701 and, optionally, the Responder RAN entity 702 for setting up a respective first Child SA. In step 770, the Responder RAN entity 702 transmits a Create Child SA response message to the Initiator RAN entity 701 comprising an indication of a specific IP address(es) of the Responder RAN entity 702 and, optionally, the Initiator RAN entity 701 for setting up the respective first Child SA. It will be appreciated that in some examples the Responder RAN entity 702 may initiate creation of a child SA (e.g. by transmitting the Create Child SA message in step 760). The setup of some Child SA pairs may be initiated by the Initiator RAN entity 701 and the setup of other Child SA pairs may be initiated by the Responder RAN entity 702.

[0089] It will be appreciated that steps 760 and 770 may be repeated until all the plurality of first Child SAs have been created.

[0090] Figure 8 illustrates an example of an IKEv2 Header Format. In an example implementation, existing IPsec protocols and procedures may be used, wherein a new capability is added to them. As shown in Figure 8, in IKEv2 IETF RFC7296 there is a defined main IKEv2 Header Format. The header format comprises an element called “Next Payload” 801 which indicated the type of the subsequent payload.

[0091] Figure 9 shows IKEv2 Next Payload Type.

[0092] As illustrated in Figure 8, comprised in the main IKEv2 Header format there is an element indicating the “Next Payload”. As shown in Figure 9, there are several different Next Payload Types currently defined. The structure comprises a chain of Next Payloads until the last payload, which then has the Next Payload as: No Next Payload.

[0093] Figure 10 illustrates an example of an IKEv2 Notify Payload Format.

[0094] As shown in Figure 9, one of the options for the value of “Next Payload” indicated in Figure 9 is the “Notify” 901 Payload type. Figure 10 illustrates the Payload format for the “Notify” payload type. The format has a field referred to as “Notify Message Type” 1001. This “Notify Message Type” field 1001 specifies different types of “Notification Messages” and the options for the values are of this field are currently organized in two groups: Error types and Status types of messages. Several of these Error / Status type Notification messages are defined. The purpose of the Status type messages is to indicate sender capabilities as part of the SA negotiation (non-cryptographic parameters), and to negotiate the use of these capabilities.

[0095] In the example implementation, a new “Notfiy Message Type” value (referred to herein as “Multiple Child SA”) may be added into the Status type group of messages. This Status type may negotiate the capability for the IKEv2 SA to handle IKEv2 negotiations for all IP addresses within a specific IP subnet, specific IP addresses within an IP subnet or specific IP addresses in separate IP subnets. For example, the first indication and / or second indication itself may be contained within the Notification data 1002 of the Notify Payload Format, with the Notify Message Type field being set as “Multiple Child SA Type”.

[0096] In step 740, the notification data 1002 of the Notify Payload Format may comprise the specific IP address of the Initiator RAN entity and optionally the Responder RAN entity for use in setting up the relevant Child SA pair. In step 750, the notification data 1002 of the Notify Payload Format may comprise the specific IP address of the Responder RAN entity ad optionally the Initiator RAN entity for use in setting up the relevant Child SA pair.

[0097] Similarly in step 760, the notification data 1002 of the Notify Payload Format may comprise the specific IP address(es) for use in setting up the relevant Child SA pair. In step 770, the notification data of the Notify Payload Format may comprise the specific IP address(es) of the Responder RAN entity and optionally the Initiator RAN entity for use in setting up the relevant Child SA pair.

[0098] The example implementation enables an indication between RAN entities of a plurality of supported IP addresses to be implemented simply, by modifying a currently used format. The modification of the currently used format may comprise adding a new Notify Message Type to the currently used structure with Notify messages, as discussed above. The example implementation may allow for simplified management, operations and maintenance, planning, RAN entity processing and memory, configuration work and network signalling.

[0099] Figure 11 illustrates a RAN entity 1 100 comprising processing circuitry (or logic) 1 101. The processing circuitry 1 101 controls the operation of the RAN entity 1100 and can implement the method described herein in relation to an RAN entity 1 100. The processing circuitry 1 101 can comprise one or more processors, processing units, multicore processors or modules that are configured or programmed to control the RAN entity 1100 in the manner described herein. In particular implementations, the processing circuitry 1101 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 RAN entity 1100. It will be appreciated that the RAN entity 1100 may comprise one or more virtual machines running different software and / or processes. The RAN entity 1100 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.

[0100] Optionally, the RAN entity 1 100 may comprise a memory 1 103. In some embodiments, the memory 1 103 of the RAN entity 1100 can be configured to store instructions (e.g. program code) executable by the processing circuitry 1 101 of the RAN entity 1100 whereby the apparatus is operable to perform the method as described with reference to Figure 3.

[0101] Alternatively or in addition, the memory 1 103 of the RAN entity 1100, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1 101 of the RAN entity 1100 may be configured to control the memory 1 103 of the RAN entity 1 100 to store any requests, resources, information, data, signals, or similar that are described herein.

[0102] In some embodiments, the RAN entity 1 100 may optionally comprise a communications interface 1 102. The communications interface 1 102 of the RAN entity 1100 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1 102 of the RAN entity 1100 can be configured to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1 101 of RAN entity 1100 may be configured to control the communications interface 1 102 of the RAN entity 1100 to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The communications interface 1102 can use any suitable communication technology.

[0103] The RAN entity 1 100 may be configured operate in the manner described herein in respect of an RAN entity. It will be appreciated that the RAN entity 1100 may comprise a first RAN entity or a second RAN entity, and may comprise an Initiator RAN entity or a Responder RAN entity.

[0104] There is also provided a computer program comprising instructions which, when executed on a least one processor (such as the processing circuitry 1101 of the RAN entity 1 100 described earlier), cause the processor to carry out at least part of the method(s) described herein. According to some embodiments there is provided a carrier containing the computer program. In some embodiments, the carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable medium. There is also provided a (for example, tangible and / or non-transient) computer-readable medium comprising instructions which, when executed by at least one processor, cause the at least one processor to perform at least part of the method(s) described herein.

[0105] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a 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 claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

22CLAIMS1 . A method, performed by a first Radio Access Network, RAN, entity (410), for applying transport security in transmitting data between the first RAN entity and a second RAN entity (420), the first RAN entity being associated with a plurality of first entity IP addresses, and the second RAN entity being associated with a plurality of second entity IP addresses, the method comprising: setting up (310) a first internet key exchange, IKE, security association (402), SA, between a first Internet Protocol, IP, address of the first entity IP addresses and a second IP address of the second entity IP addresses; and utilising (320) the first IKE SA to negotiate a plurality of first child SA pairs (404a, 404b, 404c, 404d, 404e), wherein the plurality of first child SA pairs are set up between first child IP addresses of the plurality of first entity IP addresses and second child IP addresses of the plurality of second entity IP addresses.

2. The method as claimed in claim 1 further comprising: for each first child SA pair in the plurality of first child SA pairs: negotiating (330) one or more security keys using the first IKE SA; and utilising (340) the one or more security keys to transmit data between the first RAN entity and the second RAN entity using the first child SA pair.

3. The method as claimed in claim 1 or 2, wherein the first IP address comprises an IP address of a first port (412) of the first RAN entity and the second IP address comprises an IP address of a second port (422) of the second RAN entity.

4. The method as claimed in any one of claims 1 to 2, wherein the first IP address comprises an IP address of a first central processing unit, CPU (511), of the first RAN entity and the second IP address comprises an IP address of a second CPU (512) of the second RAN entity.

5. The method as claimed in claim 1 to 4, wherein the first child IP addresses comprise a plurality of IP addresses of the first port (412) of the first RAN entityand the second child IP addresses comprises a plurality of IP addresses of the second port (422) of the second RAN entity.

6. The method as claimed in any one of claims 1 to 5 wherein setting up the first IKE SA comprises: transmitting (710) an IKE protocol packet to the second RAN entity comprising a first indication of a plurality of applicable IP addresses, wherein the applicable IP addresses are supported by the first RAN entity for use providing multiple child SA pairs managed by the first IKE SA, wherein the first child IP addresses are comprised within the plurality of applicable IP addresses.

7. The method as claimed in claim 6, further comprising: performing utilising the first IKE SA to negotiate the plurality of first child SA pairs, responsive to receiving (720) a second indication from the second RAN entity that the first child IP addresses and the second child IP addresses are supported by the second RAN entity for use in providing multiple child SA pairs managed by the first IKE SA.

8. The method as claimed in any one of claims 6 to 7, further comprising: refraining from utilising the first IKE SA to negotiate the plurality of first child SA pairs, responsive to receiving a second indication from the second RAN entity that the applicable IP addresses are not supported by the second RAN entity for use providing multiple child SA pairs using multiple IP addresses managed by the first IKE SA.

9. The method as claimed in any one of claims 1 to 5 wherein setting up the first IKE SA comprises: receiving an IKE protocol packet from the second RAN entity comprising a first indication of a plurality of applicable IP addresses, wherein the applicable IP addresses are supported by the second RAN entity for use providing multiple child SA pairs managed by the first IKE SA using multiple IP addresses.

10. The method as claimed in claim 9, further comprising:performing utilising the first IKE SA to negotiate the plurality of first child SA pairs, responsive to the first RAN entity being able to support the first child IP addresses and the second child IP addresses for use in providing multiple child SA pairs managed by the first IKE SA using multiple IP addresses.11 . The method as claimed in claim 10, further comprising transmitting a second indication to the second RAN entity that the first child IP addresses and the second child IP addresses are supported by the first RAN entity for use in providing multiple child SA pairs managed by the first IKE SA.

12. The method of claim 6 to 11 , wherein the first indication comprises an indication of a subnet of IP addresses.

13. The method of claim 6 to 1 1 , wherein the first indication comprises an indication of the applicable IP addresses in one or more subnets of IP addresses.

14. The method as claimed in claim 6 to 13, wherein the first indication is comprised in a notify payload.

15. The method as claimed in claim 14 wherein the notify payload comprises a notify message type field indicating that the notify payload comprises the first indication.

16. The method as claimed in any one of claims 7, 8, 1 1 to 15, when dependent on claims 7 or 1 1 , wherein the second indication comprises an indication that the plurality of applicable IP addresses are supported for use providing multiple child SA pairs managed by the first IKE SA.

17. The method as claimed in claim 16, wherein the second indication comprises an indication that a subset of the plurality of applicable IP addresses are supported by the second RAN entity for use providing multiple child SA pairs managed by the first IKE SA.

18. The method as claimed in any preceding claim further comprising: setting up a second IKE SA between a third IP address of the first entity IP addresses and a fourth IP address of the second entity IP addresses; and25 utilising the second IKE SA to negotiate a plurality of second child SA pairs, wherein each of the plurality of second child SA pairs is set up between a third child IP address of the first entity IP addresses and a fourth child IP address of the second entity IP addresses.

19. A first Radio Access Network, RAN, entity (410) for applying transport security in transmitting data between the first RAN entity and a second RAN entity (420), the first RAN entity being associated with a plurality of first entity IP addresses, and the second RAN entity being associated with a plurality of second entity IP addresses, the first RAN entity comprising processing circuitry (1 101 ) and a memory (1103), the memory containing instructions executable by the processing circuitry whereby the first RAN entity is operable to: set up (310) a first internet key exchange, IKE, security association, SA, between a first Internet Protocol, IP, address of the first entity IP addresses and a second IP address of the second entity IP addresses; and utilise (320) the first IKE SA to negotiate a plurality of first child SA pairs, wherein the plurality of first child SA pairs are set up between first child IP addresses of the plurality of first entity IP addresses and second child IP addresses of the plurality of second entity IP addresses.

20. The first RAN entity as claimed in claim 19, wherein the memory further contains instructions executable by the processing circuitry whereby the first Ran entity is operable to perform the method as claimed in any one of claims 2 to 18.21 . A computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any of claims 1 to 18.

22. A carrier containing the computer program according to claim 21 , wherein the carrier comprises one of an electronic signal, optical signal, radio signal or computer readable storage medium.

23. A computer-readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to any of claims 1 to 18.2624. A computer program product comprising non transitory computer readable media having stored thereon a computer program according to claim 21 .

Images