4 UPF-specific security requirements and related test cases
33.5133GPP5G Security Assurance Specification (SCAS)Release 17TSUser Plane Function (UPF)
4.1 Introduction
The present document describes the following security requirements and the related test cases for UPF:
– Security functional requirements and the related test cases (clause 4.2),
– Adaptations of hardening requirements and the related test cases (clause 4.3), and
– Adaptations of basic vulnerability testing requirements and the related test cases (clause 4.4).
The above categories are aligned with those specified in TS 33.117 [3]. The text on pre-requisites for testing in clause 4.1.2 of TS 33.117 [3] applies also to the present document.
4.2 UPF-specific security functional requirements and related test cases
4.2.1 Introduction
The security functional requirements and the related test cases specific for UPF are described in the clause.
4.2.2 Security functional requirements on the UPF deriving from 3GPP specifications and related test cases
4.2.2.0 General
The general approach in TS 33.117 [3] clause 4.2.2.1 and all the requirements and test cases in TS 33.117 [3] clause 4.2.2.2 related to SBA/SBI aspect apply to the UPF network product class.
4.2.2.1 Confidentiality protection of user data transported over N3 interface.
Requirement Name: Confidentiality protection of user data transported over N3 interface.
Requirement Reference: TS 33.501 [2], Clause 9.3
Requirement Description: "The transported user data between gNB and UPF shall be confidentiality protected." As specified in TS 33.501 [2], clause 9.3.
Threat Reference: TR 33.926 [7], Clause L.2.2, "No protection or weak protection for user plane data ".
TEST CASE:
Test Name: TC_UP_DATA_CONF_UPF
Purpose:
Verify that the transported user data between gNB and UPF are confidentiality protected over N3 interface.
Procedure and execution steps:
Pre-Condition:
– UPF network product is connected in simulated/real network environment.
– The tunnel mode IPsec ESP and IKE certificate authentication is implemented.
– Tester shall have knowledge of the security parameters of tunnel for decrypting the ESP packets.
– Tester shall have access to the N3 interface between gNB and UPF.
– Tester shall have knowledge of the confidentiality algorithm and confidentiality protection keys used for encrypting the encapsulated payload.
Execution Steps:
The requirement mentioned in this clause is tested in accordance with the procedure mentioned in clause 4.2.3.2.4 of TS 33.117 [3].
Expected Results:
The user data transported between gNB and UPF is confidentiality protected.
Expected format of evidence:
Evidence suitable for the interface, e.g., evidence can be presented in the form of screenshot/screen-capture.
4.2.2.2 Integrity protection of user data transported over N3 interface
Requirement Name: Integrity protection of user data transported over N3 interface.
Requirement Reference: TS 33.501 [2], Clause 9.3
Requirement Description: "The transported user data between gNB and UPF shall be integrity protected" as specified in TS 33.501 [2], clause 9.3.
Threat Reference: TR 33.926 [7], Clause L.2.2, "No protection or weak protection for user plane data"
TEST CASE:
Test Name: TC_UP_DATA_INT_UPF
Purpose:
Verify that the transported user data between gNB and UPF are integrity protected over N3 interface.
Procedure and execution steps:
Pre-Condition:
– UPF network product is connected in simulated/real network environment.
– The tunnel mode IPsec ESP and IKE certificate authentication is implemented.
– Tester shall have knowledge of the security parameters of tunnel for decrypting the Encapsulated Security Payload (ESP) packets.
– Tester shall have knowledge of the authentication algorithm (Hash Message Authentication Code) and the protection keys.
Execution Steps:
The requirement mentioned in this clause is tested in accordance to the procedure mentioned in clause 4.2.3.2.4 of TS 33.117 [3].
Expected Results:
The user data transported between gNB and UPF is integrity protected.
Expected format of evidence:
Evidence suitable for the interface, e.g., evidence can be presented in the form of screenshot/screen-capture.
4.2.2.3 Replay protection of user data transported over N3 interface
Requirement Name: Replay protection of user data transported over N3 interface
Requirement Reference: TS 33.501 [2], Clause 9.3
Requirement Description: "The transported user data between gNB and UPF shall be replay protected." As specified in TS 33.501, clause 9.3.
Threat Reference: TR 33.926 [7], Clause L.2.2, "No protection or weak protection for user plane data"
TEST CASE:
Test Name: TC_UP_DATA_REPLAY_UPF
Purpose:
Verify that the transported user data between gNB and UPF are replay protected.
Procedure and execution steps:
The following procedure is executed if UPF supports IPsec.
Pre-Condition:
– UPF network product is connected in simulated/real network environment.
– The tunnel mode IPsec ESP and IKE certificate authentication is implemented.
– Tester shall have knowledge of the security parameters of tunnel for decrypting the ESP packets.
– Tester shall have access to the original user data transported via N3 reference point between gNB and UPF.
Execution Steps:
The requirement mentioned in this clause is tested in accordance with the procedure mentioned in clause 4.2.3.2.4 of TS 33.117 [3].
Expected Results:
The user data transported between UE and UPF is replay protected.
Expected format of evidence:
Evidence suitable for the interface, e.g., evidence can be presented in the form of screenshot/screen-capture.
4.2.2.4 Protection of user data transported over N9 interface Within a PLMN
Requirement Name: Protection of user data transported over N9 within a PLMN.
Requirement Reference: TS 33.501 [2], Clause 9.9
Requirement Description: As specified in clause 9.9 in TS 33.501 [2], "Interfaces internal to the 5G Core can be used to transport signalling data as well as privacy sensitive material, such as user and subscription data, or other parameters, such as security keys. Therefore, confidentiality and integrity protection is required.
For the protection of the non-SBA internal interfaces, such as N4 and N9, NDS/IP shall be used as specified in [3]."
Threat Reference: TR 33.926 [7], Clause L.2.2, "No protection or weak protection for user plane data "
TEST CASE:
Test Name: TC_UP_DATA_CONF_UPF_N9
Purpose:
Verify that the protection mechanism implemented for user data transport over N9 interface in a PLMN conforms to the selected security profile.
Procedure and execution steps:
Pre-Condition:
– UPF network products are connected in simulated/real network environment.
– The tunnel mode IPsec ESP and IKE certificate authentication is implemented.
– Tester shall have knowledge of the security parameters of tunnel for decrypting the ESP packets.
– Tester shall have access to the N9 interface between two UPFs within a PLMN.
– Tester shall have knowledge of the confidentiality algorithm and confidentiality protection keys used for encrypting the encapsulated payload.
Execution Steps:
The requirement mentioned in this clause is tested in accordance with the procedure mentioned in clause 4.2.3.2.4 of TS 33.117 [3].
Expected Results:
The user data transported on N9 within a PLMN is protected.
Expected format of evidence:
Evidence suitable for the interface, e.g., evidence can be presented in the form of screenshot/screen-capture.
4.2.2.5 Signalling Data Protection
Requirement Name: Protection of signalling data transported over N4 interface.
Requirement Reference: TS 33.501 [2], Clause 9.9
Requirement Description: As specified in clause 9.9 in TS 33.501 [2], "Interfaces internal to the 5G Core can be used to transport signalling data as well as privacy sensitive material, such as user and subscription data, or other parameters, such as security keys. Therefore, confidentiality and integrity protection is required.
For the protection of the non-SBA internal interfaces, such as N4 and N9, NDS/IP shall be used as specified in [3]."
Threat Reference: TR 33.926 [7], Clause L.2.3, "No protection or weak protection for signalling data over N4 interface"
TEST CASE:
Test Name: TC_CP_DATA_CONF _UPF_N4
Purpose:
Verify that the protection mechanism implemented for signalling data transmitted over N4 conforms to selected security profile.
Procedure and execution steps:
Pre-Condition:
– UPF and SMF network products are connected in simulated/real network environment.
– The tunnel mode IPsec ESP and IKE certificate authentication is implemented.
– Tester shall have knowledge of the security parameters of tunnel for decrypting the ESP packets.
– Tester shall have access to the N4 interface between SMF and UPF.
– Tester shall have knowledge of the confidentiality algorithm and confidentiality protection keys used for encrypting the encapsulated payload.
Execution Steps:
The requirement mentioned in this clause is tested in accordance with the procedure mentioned in clause 4.2.3.2.4 of TS 33.117 [3].
Expected Results:
The signalling data transported over N4 interface is protected.
Expected format of evidence:
Evidence suitable for the interface, e.g., evidence can be presented in the form of screenshot/screen-capture.
4.2.2.6 TEID uniqueness
Requirement Name: TEID uniqueness.
Requirement Reference:
TS 23.501 [4], Clause 5.8.2.3.1; TS 29.281 [5], Clause 5.1; TS 23.060 [6], Clause 14.6
Requirement Description:
"Allocation and release of CN Tunnel Info is performed when a new PDU Session is established or released. This functionality is supported either by SMF or UPF, based on operator’s configuration on the SMF" as specified in TS 23.501[4], clause 5.8.2.3.1.
"Tunnel Endpoint Identifier (TEID): This field unambiguously identifies a tunnel endpoint in the receiving GTP U protocol entity. The receiving end side of a GTP tunnel locally assigns the TEID value the transmitting side has to use" as specified in TS 29.281[5], clause 5.1.
"The TEID is a unique identifier within one IP address of a logical node." As specified in TS 23.060 [6], clause 14.6.
Threat Reference: TR 33.926 [7], Clause L.2.4, "Failure to assign unique TEID for a session"
TEST CASE:
Test Name: TC_TEID_ID_UNIQUENESS_UPF
Purpose:
Verify that the TEID generated by UPF under test for each new GTP tunnel is unique.
Pre-Conditions:
Test environment is set up with SMF, which may be real or simulated, and UPF under test. The tester is able to trace traffic between the UPF under test and the SMF (real or simulated). SMF configures UPF under test to generate the TEIDs.
Execution Steps:
1) The tester intercepts the traffic between the UPF under test and the SMF.
2) The tester triggers the maximum number of concurrent N4 session establishment requests.
3) The tester captures the N4 session establishment responses sent from UPF to SMF and verifies that the F-TEID created for each generated response is unique.
Expected Results:
The F-TEID set in each different N4 session establishment response is unique.
Expected format of evidence:
Files containing the triggered GTP messages (e.g. pcap trace).
4.2.2.7 IPUPS
Requirement Name: IPUPS packeting handling
Requirement Reference: TS 33.501[8], clause 5.9.3.4
Requirement Description:
"The IPUPS shall only forward GTP-U packets that contain an F-TEID that belongs to an active PDU session and discard all others." as specified in TS 33.501[5], clause 5.9.3.4.
Threat Reference: TR 33.926 [7], Clause L.2.5, "invalid user plane data forwarding"
TEST CASE:
NOTE 1: This test case is only applicable to UPF supporting IPUPS.
Test Name: TC_IPUPS_PACKET_HANDLING
Purpose:
Verify that the packets not belonging to an active PDU session is discarded.
Pre-Conditions:
Test environment is set up with a V-SMF, an H-SMF, an H-UPF and a gNB which may be simulated.
Execution Steps:
1) The V-SMF requests the UPF with IPUPS functionality under test to establish an N4 session for a PDU session in home-routing roaming. The UPF with IPUPS functionality under test responds to the SMF with the F-TEID for the N9 tunnel towards the H-UPF, and the F-TEID for the N3 tunnel towards the gNB.
2) The V-SMF requests the H-SMF to establish a PDU session providing the received F-TEID for the N9 tunnel.
3) The H-SMF requests the H-UPF to establish an N4 session providing the received F-TEID for the N9 tunnel. H-UPF in the response provides its F-TEID for the N9 tunnel. The H-SMF provides the received F-TEID from the H-UPF to the V-SMF.
4) The V-SMF requests the gNB to allocate resource for the PDU session providing the F-TEID for the N3 tunnel received at step 1. The gNB replies with its F-TEID for the N3 tunnel to the V-SMF.
5) The V-SMF provides the UPF with IPUPS functionality under test with the received F-TEID assigned by the gNB for the N3 tunnel and the received F-TEID assigned by the H-UPF for the N9 tunnel.
6) The H-UPF is triggered to send GTP-U packets using the F-TEID assigned by the V-UPF for the N9 tunnel.
7) The H-UPF is triggered to send GTP-U packets using an F-TEID different than the one assigned by V-UPF for N9 tunnel.
Expected Results:
When the H-UPF is triggered to send GTP-U packets using the F-TEID assigned by the V-UPF for the N9 tunnel (step 6 in the execution steps), GTP-U packets are witnessed over the N3 tunnel.
When the H-UPF is triggered to send GTP-U packets using an F-TEID different than the one assigned by the V-UPF (step 7 in the execution steps), no GTP-U packets are witnessed over the N3 tunnel.
Expected format of evidence:
Files recording the GTP packets captured (e.g. pcap trace).
4.2.2.8 Protection against malformed GTP-U messages
Requirement Name: Protection against malformed GTP-U messages
Requirement Reference: TS 33.501[8], clause 5.9.3.4
Requirement Description:
"The IPUPS shall discard malformed GTP-U messages." as specified in TS 33.501[8], clause 5.9.3.4.
Threat Reference: TR 33.926 [7], Clause L.2.6, "Threats of malformed GTP-U messages"
TEST CASE:
NOTE 1: This test case is only applicable to UPF supporting IPUPS.
Test Name: TC_IPUPS_MALFORED_MESSAGES
Purpose:
Verify that malformed messages are discarded by UPF.
Pre-Conditions:
The pre-conditions in clause 4.4.4 of TS 33.117 [3] apply, except that fuzzing tools supporting GTP-U protocol is available.
Execution Steps:
The execution steps follow those in clause 4.4.4 of TS 33.117 [3], except that the protocol the fuzzing tool is executed against is GTP-U and the interface is N9.
Expected Results:
The expected results in clause 4.4.4 of TS 33.117 [3] apply except that the protocol and the interface contained in the testing documentation are GTP-U and N9 respectively.
Expected format of evidence:
The expected format of evidence in clause 4.4.4 of TS 33.117 [3] apply.
4.2.3 Technical baseline
4.2.3.1 Introduction
The present clause provides baseline technical requirements.
4.2.3.2 Protecting data and information
4.2.3.2.1 Protecting data and information – general
There are no UPF-specific additions to clause 4.2.3.2.1 of TS 33.117 [3].
4.2.3.2.2 Protecting data and information – unauthorized viewing
There are no UPF-specific additions to clause 4.2.3.2.2 of TS 33.117 [3].
4.2.3.2.3 Protecting data and information in storage
There are no UPF-specific additions to clause 4.2.3.2.3 of TS 33.117 [3].
4.2.3.2.4 Protecting data and information in transfer
There are no UPF-specific additions to clause 4.2.3.2.4 of TS 33.117 [3].
4.2.3.2.5 Logging access to personal data
There are no UPF-specific additions to clause 4.2.3.2.5 of TS 33.117 [3].
4.2.3.3 Protecting availability and integrity
There are no UPF-specific additions to clause 4.2.3.3 of TS 33.117 [3].
4.2.3.4 Authentication and authorization
There are no UPF-specific additions to clause 4.2.3.4 of TS 33.117 [3].
4.2.3.5 Protecting sessions
There are no UPF-specific additions to clause 4.2.3.5 of TS 33.117 [3].
4.2.3.6 Logging
There are no UPF-specific additions to clause 4.2.3.6 of TS 33.117 [3].
4.2.4 Operating systems
There are no UPF-specific additions to clause 4.2.4 of TS 33.117 [3].
4.2.5 Web Servers
There are no UPF-specific additions to clause 4.2.5 of TS 33.117 [3].
4.2.6 Network Devices
There are no UPF-specific additions to clause 4.2.6 in TS 33.117 [3].
4.3 UPF-specific adaptations of hardening requirements and related test cases
4.3.1 Introduction
This clause specifies the UPF-specific adaptations of hardening requirements and related test cases.
4.3.2 Technical baseline
There are no UPF-specific additions to clause 4.3.2 in TS 33.117 [3].
4.3.3 Operating systems
There are no UPF-specific additions to clause 4.3.3 in TS 33.117 [3].
4.3.4 Web servers
There are no UPF-specific additions to clause 4.3.4 in TS 33.117 [3].
4.3.5 Network devices
There are no UPF-specific additions to clause 4.3.5 in TS 33.117 [3].
4.3.6 Network functions in service-based architecture
There are no UPF-specific additions to clause 4.3.6 in TS 33.117 [3].
4.4 UPF-specific adaptations of basic vulnerability testing requirements and related test cases
There are no UPF-specific additions to clause 4.4 in TS 33.117 [3].
Annex A (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
Tdoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2019-10 |
EditHelp review, editorial changes |
16.0.1 |
|||||
|
2019-12 |
SA#86 |
SP-191138 |
0002 |
1 |
F |
Corrections for clean-up and alignment |
16.1.0 |
|
2020-12 |
SA#90e |
SP-201004 |
0003 |
– |
F |
Reference of general SBA/SBI aspect in 33.513 |
16.2.0 |
|
2021-09 |
SA#93e |
SP-210848 |
0005 |
– |
B |
New test cases of IPUPS to TS 33.513 |
17.0.0 |
|
2022-12 |
SA#98e |
SP-221157 |
0009 |
– |
F |
Correction of requirement references in UPF test case |
17.1.0 |