Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x
Top   in Index   Prev   Next

TR 33.874
Study on enhanced Security for Network Slicing Phase 2

V18.1.0 (Wzip)2022/09  12 p.
Rapporteur:
Dr. Lei, Zander (Zhongding)
HuaWei Technologies Co., Ltd

Content for  TR 33.874  Word version:  18.0.0

Here   Top

1  Scopep. 5

The present document identifies key issues, potential security and privacy requirements and solutions with respect to network slicing Phase 2 work TS 23.501, TS 23.502, TS 23.503 and studies TR 23.700-40 and TR 38.832, specifically,
  • Define the security requirements and security services for new NF(s) introduced for UEs' network slice access control.
  • Study potential security risks/threats (i.e. DoS, sensitive information leakage) and solutions if needed with respect to slice-related quota management, data rate limitation, and constraints on simultaneous use of slices.
  • Study potential security risks/threats related to broadcasting slice-related cell selection/reselection info, and provide security solutions if needed.
Up

2  Referencesp. 5

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TS 23.501: "System architecture for the 5G System (5GS)"
[3]
TS 23.502: "Procedures for the 5G System (5GS)"
[4]
TS 23.503: "Policy and charging control framework for the 5G System (5GS); Stage 2"
[5]
TR 23.700-40: "Study on enhancement of network slicing; Phase 2"
[6]
TR 38.832: "Study on enhancement of Radio Access Network (RAN) slicing"
[7]
TS 33.501: "Security architecture and procedures for 5G system"
Up

3  Definitions of terms, symbols and abbreviationsp. 5

3.1  Termsp. 5

For the purposes of the present document, the terms given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

3.2  Symbolsp. 6

Void

3.3  Abbreviationsp. 6

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

4  Key issuesp. 6

4.1  Key Issue #1: privacy issue on broadcasting slice informationp. 6

4.1.1  Key issue detailsp. 6

A gNB may support multiple and different network slices, and on different frequencies in different regions.
In TR 38.832, in order to support fast cell selection and cell reselection for particular network slices, solutions based on broadcasting slice related information are being studied. The broadcast slice related cell info may contain e.g. NSSAI, SST, slice grouping or slice associated information. In this key issue, the following questions are to be addressed:
  • Whether broadcasting slice related information in this scenarios will cause any privacy issue
  • If yes, mitigation solutions need to be provided
Up

4.1.2  Security threatsp. 6

According to TS 23.501, SST refers to the expected Network Slice behaviour in terms of features and services. An SST could be represented with a standardised SST value or without a standardised SST value. The currently standardized SST values can indicate the slice types of eMBB, URLCC, MIoT and V2X, from which sensitive information of a specific slice can hardly be derived. Hence there is no privacy issue if SST is included in the broadcast SIB.
An S-NSSAI is comprised of a SST and an optional Slice Differentiator (SD), which is to differentiate amongst multiple network slices of the same Slice/Service type. An S-NSSAI may contain privacy-sensitive information, e.g. when dedicated to a group of users may expose the group identity. An S-NSSAI may also contain sensitive information, e.g. network topology that the operator may not want to share with others.
A cell broadcasting sensitive S-NSSAI may become a target of attackers interested in the S-NSSAI information. It is likely for an attacker to further link the S-NSSAI with its UEs/users together with other knowledge/tools, e.g. a frequency band supports only the sensitive S-NSSAI or a few allowing attackers to narrow down the scope. Broadcasting sensitive S-NSSAI should be avoided.
Slice group information may or may not leak sensitive information depending on how the slice group is defined. For example, if a slice group is defined based on the standardized slice type or SST values, there may be no privacy issue as discussed above. S-NSSAIs with only SST values are valid slice identifiers. On the other hand, there may be cases that a not well designed slice group contains only one SST (used in an S-NSSAI as a valid slice identifier), one S-NSSAI or a few S-NSSAI having the same SD values thus exposing network topologies or being dedicated to special groups of users. In such a case, broadcasting group info may lead to leak of sensitive information.
Slice grouping information (slice group identity and group mapping info) is assumed to be delivered to UE through NAS signaling which is protected. The group identifier is broadcasted rather than Slice Group itself. The group identifier is to be defined to identify the slice group.
Therefore, the slice group information for which the slice group identifier is to be broadcasted needs to be defined taking into consideration the leakage of sensitive information.
Up

4.1.3  Potential security requirementsp. 7

Slice group information needs to be defined taking into consideration the possible leakage of sensitive information due to the group identifier being broadcasted.

4.2  Key Issue 2: DoS to NSAC procedurep. 7

4.2.1  Key issue detailsp. 7

A new Network Slice Admission Control (NSAC) procedure has been introduced in TS 23.501 and TS 23.502, where the number of registered UEs is monitored for a network slice (i.e. S-NSSAI) and a UE will be rejected to access if the number of UE registered in the requested S-NSSAI has reached its quota. However, the NSAC procedure needs to be studied further to address potential security risks, for examples:
  • In the current NSAC procedure, the number of registered UE in an S-NSSAI is updated independently from other S-NSSAIs during the registration procedure. In other words, the granularity level at registration is S-NSSAI. However, it is not the case in the de-registration procedure. The numbers are only updated when the UE exits from all network slices, i.e. de-registered. Since a UE may access multiple slices, e.g. eight, the UE would still be counted against quota usage of ALL S-NSSAIs even the UE is not using some or most of slices ("idly occupied" by the UE). This may lead to the quota reached fast which does not reflect the real usage of a slice. Other legitimate UEs will suffer from DoS - "dog in the mager". It is notable that an attacker can use legitimate UEs to launch such attacks.
  • The Early Admission Control (EAC) mode has been introduced where the admission control can be inactive if the number of UE bellows a pre-configured threshold. This may pose a security risk that exceeds the slice quota when a sudden increase in the slice registration requests, maliciously or accidentally.
Up

4.2.2  Security threatsp. 7

If EAC mode is not activated properly, it has the potential risk to cause unavailability of the network slices.

4.2.3  Potential security requirementsp. 7

The 5G system should prevent a potential risk due to the EAC inactive mode.

4.3  Key Issue #3: AF authentication and authorizationp. 7

4.3.1  Key issue detailsp. 7

As specified in TS 23.501 and TS 23.502, the current utilization state of a network slice, e.g. the number of UEs registered for a network slice or the current number of PDU Sessions established on a network slice, can be reported to an AF deployed within a 3GPP system or in a third party domain. In either case, the AF should be authenticated and authorized beforehand and the 5G system should make sure no sensitive information leakage.
In TS 23.502, a notification procedure has been specified to allow an AF to get access to the network slide information through NEF. However, it is not clear how the AF is authenticated and authorized. The authorization details (e.g. what parameters and whether slice-specific parameters need to be verified) need to be specified to avoid ambiguity and potential attacks. It is expected that the AF deployed within the 3GPP domain or a third party domain will be authenticated or authorized in a different way, which should be also studied and specified. In addition, the procedure needs to take into account the privacy issue of S-NSSAI since S-NSSAI may not be available at a third party AF due to concerns on the sensitivity information leakage (an S-NSSAI may not to be made known to a third-party AF).
Up

4.3.2  Security threatsp. 8

If an AF is not authenticated or authorized before accessing to the network slice information, a mischievous AF may collect such information for other purposes. If S-NSSAI is sent to a third party AF, sensitive information may leak out of 3GPP systems.

4.3.3  Potential security requirementsp. 8

S-NSSAI information shall not be sent to a third party AF for network slice quota-usage notification.

5  Solutionsp. 8

5.1  Solution #1: authentication and authorization for a third-party AF or an AF deployed within 3GPP systemsp. 8

5.1.1  Introductionp. 8

AF authentication and authorization is subject to whether the AF lies in the 3GPP system or in a third party domain. Existing but different mechanisms are chosen for the two scenarios. In case AF is a third party NF, S-NSSAI is not required at AF to prevent sensitive information leakage.

5.1.2  Solution detailsp. 8

5.1.2.0  Generalp. 8

If an AF is deployed within the 3GPP systems, authentication and authorization is based on the mechanisms defined for SBI, Clause 13 of TS 33.501, where the AF is authenticated by the NRF it registered within the same PLMN. For the Oauth 2.0 based authorization, the NRF takes the role of Authentication Server and the NEF takes the role of Resource Server.
If an AF a third party NF, authentication and authorization is based on the mechanisms defined in Clause 12 of TS 33.501, where mutual authentication is performed between the AF and the NEF. For the Oauth 2.0 based authorization, the NEF takes both roles of Authentication Server and the Resource Server.
In order to avoid sensitive information leakage involving S-NSSAI, S-NSSAI is not sent to or made available to a third party AF. Instead, NEF keeps a mapping between S-NSSAI and ENSI (External Network Slice Information) and ENSI (instead of S-NSSAI) is available at the third party AF. The notification procedure (adapted from the clause 4.15.3.2.10 of TS 23.502) with ENSI is described as below.
Up

5.1.2.1  Number of UEs and PDU Sessions per network slice notification procedurep. 9

Copy of original 3GPP image for 3GPP TS 33.874, Fig. 5.1.2.1-1: Number of UEs and PDU Sessions per network slice notification procedure
Up
Step 0.
Authentication of AF: AF is authenticated by NRF or authenticated by NEF based on description above. A token is generated for AF after authentication. It is noted that the AF token includes claim for the authorized S-NSSAI or ENSI (if AF is a third party NF).
Step 1.
To subscribe or unsubscribe for the number of UEs or the number of PDU Sessions per network slice notification with the NSACF, the AF sends Nnef_EventExposure_Subscribe/Unsubscribe Request (Event ID, Event Filter, Event Reporting information) message to the NEF. The Event ID parameter defines the subscribed event ID, i.e. Number of Registered UEs or Number of Established PDU Sessions. The Event Filter parameter defines the S-NSSAI for which reporting is required. If the AF is a 3GPP NF, The Event Filter parameter is S-NSSAI whereas the Event Filter parameter is ENSI if the AF is a third party NF. The Event Reporting information parameter defines the mode of reporting, i.e. threshold based reporting with included a threshold value or periodic reporting with included periodicity time interval.
Step 2.
The NEF checks whether the AF is authorised for the requested subscription based on the AF token. It needs to check whether the token claims matches the AF's identity and the Event Filter parameter. If authorised, the NEF may query the NRF to find the NSACF responsible for the requested S-NSSAI (NEF needs to map to S-NSSAI based on ENSI for a third party AF). The NEF forwards the request to the NSACF with Nnsacf_SliceEventExposure_Subscribe/Unsubscribe Request (Event ID, Event Filter, Event Reporting information). The Event Filter parameter is the mapped S-NSSAI for the third party AF.
Step 3.
The NSACF confirms with Nnsacf_SliceEventExposure_Subscribe/Usubscribe Response message to the NEF.
Step 4.
The NEF forwards the response from NSACF via the Nnef_EventExposure_Subscribe/Unsibscribe Response message to the AF. The Event Filter parameter is changed to the mapped ENSI for the third party AF.
Step 5.
When the reporting condition for a subscribed event is fulfilled, the NSACF triggers a notification towards the AF.
Step 6.
The NSACF sends the Nnsacf_SliceEvent Exposure_Notify (Event ID, Event Filter, Event Reporting information) message to the NEF. If the subscription is for event based notification (e.g. based on the monitored event reaching a threshold value), the Event Reporting information parameter contains confirmation for the event fulfilment. If the subscription is for periodic notification, the Event Reporting information parameter provides information for the current number of UEs registered with a network slice (e.g. represented in percentage of the maximum number of the UEs registered with the network slice) or information for the current number of PDU Sessions on a network slice (e.g. represented in percentage of the maximum number of the UEs established on the network slice) or both. It is
Step 7.
The NEF forwards the message to the AF in the Nnef_EventExposure_Notify (Event ID, Event Filter, Event Reporting information) message. The Event Filter parameter is changed to the mapped ENSI for the third party AF.
Up

5.1.2.2  Number of UEs and PDU Sessions per network slice status retrieval by AF procedurep. 10

Copy of original 3GPP image for 3GPP TS 33.874, Fig. 5.1.2.2-1: Number of UEs and PDU Sessions per network slice status retrieval by AF procedure
Up
Step 1.
To retrieve information about the number of the UEs registered with a network slice or the number of the PDU Sessions established on a network slice or both, the AF sends Nnef_SliceStatus_Retrieval Request (Event ID, Event Filter) message to the NEF.
The Event ID parameter defines the information to be reported, i.e. the number of registered UEs with a network slice or the number of the PDU sessions with a network slice or both. The Event Filter parameter defines the S-NSSAI for which reporting is required. If the AF is within the 3GPP operator domain, the Event Filter parameter is S-NSSAI whereas the Event Filter parameter is ENSI for the AF outside the 3GPP operator domain.
Step 2.
The NEF checks whether the AF is authorised based on the AF token. It needs to check whether the token claims matches the AF's identity and the Event Filter parameter. If authorised, the NEF may query the NRF to find the NSACF responsible for the requested S-NSSAI. The authorization check by NEF needs to make sure the AF is allowed to access the S-NSSAI.
The NEF shall map to S-NSSAIs from ENSI for the AF outside the 3GPP operator domain. The authorization check by NEF needs to make sure the AF is allowed to access the S-NSSAI.
Step 3.
The NEF forwards the request to the NSACF with Nnsacf_SliceStatus_Retrieval Request (Event ID, Event Filter).
Step 4.
The NSACF returns the Nnsacf_SliceStatus_Retrieval Response (Event ID, Event Filter, Event Reporting information) message to the NEF, as in TS 23.502.
Step 5.
The NEF forwards the message to the AF in the Nnef_SliceStatus_Retrieval Response (Event ID, Event Filter, Event Reporting information) message. The Event Filter parameter is changed to the mapped ENSI for the AF outside the 3GPP operator domain.
Up

5.1.3  Evaluationp. 10

This solution addresses the key issue #3 by optionally storing a mapping between an S-NSSAI and ENSI in NEF. The AF which is outside the 3GPP operator domain is configured with ENSI instead of S-NSSAI to avoid sensitive information leakage.
This solution is in line with the defined procedures for the AF to get access to the network slice quota information.
The NSACF services, i.e. "Nnsacf_SliceEventExposure_Subscribe/Unsubscribe" and "Nnsacf_SliceEventExposure_Notify" are not affected and can be kept as is in TS 23.502.
Optionally, the corresponding NEF services may be updated with the different Event Filter values.
Up

6  Conclusionsp. 11

6.1  Conclusions for KI#1p. 11

For KI#1, it is concluded that no solution is required for the normative text.

6.2  Conclusions for KI#2p. 11

For the EAC issue under KI#2, it is concluded that no solution is required for the normative text. The following NOTE is recommended to be added for the EAC mode in the relevant specifications:

6.3  Conclusions for KI#3p. 11

Authentication and authorization for an AF for network slice quota-usage notification is recommended for normative work based on the solution #1.

$  Change historyp. 12


Up   Top