Patent ID: 12206649

DETAILED DESCRIPTION

FIG.1is a block diagram illustrating an exemplary 5G system network architecture. The architecture inFIG.1includes NRF100and SCP101, which may be located in the same home public land mobile network (HPLMN). As described above, NRF100may maintain profiles of available NF instances and their supported services and allow consumer NFs or SCPs to subscribe to and be notified of the registration of new/updated NF instances. SCP101may also support service discovery and selection of NF instances. SCP101may perform load balancing of connections between consumer and producer NFs.

NRF100is a repository for profiles of NF instances. In order to communicate with a producer NF instance, a consumer NF or an SCP must obtain the NF profile of the producer NF instance from NRF100. The NF profile is a JavaScript object notation (JSON) data structure defined in 3GPP TS 29.510. The NF profile includes attributes that indicate the type of service provided, capacity of the NF instance, and information for contacting the NF instance.

InFIG.1, any of the network functions can be consumer NFs, producer NFs, or both, depending on whether they are requesting, providing, or requesting and providing services. In the illustrated example, the NFs include a PCF102that performs policy related operations in a network, unified defined management (UDM)104that manages user data, and an application function (AF)106that provides application services.

The NFs illustrated inFIG.1further include an SMF108that manages sessions between AMF110and PCF102. AMF110performs mobility management operations similar to those performed by a mobility management entity (MME) in 4G networks. An authentication server function (AUSF)112performs authentication services for user equipment (UEs), such as user equipment (UE)114, seeking access to the network.

A network slice selection function (NSSF)116provides network slicing services for devices seeking to access specific network capabilities and characteristics associated with a network slice. A network exposure function (NEF)118provides application programming interfaces (APIs) for application functions seeking to obtain information about Internet of things (IoT) devices and other UEs attached to the network. NEF118performs similar functions to the service capability exposure function (SCEF) in 4G networks.

A radio access network (RAN)120connects user equipment (UE)114to the network via a wireless link. Radio access network120may be accessed using a g-Node B (gNB) (not shown inFIG.1) or other wireless access point. A user plane function (UPF)122can support various proxy functionality for user plane services. One example of such proxy functionality is multipath transmission control protocol (MPTCP) proxy functionality. UPF122may also support performance measurement functionality, which may be used by UE114to obtain network performance measurements. Also illustrated inFIG.1is a data network (DN)124through which UEs access data network services, such as Internet services.

SEPP126filters incoming traffic from another PLMN and performs topology hiding for traffic exiting the home PLMN. SEPP126may communicate with a SEPP in a foreign PLMN which manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs may traverse two SEPP functions, one for the home PLMN and the other for the foreign PLMN.

As stated above, security issues with 5G and other types of networks include the lack of validation of security handshake procedures on inter-PLMN interfaces, such as the N32-c interface, and the burden of manual configuration at the SEPP to perform such validation for every inter-PLMN handshake.FIG.2is a network diagram illustrating inter-PLMN interfaces between SEPPs. Referring toFIG.2, SEPPs126A and126B communicate with each other over the N32-c and N32-f interfaces. The N32-c interface is a control plane interface between SEPPs126A and126B for performing an initial security handshake and negotiating parameters to be applied for forwarding of data on the N32-f interface. The N32-f interface between SEPPs126A and126B is a forwarding interface used for forwarding communications between NF service consumers and NF service producers after applying application level security protection. The N32-f interface can utilize transport layer security (TLS) or protocol for N32 interconnect security (PRINS). PRINS is only applicable when there are IP exchange (IPX) services in the path between PLMNs. The subject matter described herein relates to methods systems and computer readable media for selectively validating data on the N32-c interface during the N32-c security handshake procedure.

FIG.3is a message flow diagram illustrating an inter-PLMN security handshake procedure, which is referred to in 3GPP TS 29.573 as the N32-c security capability negotiation procedure. This procedure is used to share security capabilities between an initiating SEPP126A and a responding SEPP126B. The purpose of the N32-c security capability negotiation procedure is for the SEPPs to agree on the security procedure to use for N32-f communications. Referring to the message flow inFIG.3, in line 1, initiating SEPP126A sends an inter-PLMN security handshake request message to responding SEPP126B. The inter-PLMN security handshake request message is an HTTP POST message that a secNegotiateReqData information element (IE), which carries a sender FQDN (i.e., the FQDN of initiating SEPP126A), an identifier for the supported security capabilities (PRINS or TLS), an indicator as to whether the 3gpp-Sbi-Target-apiRoot header is supported, the sender PLMN ID(s) and the target PLMN ID.

If responding SEPP126B successfully processes the inter-PLMN security handshake request message, responding SEPP126B responds as indicated in line 2a with a 200 OK message containing a secNegotiateRspData IE, which carries a sender FQDN (i.e., the FQDN of responding SEPP126B), an identifier for the selected security capability (PRINS or TLS), whether the 3gpp-Sbi-Target-apiRoot HTTP header is supported, the sender PLMN ID(s), and an indicator of the purpose of the accepted N32 connection. If responding SEPP126B does not successfully process the inter-PLMN security handshake request message, responding SEPP126B responds as indicated in line 2b with a 4XX or 5XX message indicating problem details. It should be noted that there is no validation mechanism specified in 3GPP TS 29.573 for the data exchanged on the N32-c interface.

Table 1 shown below illustrates exemplary data communicated in the inter-PLMN security handshake request message on the N32-c interface.

TABLE 1Security Capability Data Carried in Inter-PLMN Security Handshake Request MessageAttribute NameData TypePCardinalityDescriptionsenderfqdnM1This IE shall uniquelyidentify the SEPP thatis sending therequest. This IE isused to store thenegotiated securitycapability against theright SEPP.supportedSecCapabilityarray(SecurityCapability)M1 . . . NThis IE shall containListthe list of securitycapabilities that therequesting SEPPsupports.3gpp-Sbi-booleanC0 . . . 1This IE should beTargetApiRootpresent and indicateSupportedthat the 3gpp-Sbi-Target-apiRoot HTTPheader is supported,if TLS security issupported for N32-fmessage forwarding.When present, it shallindicate if TLSsecurity using the3gpp-Sbi-Target-apiRoot HTTP headeris supported:true: supportedfalse (default): notsupportedplmnIdListArrayO1 . . . NA list of PLMN IDs(plmnId)associated with theSEPP, which issending the request.The list to be storedby the receivingSEPP in a N32-fContext (seeclause 5.9.3 in3GPP TS 33.501
From Table 1, the inter-PLMN security handshake request message carries the FQDN of the requesting SEPP and a list of PLMNs associated with the requesting SEPP as well as data identifying security capabilities supported by the requesting SEPP.

Table 2 shown below illustrates exemplary data returned in the response to the inter-PLMN security handshake request message.

TABLE 2Security Capability Data Carried in Inter-PLMN Security Handshake Response MessageAttribute NameData TypePCardinalityDescriptionsenderfqdnM1This IE shall uniquelyidentify the SEPP thatis sending theresponse. This IE isused to store thenegotiated securitycapability against theright SEPP.supportedSecCapabilityarray(SecurityCapability)M1 . . . NThis IE shall containListthe list of securitycapabilities selectedby the respondingSEPP.3gpp-Sbi-booleanC0 . . . 1This IE should beSupportedpresent and indicateTargetApiRootthat the 3gpp-Sbi-Target-apiRoot HTTPheader is supported,if TLS security issupported for N32-fmessage forwarding.When present, it shallindicate if TLSsecurity using the3gpp-Sbi-Target-apiRoot HTTP headeris supported:true: supportedfalse (default): notsupportedplmnIdListArrayO1 . . . NA list of PLMN IDs(plmnId)associated with theSEPP, which issending the request.The list to be storedby the receivingSEPP in a N32-fContext (seeclause 5.9.3 in3GPP TS 33.501)

In general, there exists a need for validation of data exchanged during the N32-c handshake and a mechanism that avoids the need for some of the manual configuration at the SEPP. A solution to this problem is selective N32-c handshake validation.FIG.4is a network diagram illustrating the need for selective N32-c handshake validation. InFIG.4, home SEPP126A protects communications between network functions400in the home PLMN and external PLMNs. Similarly, visited SEPP126B protects communications between network functions402in a visited PLMN and external PLMNs. The PLMN of SEPP126B is trusted by the operator of the home PLMN. Another visited SEPP126C protects communications between network functions404in another visited PLMN and external PLMNs. The PLMN of SEPP126C is untrusted by the network operator of the home PLMN.

If home SEPP126A is configured to validate N32-c handshake data using static configuration for every PLMN, this increases the operational burden on the operator of the home PLMN. There is a need for a mechanism by which home SEPP126A can perform inter-PLMN security handshake validation for untrusted or unknown PLMNs and refrain from performing N32-c handshake validation for trusted PLMNs.

FIG.5illustrates operational challenges associated with N32-c handshake validation at SEPPs. Referring toFIG.5, SEPP126A is manually configured with remote PLMN information for SEPP126B to be used in verifying N32-c handshake procedures. For example, SEPP126A is configured with identifiers for PLMN2 and PLMN3 as the PLMNs of SEPP126B. Similarly, SEPP126B is manually configured with PLMN0 as the PLMN ID of SEPP126A. In line 1, SEPP126A, functioning as the initiating SEPP for the N32-c handshake procedure, sends an inter-PLMN security handshake request message to SEPP126B. The message identifies PLMN0 as the PLMN of SEPP126A. SEPP126B receives the message, validates the PLMN identifier PLMN0 against the manually configured inter-PLMN security handshake validation data, and responds with an inter-PLMN security handshake response message carrying N32-c security capability parameters accepted by SEPP126B.

When a network configuration change at SEPP126A causes its local PLMN ID list to include PLMN1 in addition to PLMN0, SEPP126A sends an inter-PLMN security handshake request message to SEPP126B to register PLMN1 as an additional PLMN of SEPP126A. In this example, the local inter-PLMN security handshake validation data stored at SEPP126B is not up to date. Accordingly, SEPP126B rejects the inter-PLMN security handshake request message. Keeping the inter-PLMN security handshake validation data at each SEPP in sync with network configuration changes results in operational overhead for network operators.

FIG.6illustrates a security issue that can occur when inter-PLMN security handshake validation is not performed. Referring toFIG.6, in line 1, SEPP126A initiates an N32-c security capabilities handshake procedure with SEPP126B. SEPP126A includes its PLMN Id, PLMN0, in the PLMN ID list in the inter-PLMN security handshake request message. In line 2 of the message flow diagram, SEPP126B responds with a 200 OK message indicating successful completion of the N32-c handshake procedure.

In line 3 of the message flow diagram, SEPP126C initiates an N32-c handshake procedure with SEPP126B. SEPP126C includes the PLMN ID of the PLMN of SEPP126A in the inter-PLMN security handshake request message. The N32-c handshake is successful because SEPP126B does not validate the PLMN ID list presented by SEPP126C in the inter-PLMN security handshake request message. SEPP126C should not be able to register a PLMN ID that is outside of the administrative domain of its network operator. Validation at the TLS layer does not restrict an SEPP from using a PLMN that is outside of its network operator's administrative domain. Accordingly, the failure to validate inter-PLMN security handshake messages can allow an untrusted SEPP or a hacker to register a PLMN that it is not authorized to register with another SEPP. Such a result is undesirable as the untrusted SEPP or hacker could receive data intended for the PLMN without authorization.

In order to avoid at least some of these difficulties, an SEPP can be configured to perform selective inter-PLMN security handshake validation based on trust information configured for remote SEPPs.FIG.7is a message flow diagram illustrating exemplary messages exchanged for selective inter-PLMN security handshake validation. InFIG.7, SEPP126B includes, in addition to a security handshake validation database, an SEPP trust relationship database that contains data indicative of trust relationships with remote SEPPs. In the illustrated example, SEPP126B is configured to identify SEPP126A as trusted and SEPP126C as untrusted. In an alternate implementation, the SEPP trust relationship database may contain the identifiers of trusted SEPPs only, and the absence of an SEPP identifier in the SEPP trust relationship database may indicate that the SEPP is untrusted or unknown. The SEPP trust relationship database may be a security policy database of a network operator that contains security policies defined by the network operator. The SEPP trust relationship database may be shared across SEPPs of the network operator.

Referring to the message flow inFIG.7, in line 1, SEPP126A initiates an N32-c handshake with SEPP126B. SEPP126B accesses its SEPP trust configuration database using SEPP-identifying information from the inter-PLMN security handshake request message and determines that SEPP126A is trusted. Accordingly, SEPP126B accepts and processes the inter-PLMN security handshake request message without performing an inter-PLMN security handshake validation. SEPP126B registers the PLMN IDs carried in the inter-PLMN security handshake request message as being associated with SEPP126A. In line 2, SEPP126B sends a 200 OK message to SEPP126A containing the security capability information illustrated above in Table 2 and confirming successful processing of the inter-PLMN security handshake request message.

In line 3 of the message flow diagram, SEPP126C initiates an N32-c handshake procedure with SEPP126B by sending an inter-PLMN security handshake request message to SEPP126B. SEPP126B receives the inter-PLMN security handshake request, performs a lookup in its SEPP trust relationship database using SEPP-identifying information from the message, and determines, based on results of the lookup, that SEPP126C is untrusted. Accordingly, SEPP126B performs an inter-PLMN security handshake validation by comparing the PLMN IDs in the PLMN ID list carried in the message with the stored configuration data for SEPP126C. In this example, SEPP126C is attempting to register PLMN0, and the configuration data indicates that SEPP126C should not be able to register PLMN0 because PLMN0 is not configured for untrusted SEPP126C. Accordingly, in line 4 of the message flow diagram, SEPP126B rejects the inter-PLMN security handshake request message.

In line 5 of the message flow diagram, SEPP126A sends a new inter-PLMN security handshake request message to SEPP126B to update the PLMN list associated with SEPP126A to include PLMN1. Because SEPP126A is trusted, SEPP126B accepts the inter-PLMN security handshake request message, updates the PLMN ID list for SEPP126A to include PLMN1, and responds in line 6 with a 200 OK message. Thus, performing selective inter-PLMN security handshake validation based on trust relationships enables SEPPs to update their local PLMN ID information with other SEPPs without security validation, while providing security validation for untrusted or unknown SEPPs.

FIG.8is a block diagram illustrating an exemplary architecture for an SEPP capable of performing selective inter-PLMN security handshake validation. Referring toFIG.8, SEPP126A includes at least one processor800and a memory802. SEPP126A further includes a selective inter-PLMN security handshake validator804for selectively validating inter-PLMN handshake exchanges. Selective inter-PLMN security handshake validator804may access an SEPP trust relationship database806to determine whether or not to validate inter-PLMN security handshake exchanges. In one example, SEPP trust relationship database806may contain identifiers, such as FQDNs, of trusted SEPPs. In such an implementation, selective inter-PLMN security handshake validator804may perform a lookup in SEPP trust relationship database806using the sender FQDN read from an inter-PLMN security handshake request message. If the sender FQDN matches one of the FQDNs for trusted SEPPs in SEPP trust relationship database806, selective inter-PLMN security handshake validator804may determine that the SEPP is trusted and register the PLMN IDs carried in the inter-PLMN security handshake request message without performing the inter-PLMN security handshake validation procedure. As described above, in another implementation, SEPP trust relationship database806may contain identifiers of trusted SEPPs and untrusted SEPPs along with indicators that identify the SEPPs as trusted or untrusted.

If selective inter-PLMN security handshake validator804determines that an inter-PLMN security handshake validation procedure is needed, selective inter-PLMN security handshake validator804may implement the inter-PLMN security handshake validation procedure by performing a lookup in an inter-PLMN security handshake validation database808using the sender FQDN from the inter-PLMN security handshake request message. Inter-PLMN security handshake validation database808may contain entries indexed by SEPP identifiers, such as FQDNs, and corresponding lists of PLMN IDs that each SEPP is permitted to register.

If the lookup in inter-PLMN security handshake validation database808fails to locate an entry corresponding to the sender FQDN, validation may fail. If the lookup results in an entry corresponding to the sender FQDN, selective inter-PLMN security handshake validator804may read the PLMN IDs stored in the PLMN ID list in the entry, compare the PLMN IDs read from the database entry to the PLMN IDs in the message, and if the PLMN IDs in the database entry match those in the message, accept and process the message. If the PLMN IDs in the database entry do not match the PLMN IDs in the message, selective inter-PLMN security handshake validator804may reject the message. Selective inter-PLMN security handshake validator804may be implemented using computer executable instructions stored in memory802and executed by processor800. SEPP trust relationship database806and inter-PLMN security handshake validation database may be stored in memory802.

FIG.9is a flow chart illustrating an exemplary process for selective inter-PLMN security handshake validation. Referring toFIG.9, in step900, the process includes receiving, at an SEPP, a first inter-PLMN security handshake request message. For example, selective inter-PLMN security handshake validator804may receive a request for initiating an N32-c security capability exchange procedure. As described above with regard toFIG.3, the request may be an HTTP POST message that carries N32-c security capabilities information.

In step902, the process includes performing, by the SEPP and in an SEPP trust relationship database, a lookup to determine whether the first inter-PLMN security handshake request message originates from a trusted SEPP. For example selective inter-PLMN security handshake validator804may determine whether the originator of the inter-PLMN security handshake request message is a trusted SEPP by performing a lookup in SEPP trust relationship database806using SEPP-identifying information read from the inter-PLMN handshake request message. In one example, the SEPP-identifying information comprises the sender FQDN read from the security negotiate request data carried by the inter-PLMN security handshake request message. Selective inter-PLMN security handshake validator804may compare the sender FQDN read from the message to FQDN values in SEPP trust relationship database806.

In step904, the process includes determining, by the SEPP and based on the lookup, that the first inter-PLMN security handshake request message does not originate from a trusted SEPP. For example, inter-PLMN security handshake validator804may determine that the sender FQDN read from the inter-PLMN security handshake request message is not present or is present and is identified as untrusted in SEPP trust relationship database806.

In step906, the process includes, in response to determining that the first inter-PLMN security handshake request message does not originate from a trusted SEPP, performing a security handshake validation procedure on the first inter-PLMN security handshake request message. For example, selective inter-PLMN security handshake validator804may read the PLMN ID list and the sender FQDN from the first inter-PLMN security handshake request message, perform a lookup in inter-PLMN security handshake validation database808using the sender FQDN, and read the PLMN IDs configured in the database for the sender FQDN.

In step908, the process includes determining that the first inter-PLMN security handshake request message fails the inter-PLMN security handshake validation procedure. Selective inter-PLMN security handshake validator804may determine that the message fails the validation procedure if the originator of the message is not authorized to register one or more of the PLMN IDs carried in the message. For example, if the sender FQDN read from the message is not present in inter-PLMN security handshake validation database808or, if the sender FQDN read from the message is present in inter-PLMN security handshake validation database808and any of the PLMN IDs read from the PLMN ID list in the message are not present in the database entry corresponding to the sender FQDN, inter-PLMN security handshake validator804may determine the message fails the inter-PLMN security handshake validation procedure.

In step910, the process includes, in response to determining that the first inter-PLMN security handshake request message fails the inter-PLMN security handshake validation procedure, performing a network protective operation. For example, selective inter-PLMN security handshake validator804may reject an inter-PLMN security handshake request message, such as a request for initiating an N32-c security capability exchange procedure, in response to determining that an originator of the message identified by the sender FQDN is not authorized to register one or more of the PLMN IDs carried in the message

Exemplary advantages of the subject matter described herein include providing security on inter-PLMN interfaces, such as the N32-c interface while reducing the amount of manual configuration required to provide security on such interfaces.

The disclosure of each of the following references is hereby incorporated herein by reference in its entirety.

REFERENCES

1. 3rdGeneration Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G system (5GS); Stage 2 (Release 17) 3GPP TS 23.501 V17.4.0 (2022-03)2. 3rdGeneration Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 17) 3GPP TS 23.502 V17.4.0 (2022-03)3. 3rdGeneration Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Technical Realization of Service Based Architecture; Stage 3 (Release 17) 3GPP TS 29.500 V17.6.0 (2022-03)4. 3rdGeneration Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Principles and Guidelines for Services Definition; Stage 3 (Release 17) 3GPP TS 29.501 V17.5.0 (2022-03)5. 3rdGeneration Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 17) 3GPP TS 29.510 V17.5.0 (2022-03)6. 3rdGeneration Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Public Land Mobile Network (PLMN) Interconnection; Stage 3 (Release 17) 3GPP TS 29.573 V17.4.0 (2022-03)7. 3rdGeneration Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing, and identification; (Release 17) 3GPP TS 23.003 V17.5.0 (2022-03)8. 3rdGeneration Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G system (Release 17) 3GPP TS 33.501 V17.5.0 (2022-03)

It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.