Message filtering and policy control for non roaming scenario

Abstract

A method for establishing a trust boundary between a non-public network and a further network, the method comprising: providing a logical interface configured to negotiate compatibility between the non-public network and the further network; wherein the logical interface comprises one or more non-public interface information element that indicates the purpose of the signalling between the non-public network and the further network.

Description

[0001] MESSAGE FILTERING AND POLICY CONTROL FOR NON ROAMING SCENARIO

[0002] FIELD OF THE INVENTION

[0003] This invention relates to a method and apparatus for establishing a trust boundary between a non-public network and a further network.

[0004] BACKGROUND

[0005] Non-public (private) networks are intended for the sole use of a private entity or enterprise and can be deployed in various models and architectures either as standalone networks or connected to wider network configurations. The current standards allow for private networks to be deployed in standalone networks, such private networks can be hosted by a Public Land Mobile Network (PLMN) or they can be offered through a slice of the Public Land Mobile Network.

[0006] There are two main types of Public Network Integrated Non-Public Network (PNI-NPNs) models with dedicated Network Functions (NF s) that are deployed in user premises are of interest to the 5G standards.

[0007] The first example of such a model is shown in Figure 1 of the present disclosure in which a dedicated User Plane Function (UPF) is deployed by users in their premises. All Control Plane (CP) functions rely on network functions that are deployed in the user’s premises. The interface between the user’s premises and the operator premises is shown in Figure 1 as N4, which at present in the art is a non-Service Based Architecture (SBA) interface.

[0008] The second example is shown in Figure 2 of the present disclosure, which demonstrates a dedicated User Plane Function (UPF) and part of the Control Plane functions are deployed in user premises. In the example of Figure 2 the interface between user premises and operator premises is a Service Based Architecture interface.

[0009] The problem with these models is that the interface between private and public networks is not a secure one and as such it is vulnerable to attacks from malicious parties.

[0010] Dedicated Network Functions deployed on user premises are susceptible to various risks, such as weaker physical security and operational errors. While current Network Domain Security / Intemet Protocol and Service Based Architecture security measures provide authentication, confidentiality, integrity, and anti-replay protection, they fall short in safeguarding Public Land Mobile Networks from attacks leveraging compromised dedicated Network Functions at the hosted Public Network Integrated Non-Public Network. Such attacks may include Distributed Denial-of-Service (DDoS) attacks, malformed signalling messages, and exposure of topology information.

[0011] Attack assumptions are in some cases created to build the necessary mitigation to address the problem described for example insider threat, third party vendor risks, supply chain compromise, disgruntled employees, weak security practices.

[0012] It is therefore desirable to develop an approach that can overcome at least some of the above issues.

[0013] SUMMARY OF THE INVENTION

[0014] According to one aspect of this disclosure there is provided a method for establishing a trust boundary between a non-public network and a further network, the method comprising: providing a logical interface configured to negotiate compatibility between the non-public network and the further network; wherein the logical interface comprises one or more non-public interface information element that indicates the purpose of the signalling between the non-public network and the further network. This provides the advantage of providing security to home public land mobile network from threats that originated from hosted private networks. The method as described above further comprising: providing a security edge protection proxy at the trust boundary between the non-public network and the further network; wherein the security edge protection proxy is configured to allow secure communication between the non-public network and the further network based on the logical interface. This provides a first line of defence for private networks that are logically considered part of the HPLMN but marked as untrusted.

[0015] The method as described above, wherein the further network is a public land mobile network, PLMN. This allows the further network that is to be protected to be a public network.

[0016] The method as described above, wherein the logical interface is a modified N32 logical interface that comprises one or more non-public network information element. This allows for a fast adaptation of current logical interfaces in order to provide security to HPLMN from threats that have originated from hosted private networks.

[0017] The method as described above, wherein the logical interface is a non-public network logical interface that only comprises one or more non-public network data type and one or more corresponding non-public network information element. This separates the need to rely on a logical interface which is typically used for Inter-PLMN communication.

[0018] The method as described above, wherein the one or more non-public network data type comprises an identifier for the corresponding one or more non-public network information element. This provides an additional data type and means for identifying the non-public network information elements.

[0019] The method as described above, further comprising: performing compatibility negotiation by: signalling between the non- public network and the further network based on the logical interface without exchanging data parameters; and transmitting data parameters of data service providers of the further network. This provides the ability to establish a connection without the need to exchange data parameters.

[0020] The method as described above, further comprising: receiving a logical interface; and modifying the received logical interface to include the one or more non-public interface information element that indicates the purpose of the signalling between the non-public network and the further network. This allows the logical interface to be formed prior to the method of the present disclosure.

[0021] According to a another aspect of this disclosure there is provided a system for establishing a secure connection between a non- public network and a further network, the system comprising: a trust boundary between the non-public network and the further network; a stored logical interface configured to negotiate compatibility between the non-public network and the further network; and one or more processors configured to perform compatibility negotiation based on the logical interface; wherein the logical interface comprises one or more non-public interface information element that indicates the purpose of the signalling between the non-public network and the further network. This provides the advantage of providing security to home public land mobile network from threats that originated from hosted private networks.

[0022] The system as described above, wherein the trust boundary comprises a security edge protection proxy between the non-public network and the further network; wherein the security edge protection proxy is configured to allow secure communication between the non-public network and the further network based on the logical interface. This provides a first line of defence for private networks that are logically considered part of the HPLMN but marked as untrusted. The system as described above, wherein the further network is a public land mobile network, PLMN. This allows the further network that is to be protected to be a public network.

[0023] The system as described above, wherein the logical interface is a modified N32 logical interface that comprises one or more non-public network information element. This allows for a fast adaptation of current logical interfaces in order to provide security to HPLMN from threats that have originated from hosted private networks.

[0024] The system as described above, wherein the logical interface is a non-public network logical interface that only comprises one or more non-public network data type and one or more corresponding non-public network information element. This separates the need to rely on a logical interface which is typically used for Inter-PLMN communication.

[0025] The system as described above, wherein the one or more non-public network data type comprises an identifier for the corresponding one or more non-public network information element. This provides an additional data type and means for identifying the non-public network information elements.

[0026] The system as described above, wherein the one or more processors is further configured to: perform compatibility negotiation by: signalling between the non-public network and the further network based on the logical interface without exchanging data parameters; and transmitting data parameters of data service providers of the further network. This provides the ability to establish a connection without the need to exchange data parameters.

[0027] The system as described above, wherein the one or more processors are further configured to: receive a logical interface; and modify the received logical interface to include the one or more non-public interface information element that indicates the purpose of the signalling between the non-public network and the further network. This allows the logical interface to be formed by a further system and transmitted to the system of the present disclosure.

[0028] BRIEF DESCRIPTION OF THE FIGURES

[0029] The present invention will now be described by way of example with reference to the accompanying drawings.

[0030] In the drawings:

[0031] Figure 1 illustrates an example of a PNI-NPN with dedicated a UPF deployed at user premises;

[0032] Figure 2 illustrates an example of a PNI-NPN with a dedicated UPF and part of control plane functions that are deployed in user premises;

[0033] Figure 3 illustrates an example of threat modelling based on STRIDE;

[0034] Figure 4 illustrates an example of a roaming 5G System architecture including a local breakout scenario in a service-based interface;

[0035] Figure 5 illustrates an example of a roaming 5G System architecture that includes a home routed scenario in a service-based interface;

[0036] Figure 6 illustrates an example of a 5G System architecture with access to a standalone non-public network that uses credentials from credentials holder based on Authentication server function (AUSF) and Unified Data Management (UDM);

[0037] Figure 7 illustrates an example of a SEPP perimeter boundary to build a trust boundary according to the present disclosure;

[0038] Figure 8 illustrates an example of a security capability exchange procedure between SEPP components on either side of the trust boundary;

[0039] Figure 9 illustrates an example of an end-to-end flow of signalling according to the first embodiment based on the use of intended purpose and 3gpp-sbi-interplmn-purpose;

[0040] Figure 10a illustrates an example of the creation of the logical interface N32’c; Figure 10b illustrates an example of the creation of the logical interface N32’f;

[0041] Figure 11 illustrates a further example of a security capability exchange procedure between SEPP components on either side of the trust boundary;

[0042] Figure 12 illustrates an example of an end-to-end flow of signalling according to the second embodiment based on the use of N32’ Intended purpose and 3gpp-sbi-intraplmn-purpose.

[0043] DETAILED DESCRIPTION

[0044] In light of the above issues in the art, it is beneficial to establish a trust boundary for Hosted Public Network Integrated NonPublic Network is essential to ensure an additional security layer for Public Land Mobile Networks, considering the potential threats posed by compromised dedicated Network Functions.

[0045] The threat model used for the purpose of forming attack assumptions may be STRIDE which determines the critical assets and categorises the threats and other supporting attributes to build the required knowledge to develop the mitigation. Some potential threats are outlined in Table 1 of the Figures. Table 1 illustrates threat modelling for Public Land Mobile Network hosting NonPublic Network control plane functions. Key critical assets determined based on the architecture described in Figure 1 and Figure 2 may be NRF, UDM and SBA. The determination of critical assets can change based on architecture. An example of this can be see in Figure 3, which illustrates threat modelling based on STRIDE. It is obvious from the mind map of Figure 3 that these threats may be classified in two segments that are either network specific or user specific. A high-level view of the map of Figure 3 reveals a sample of potential attacks that could be originated by the hosted Non-Public network towards the Home Public Land Mobile Network or in elevation of privilege Public Network Integrated Non-Public Network functions can attempt to attack other operators by indirect means using operator’s carrier network. In other words, there are a number of potential threats to the network that are external in origin.

[0046] It is therefore beneficial to introduce a trust boundary between network elements in order to mitigate the risk of these attacks. An example architecture that includes a trust boundary can be seen in Figure 4 depicts a 5G System roaming architecture with local breakout with service-based interfaces within the Control Plane. As can be seen in Figure 4, the boundary between the Home Public Land Mobile Network (HPLMN) and the Visiting Public Land Mobile Network (VPLMN) includes a Security Edge Protection Proxy (SEPP) boundary comprised of a visiting SEPP component and a home SEPP component. Similarly, Figure 5 depicts a 5G System roaming architecture in the case of home routed scenario with service-based interfaces within the Control Plane. As can be seen in Figure 5, there is also a SEPP (Security Edge Proxy Protection) layer.

[0047] In both scenarios a trust boundary is established between the visited network and the home network which is secured through a border network function known as SEPP (Security Edge Proxy Protection). The SEPP provides application layer security and restricts the flow of the information between VPLMN and HPLMN and also encrypts sensitive user information.

[0048] Similarly in Figure 6 depicts an example of a Standalone Non-Public Network (SNPN) where the credential holders are present in the Home Public Land Mobile Network, the communication happens through the SEPP layer which establishes the trust boundary between standalone private network and Home Public Land Mobile Network. In this example, the Standalone NonPublic Network may be accessed using credentials from Credentials Holder using AUSF and UDM.

[0049] Despite the introduction of the SEPP boundary in the examples of Figures 4 to 6, which does address the risk and threats towards the Home Public Land Mobile Network that may arise from the either Visiting Public Land Mobile Network or the Standalone Non-Public Network, it does not address the attack surface that may arise from the deployment where the Home Public Land Mobile Network is hosting the part of the services that are offered through Public Network Integrated Non-Public Network. It should be understood that the hybrid models as described in Figure 1 and Figure 2 are not considered as trusted by part of the operator network.

[0050] To address the non-exhaustive list of risks that encompass for Hosted PNI-NPN deployment model, there are various steps that can be undertaken through which the attack surface for these models can be reduced.

[0051] On such way that this present disclosure seeks to solve the above problems is to introduce a SEPP in a Hosted-Non-Public Network scenario. This is architecture is preferred as it allows topology hiding, rate limiting, malformed message handling and unauthorized signalling access.

[0052] The present disclosure therefore provides a system and method for establishing a trust boundary between a non-public network and a further network, the method comprising: providing a logical interface configured to negotiate compatibility between the non-public network and the further network; wherein the logical interface comprises one or more non-public interface information element that indicates the purpose of the signalling between the non-public network and the further network.

[0053] The solution of this disclosure may be implemented in two ways by establishing a trust boundary between a non-public network and a further network as shown in Figure 7. As shown in Figure 7, the present disclosure establishes a trust boundary between a Public Network Integrated Non-Public Network and a further network. The further network may in some cases be a public land mobile network, PLMN or home public land mobile network. The trust boundary may comprise a SEPP architecture that includes a Public Network Integrated SEPP and a home SEPP. The SEPP architecture may provide a logical interface configured to negotiate compatibility between the non-public network and the further network. The example embodiments of the present disclosure will be described in relation to a reference logical interface N32 that may be modified or replaced (N32’) as described later.

[0054] N32 may be considered a reference logical interface that that aims to provide security between serving and home network. In the context of the Hosted non-public network model where the network function doesn’t have a unique network identifier and relies on the network and user identities of the HPLMN it is then logically considered part of the network but is marked as untrusted. As such, it is important to build a first line of perimeter defence to mark the boundaries between Hosted non-public network and public land mobile network by introducing SEPP as in the present disclosure.

[0055] The first implementation may provide a modified logical interface which may be an extension of a known logical interface such as IntendedUsageolN32. The modified logical interface may include new information elements for the purpose of accommodating an architecture that includes a hosted non-public network.

[0056] In an alternative embodiment of the present disclosure the logical interface is a non-public network logical interface that only comprises one or more non-public network data type and one or more corresponding non-public network information element. In other words, the logical interface may be a logical interface N32’ which will address the Hosted NPN deployment model considering this traffic is still intra-PLMN but untrusted. The logical interface of this embodiment may comprise one or more non-public network information element that may be a new IntendedN32’purpose that will solely focus on the untrusted but intra-PLMN traffic. In addition, the logical interface of this embodiment may also introduce a one or more non-public network data type that comprises an identifier that corresponds to the one or more non-public network information element of this logical interface. In some cases, the one or more non-public network data type may be a new attribute 3gpp-Sbi-Intraplmn- Purpose. These two embodiments that are described herein as examples of implementation of the trust boundary of the present disclosure sure that the SEPP is able to adapt to security requirements of the network. In addition, in order for the SEPP to adapt potential security requirements there is a need to enhance the Security Capability Negotiation procedure where a definition for the hosted NPN may be needed.

[0057] Figure 8 illustrates an example of the security capability exchange procedure between SEPP components of the trust boundary of this disclosure. Figure 8 illustrates that the initiating SEPP may issue a HTTP POST request towards the responding SEPP across the trust boundary. The request body may comprise the non-public network information element, which may comprise "SecNegotiateReqData" IE. This may comprise the following information, supported security capabilities (i.e PRINS and / or TLS), whether the 3gpp-Sbi-Target-apiRoot HTTP header is supported, if TLS security is supported, sender PLMN identification (IDs) or SNPN identification, target PLMN ID or SNPN ID, purpose of the intended usage of N32 connection. As can be seen in Figure 8 a response signal 2a is then received by the initiating SEPP along with the problem details 2b.

[0058] As briefly discussed above, the present disclosure provides a method and system for establishing a trust boundary between a non-public network and a further network, the method comprising: providing a logical interface configured to negotiate compatibility between the non-public network and the further network; wherein the logical interface comprises one or more non-public interface information element that indicates the purpose of the signalling between the non-public network and the further network.

[0059] In both embodiments of the present disclosure the trust boundary may be comprised of a security edge protection proxy at the trust boundary between the non-public network and the further network. The security edge protection proxy may be configured to allow secure communication between the non-public network and the further network based on the logical interface. In other words the SEPP provides for increased security for the connections between the non-public network (private network) and the further network (that may be a HPLMN).

[0060] The first embodiment of the present disclosure builds on this by extending a reference logical interface, which may be a N32 logical interface, to include one or more non-public network information elements. This extends the intended usage of N32 during security capability negotiation procedure where a definition for the hosted PNI-NPN is required. At present the N32 purpose may indicate the intended purpose of inter-PLMN signalling and SNPN only. In other words, the non-public network information element that is comprised within the modified logical interface may define the purpose of the connection request in order verify and negotiate the security of the connection. An example of the extended purpose of the logical interface (N32) can be seen in Table 2. In Table 2 the purpose of the request may be understood to be the non-public network information element that is used to negotiate the connection over the SEPP trust boundary. The information elements that are included in order to form the modified logical interface are given as examples “HOSTED_NPN_INTERCONNECT” and “HOSTED_NPN_INTERCONNECT_TEST” in Table 2. In some cases the method and system of the present disclosure may be configured to receive a N32 logical interface; and modify the received N32 logical interface to include the one or more non- public interface information element that indicates the purpose of the signalling between the non-public network and the further network. In some examples, N32 specific data types where modification (extension) to the N32 logical interface included the inclusion of new intended purpose data (non-public network information elements) may be necessary. These information elements may comprise SecNegotiateReqData, SecNegotiateRspData and IntendedN32Purpose.

[0061] This will modify (extend) the 3gpp-sbi-interplmn-purpose to cater for hosted NPN, as the traffic to / from PNI hosted_NPN is considered untrusted and it is therefore beneficial to pass such communication through perimeter checks. In other words, the extension to the logical interface to include one or more non-public network information elements allows for security checks to be performed based on the purpose of the connection when a connection request is made. In some cases, there may also be a need to adapt the header (non-public network information elements) 3gpp-Sbi-Interplmn-Purpose that contains the intended purpose for inter-PLMN signalling. In such a scenario that may be envisaged as part of the first embodiment the non-public network information elements that comprise the header may be modified to include signalling that comprises the following,

[0062] Sbi-Interplmn-Purpose-Header = "3gpp-Sbi-Interplmn-Purpose:" OWS N32Purpose

[0063] As can be seen, the new non-public network information elements “HOSTED_NPN_INTERCONNECT” and "HOSTED_NPN_INTERCONNECT_TEST” are now included in the logical interface.

[0064] Figure 9 illustrates an end-to-end flow diagram depicting the negotiation procedure across the trust boundary established by the system and method of the present disclosure. Optionally, the method of the present disclosure may include the steps of the flow diagram of Figure 9. The signalling seen in Figure 9 of the present disclosure provides two advances on the art that can be classified broadly into two areas, the first is a change in the way security negotiations are performed and the other is a modification to the service request signalling. The steps of Figure 9 will now be described in relation to the Figure. Figure 9 depicts three main stages of establishing a connection between networks, which may be negotiation, parameter exchange and pay load delivery. During this process, signalling between the non-public network and the further network may be first performed based on the logical interface without exchanging data parameters, followed by the transmitting of data parameters of data service providers of the further network.

[0065] The first step of Figure 9 depicts the initial logical interface (N32-c) capability negotiation procedure between the PNI-Hosted non-public network and the further network, during which c-SEPP and p-SEPP trust boundary components are located at PNI- Hosted NPN and HPLMN / PLMN respectively. These two SEPP components share the list of the intended N32 purpose, which is set to Hosted NPN. The purpose parameters may be pre-provisioned to adapt the SEPP to accommodate for the connection with PNI-NPN. In other words, the SEPP components share common logical interface information elements. Once the modified logical interface N32 using the N32-c (N32c control plane) negotiation is successful, the second phase is the establishment of transport layer security (TLS) connection for the purpose of an N32-f forwarding plane.

[0066] In step 2 of Figure 9, a service request such as a Nnrf discovery request is then sent from the NF consumer to the NRF (central repository of network functions) to adapt with the Hosted NPN based on the non-public network information element “3gpp Sbi interplmn purpose” of the logical interface. This will allow the C-SEPP or P-SEPP components to perform security check based on the local policy. This is an example of parameter exchange that may be performed in the first embodiment of this disclosure. In Figure 9, step 3 of the end-to-end flow demonstrates that the SEPP trust boundary already includes the information captured from the security capability negotiation procedure (the negotiation performed with the logical interface) and therefore it may validate that based on the “3gpp Sbi interplmn purpose” signalling. If the validation is completed, implying the security check is completed by comparing the logical interface information elements then a service request may be forwarded on to the HPLMN for further handling.

[0067] At step 4 of Figure 9, a HPLMN NRF (network repository function) can be validated thus allowing the consumer NF (network function) to access producer NF resource based on the local policy using the new modified logical interface comprised of the new one or more non-public network information elements that may include “3gpp Sbi interplmn purpose”. If the policy check is passed, the NRF issues a token with the details of resource level access.

[0068] In step 5 of Figure 9, the network function consumer at the hosted non-public network may generate a service request signal and send this to the towards the NF producer in the HPLMN using the token issued in the step 4 of Figure 9. In other words, a token requesting payload delivery may be provided based on the validated security signalling based on the logical interface as earlier described.

[0069] In step 6 of Figure 9, one or more of the SEPP components, C-SEPP or P-SEPP perform validation ofthe service request based on a local policy based on the information elements adapted to support Hosted NPN settings. In step 7 of Figure 9, the network function producer at the HPLMN may perform a token integrity check and validate the token claims and ensure the token is genuinely issued by the NRF at the HPLMN. Additional security checks can be performed at the network function producer to restrict the service access based on the information element “3gpp Sbi interplmn purpose”. The end-to-end process of Figure 9 may optionally be performed as part of the method of this disclosure or may be performed post the method of this disclosure in the implementation of the trust boundary that is established by the method disclosed herein. In addition, the system of this disclosure may be configured using one or more processors to perform the method described herein that may include the steps of Figure 9 and described above.

[0070] In a second embodiment of the present disclosure there is presented a method for establishing a trust boundary between a non- public network and a further network as in the first embodiment, however instead of modifying a logical interface to include one or more new non-public network information elements, instead a new logical interface is created. The new logical interface does not introduce one or more non-public network information elements along with information elements related to other types of networks but instead creates a standalone logical interface that is only comprised of one or more non-public network data type and one or more corresponding non-public network information element. As such, the new logical interface in the second embodiment of this disclosure does is specific to the application of non-public networks for establishing and verification of a trust boundary.

[0071] A new logical interface N32’ (N32 prime) can be introduced that can primarily focus on the needs and requirements of the private networks specifically PNI-NPN. In the context of Hosted NPN model where the Hosted non-public network NF doesn’t have a unique network identifier and relies on the network and user identities of the HPLMN it is then logically considered part of the network but marked as untrusted. So, it is beneficial to build a first line of perimeter defence to mark the boundaries between Hosted NPN and PLMN. In other words, to establish a trust boundary as in the first embodiment. The features of the first embodiment are the same in the second embodiment with the exception of the logical interface, which may be thought of as a new logical interface in the second embodiment. In some cases, the method and system of this disclosure may be configured to receiving aN32 logical interface; and modifying the received N32 logical interface to include the one or more non-public interface information element that indicates the purpose of the signalling between the non-public network and the further network

[0072] Figure 10a depicts a new logical interface N32’-c. The N32’-c interface provides the functionality of an initial handshake between the SEPP in PLMN (in other words may perform the function of initiating SEPP) and the SEPP in Hosted NPN (the responding SEPP). This logical interface may include the capability to perform capability negotiation with no parameter exchange. No parameter exchange is referred to here in a context that there are three phases of connection establishment, negotiation, parameter exchange and the payload. Since the N32’c uses TLS only and not Protocol for N32 Interconnect Security (PRINS) then there is no need for the parameter exchange step. Intra / PLMN HTTP2 messages fall into a “service request” category. Figure 10b depicts creation of the logical interface N32’-f. The N32’-f interface may be used to forward the Intra-PLMN HTTP / 2 messages of the network function service producers and the network functions service consumers through the SEPPs. While PRINS itself is used in the Inter-PLMN scenario, it may not be applicable here and only TLS implementation may be suitable to be used with the Hosted NPN SEPP and PLMN SEPP. In order for the SEPP to adapt potential security requirements there is a need to create the Security Capability Negotiation procedure where definition for the hosted NPN is necessary at this in N32’c.

[0073] Figure 11 depicts the trust boundary of the second embodiment between the initiating SEPP and the responding SEPP components. Figure 11 therefore depicts the security exchange under the new logical network N32’c. A seen in Figure 11 , the initiating SEPP may issue a HTTP POST request towards the responding SEPP with the request body containing the "SecNegotiateReqData" IE carrying the following information as information elements, Supported security capabilities (i.e PRINS and / or TLS), whether the 3gpp-Sbi-Target-apiRoot HTTP header is supported, if TLS security is supported, sender PLMN ID(s) or SNPN ID(s), target PLMN ID or SNPN ID, purpose of the intended usage of the N32’ connection.

[0074] In this embodiment the method and system may create signalling related to the intended N32’purpose during negotiation and security capability exchange. The parameter forN32’Purpose may indicate the intended purpose of intra-PLMN signalling. As in the first embodiment the same data types are required and information elements which may be SecNegotiateReqData, SecNegotiateRspData, IntendedN32’Purpose. These however may be the only data types and information elements that are present in the logical interface of the second embodiment. An example of the extended purpose of the new logical interface (N32’) can be seen in Table 3. In Table 3 the purpose of the request may be understood to be the non-public network information element that is used to negotiate the connection over the SEPP trust boundary. As shown in Table 3 only the new logical interface only includes these data types and information elements. In addition, it may be necessary to create a new header as in the first embodiment that contains the intended purpose for intra-PLMN signalling to cater for hosted NPN, the header will contain the intended purpose for intra-PLMN signaling i.e “3gpp-Sbi-Intraplmn-Purpose” and may be of the form, Sbi-Intraplmn-Purpose-Header = "3gpp-Sbi-Intraplmn-Purpose:" OWS N32Purpose

[0075] N32’Purpose =

[0076] / "HOSTED_NPN_INTERCONNECT“

[0077] / "HOSTED_NPN_INTERCONNECT_TEST”.

[0078] Figure 12 of the present disclosure depicts and end-to-end flow according to the second embodiment that introduced one or more new non-public network data types as well as one or more non-public network information elements with the use of the new logical interface N32’ intended purpose and 3gpp-sbi-intraplmn-purpose.

[0079] In step 1 of Figure 12, there is shown the initial stage of the Initially, during the N32’-c capability negotiation, both the c-SEPP and p-SEPP components located at the PNI-Hosted non-public network and HPLMN respectively exchange their intended N32’ purposes, which are designated for the Hosted non-public network. This pre-configured parameter allows the SEPPs to establish a connection suited for the Public Network Integrated Non-Public Network. Following the successful N32’-c negotiation, a transport layer security connection is then established for the N32’-f forwarding plane.

[0080] In step 2 of Figure 12, service requests, such as Nnrf discovery, are adjusted to incorporate the "3gpp Sbi intraplmn purpose" information element of the logical interface. This addition enables the C-SEPP or P-SEPP components to enforce security checks based on predefined local policies.

[0081] Step 3 of Figure 12 depicts using information from the initial security negotiation, the SEPP verifies the "3gpp Sbi intraplmn purpose". Upon successful validation, the service request may then be forwarded to the HPLMN for further processing.

[0082] In step 4 of Figure 12, the HPLMN NRF assesses whether the consumer network function is permitted to access the producer network function resources based on local policy that may utilize the "3gpp Sbi intraplmn purpose." Upon passing the policy check, the NRF issues a token that specifies the access level to resources for the requesting network. In step 5 of Figure 12, the network function consumer at the Hosted NPN uses the issued token to make a service request to the network function producer in the HPLMN. In step 6 of Figure 12, the C-SEPP or P-SEPP components may perform validation of the service request, applying local policy using the adapted information elements for Hosted NPN settings. In step 7 of Figure 12, the network function producer at the HPLMN may conduct a token integrity check and validates the token claims, ensuring it was legitimately issued by the HPLMN NRF. Additional security checks may then be performed to restrict access based on the "3gpp Sbi intraplmn purpose".

[0083] In the second embodiment of the present disclosure the new logical interface may comprise one or more non-public network data type comprises an identifier for the corresponding one or more non-public network information element. This identifier can be used to identify the non-public network information element of the new logical interface to which it is associated.

[0084] There is also provided a system for establishing a secure connection between a non-public network and a further network according to this disclosure. The system may be configured to perform the methods discussed above in either embodiment or a variation thereof. The system may further comprise: a trust boundary between the non-public network and the further network and a stored logical interface configured to negotiate compatibility between the non-public network and the further network. The system may be comprised of one or more processors that are configured to perform the method discussed above. The system may be configured to implement a modified logical interface as described in the first embodiment or a new logical interface as described in the second embodiment.

[0085] The system and methods of the present disclosure provide a number of advantages in order to solve the aforementioned problems. These are that this disclosure introduces a SEPP-SEPP architecture to build the first line of defence for private networks that are logically considered part of the HPLMN but marked as untrusted. This provides topology hiding, and rate limiting the of the traffic and application layer security; it prevents malformed signalling from reaching the PLMN; it offers centralized policy control and message filtering. In addition, this architecture is capable of handling threats triggered through Hosted-NPN model for example, insider threats, supply chain compromise. It also prevents unauthorized access to producer resources without the consent thus reducing the risk of elevation of privilege.

[0086] Furthermore, the present disclosure extends the usage of intendedN32 purpose to support for Hosted NPN in the security capability exchange procedure in the N32 interface and extends the usage of 3gpp-sbi-interplmn-purpose to provide support for the hosted NPN during the service handling. This allows for quick adaption to provide security to HPLMN against threats that originate from hosted private networks. The present disclosure also creates a new logical interface N32’ that incorporates the IntendedN32’ purpose to support hosted NPNs during security capability exchange and creates an additional identifier 3gpp-sbi-intraplmn-purpose for the purpose of service handling that is entirely focused on private networks. Creating a new logical interface separates the need to rely on the N32 interface which is typically used for Inter-PLMN communication. N32’ can be solely used for private network communication where the enterprise doesn’t have unique network and user identifiers but rather relies on the operator for serving their users.

[0087] The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such individual feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

[0088]

[0089] Table 1

[0090]

[0091] Table 2

[0092]

[0093] Table 3

Claims

CLAIMS1. A method for establishing a trust boundary between a non-public network and a further network, the method comprising: providing a logical interface configured to negotiate compatibility between the non-public network and the further network; wherein the logical interface comprises one or more non-public interface information element that indicates the purpose of the signalling between the non-public network and the further network.

2. The method of claim 1 further comprising: providing a security edge protection proxy at the trust boundary between the non-public network and the further network; wherein the security edge protection proxy is configured to allow secure communication between the non-public network and the further network based on the logical interface.

3. The method of claim 1 or 2, wherein the further network is a public land mobile network, PLMN.

4. The method of any preceding claim, wherein the logical interface is a modified N32 logical interface that comprises one or more non-public network information element.

5. The method of any one of claims 1 to 3, wherein the logical interface is a non-public network logical interface that only comprises one or more non-public network data type and one or more corresponding non-public network information element .

6. The method according to claim 5, wherein the one or more non-public network data type comprises an identifier for the corresponding one or more non-public network information element.

7. The method of claim 5 or 6, further comprising: performing compatibility negotiation by: signalling between the non-public network and the further network based on the logical interface without exchanging data parameters; and transmitting data parameters of data service providers of the further network.

8. The method according to any preceding claim, further comprising: receiving a logical interface; and modifying the received logical interface to include the one or more non-public interface information element that indicates the purpose of the signalling between the non-public network and the further network .

9. A system for establishing a secure connection between a non-public network and a further network, the system comprising: a trust boundary between the non-public network and the further network; a stored logical interface configured to negotiate compatibility between the non-public network and the further network; and one or more processors configured to perform compatibility negotiation based on the logical interface; wherein the logical interface comprises one or more non-public interface information element that indicates the purpose of the signalling between the non-public network and the further network.

10. The system of claim 9, wherein the trust boundary comprises a security edge protection proxy between the nonpublic network and the further network; wherein the security edge protection proxy is configured to allow secure communication between the non-public network and the further network based on the logical interface.

11. The system of claim 9 or 10, wherein the further network is a public land mobile network, PLMN.

12. The system of any one of claims 9 to 11, wherein the logical interface is a modified N32 logical interface that comprises one or more non-public network information element.

13. The system of any one of claims 9 to 12, wherein the logical interface is a non-public network logical interface that only comprises one or more non-public network data type and one or more corresponding non-public network information element.

14. The system according to claim 13, wherein the one or more non-public network data type comprises an identifier for the corresponding one or more non-public network information element.

15. The system of claim 13 or 14, wherein the one or more processors is further configured to: perform compatibility negotiation by: signalling between the non-public network and the further network based on the logical interface without exchanging data parameters; and transmitting data parameters of data service providers of the further network.

16. The system according to any one of claims 9 to 15, wherein the one or more processors are further configured to: receive a logical interface; and modify the received logical interface to include the one or more non-public interface information element that indicates the purpose of the signalling between the non-public network and the further network.

Images