TS 33.513
5G Security Assurance Specification (SCAS) –
User Plane Function (UPF)
V17.1.0 (PDF)
2022/12 18 p.
V16.2.0
2020/12 16 p.
- Rapporteur:
- Mr. Rajadurai, Rajavelsamy
Samsung R&D Institute UK
Content for TS 33.513 Word version: 17.1.0
1 Scope
2 References
3 Definitions of terms, symbols and abbreviations
4 UPF-specific security requirements and related test cases
4.1 Introduction
4.2 UPF-specific security functional requirements and related test cases
4.3 UPF-specific adaptations of hardening requirements and related test cases
4.4 UPF-specific adaptations of basic vulnerability testing requirements and related test cases
$ Change history
1 Scope p. 6
The present document contains requirements and test cases that are specific to the UPF network product class. It refers to the Catalogue of General Security Assurance Requirements and formulates specific adaptions of the requirements and test cases. It also specifies the requirements and test cases unique to the UPF network product class.
2 References p. 6
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 33.501: (Release 15) "Security architecture and procedures for 5G system".
[3]
TS 33.117: "Catalogue of general security assurance requirements".
[4]
TS 23.501: "System Architecture for 5G system".
[5]
TS 29.281: "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U) ".
[6]
TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2".
[7]
TR 33.926: "Security Assurance Specification (SCAS) threats and critical assets in 3GPP network product classes".
[8]
TS 33.501: (Release 16) "Security architecture and procedures for 5G system".
3 Definitions of terms, symbols and abbreviations p. 6
3.1 Terms p. 6
For the purposes of the present document, the terms and definitions 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 Symbols p. 6
Void.
3.3 Abbreviations p. 7
4 UPF-specific security requirements and related test cases p. 7
4.1 Introduction p. 7
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).
4.2 UPF-specific security functional requirements and related test cases p. 7
4.2.1 Introduction p. 7
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 p. 7
4.2.2.0 General p. 7
The general approach in TS 33.117, clause 4.2.2.1 related to SBA/SBI aspect apply to the UPF network product class.TS 33.117, 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. p. 7
Requirement Name:
Confidentiality protection of user data transported over N3 interface.
Requirement Reference:
Requirement Description:
"The transported user data between gNB and UPF shall be confidentiality protected." As specified in TS 33.501, clause 9.3.
Threat Reference:
TR 33.926, 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.
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.
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 p. 8
Requirement Name:
Integrity protection of user data transported over N3 interface.
Requirement Reference:
Requirement Description:
"The transported user data between gNB and UPF shall be integrity protected" as specified in TS 33.501, clause 9.3.
Threat Reference:
TR 33.926, 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.
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.
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 p. 9
Requirement Name:
Replay protection of user data transported over N3 interface
Requirement Reference:
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, 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:
Execution Steps:
- 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.
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.
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 p. 9
Requirement Name:
Protection of user data transported over N9 within a PLMN.
Requirement Reference:
Requirement Description:
As specified in clause 9.9 in TS 33.501, "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, 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.
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.
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 p. 10
Requirement Name:
Protection of signalling data transported over N4 interface.
Requirement Reference:
Requirement Description:
As specified in clause 9.9 in TS 33.501, "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, 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.
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.
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 p. 11
Requirement Name:
TEID uniqueness.
Requirement Reference:
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, 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, clause 5.1.
"The TEID is a unique identifier within one IP address of a logical node." As specified in TS 23.060, clause 14.6.
Threat Reference:
TR 33.926, 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:
- The tester intercepts the traffic between the UPF under test and the SMF.
- The tester triggers the maximum number of concurrent N4 session establishment requests.
- 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.
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 p. 12
Requirement Name:
IPUPS packeting handling
Requirement Reference:
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, clause 5.9.3.4.
Threat Reference:
TR 33.926, Clause L.2.5, "invalid user plane data forwarding"
TEST CASE:
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:
- 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.
- The V-SMF requests the H-SMF to establish a PDU session providing the received F-TEID for the N9 tunnel.
- 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.
- 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.
- 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.
- The H-UPF is triggered to send GTP-U packets using the F-TEID assigned by the V-UPF for the N9 tunnel.
- 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.
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 p. 13
Requirement Name:
Protection against malformed GTP-U messages
Requirement Reference:
Requirement Description:
"The IPUPS shall discard malformed GTP-U messages." as specified in TS 33.501, clause 5.9.3.4.
Threat Reference:
TR 33.926, Clause L.2.6, "Threats of malformed GTP-U messages"
TEST CASE:
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 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, 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 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 apply.
4.2.3 Technical baseline p. 13
4.2.3.1 Introduction p. 13
The present clause provides baseline technical requirements.
4.2.3.2 Protecting data and information p. 13
4.2.3.2.1 Protecting data and information - general p. 13
There are no UPF-specific additions to clause 4.2.3.2.1 of TS 33.117.
4.2.3.2.2 Protecting data and information - unauthorized viewing p. 14
There are no UPF-specific additions to clause 4.2.3.2.2 of TS 33.117.
4.2.3.2.3 Protecting data and information in storage p. 14
There are no UPF-specific additions to clause 4.2.3.2.3 of TS 33.117.
4.2.3.2.4 Protecting data and information in transfer p. 14
There are no UPF-specific additions to clause 4.2.3.2.4 of TS 33.117.
4.2.3.2.5 Logging access to personal data p. 14
There are no UPF-specific additions to clause 4.2.3.2.5 of TS 33.117.
4.2.3.3 Protecting availability and integrity p. 14
There are no UPF-specific additions to clause 4.2.3.3 of TS 33.117.
4.2.3.4 Authentication and authorization p. 14
There are no UPF-specific additions to clause 4.2.3.4 of TS 33.117.
4.2.3.5 Protecting sessions p. 14
There are no UPF-specific additions to clause 4.2.3.5 of TS 33.117.
4.2.3.6 Logging p. 14
There are no UPF-specific additions to clause 4.2.3.6 of TS 33.117.
4.2.4 Operating systems p. 14
There are no UPF-specific additions to clause 4.2.4 of TS 33.117.
4.2.5 Web Servers p. 14
There are no UPF-specific additions to clause 4.2.5 of TS 33.117.
4.2.6 Network Devices p. 14
There are no UPF-specific additions to clause 4.2.6 in TS 33.117.
4.3 UPF-specific adaptations of hardening requirements and related test cases p. 14
4.3.1 Introduction p. 14
This clause specifies the UPF-specific adaptations of hardening requirements and related test cases.
4.3.2 Technical baseline p. 14
There are no UPF-specific additions to clause 4.3.2 in TS 33.117.
4.3.3 Operating systems p. 15
There are no UPF-specific additions to clause 4.3.3 in TS 33.117.
4.3.4 Web servers p. 15
There are no UPF-specific additions to clause 4.3.4 in TS 33.117.
4.3.5 Network devices p. 15
There are no UPF-specific additions to clause 4.3.5 in TS 33.117.
4.3.6 Network functions in service-based architecture p. 15
There are no UPF-specific additions to clause 4.3.6 in TS 33.117.
4.4 UPF-specific adaptations of basic vulnerability testing requirements and related test cases p. 15
There are no UPF-specific additions to clause 4.4 in TS 33.117.
$ Change history p. 16
