N32-f SEPP Identity Cross-Validation Against Inter-PLMN Spoofing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing 5G network architecture lacks validation of SEPP identity and PLMN identity on the inter-PLMN forwarding interface, making it vulnerable to spoofing attacks, particularly on the N32-f interface, which can lead to unauthorized service communications and denial of service attacks.
Innovation Solution
Implementing cross-validation of SEPP and PLMN identities by extracting identifiers from X.509 certificates during TLS handshakes on both the N32-c and N32-f interfaces, and storing these in a database for comparison to ensure authenticity.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If TLS certificate validation is performed only on the N32-f interface, then basic encryption is provided, but spoofing attacks remain possible because SEPP identity cannot be verified
Solution Approach 1:
The patent extracts and stores SEPP identifiers from TLS certificates during the N32-c interface handshake before the N32-f interface communication begins. This preliminary extraction and storage of identifiers allows for subsequent verification without adding complex real-time validation logic during the actual service communication on N32-f
Solution Approach 2:
The patent introduces an identifier verification mechanism that acts as an intermediary between the TLS certificate validation and the service communication. By extracting identifiers from certificates and verifying them against stored values, it creates a intermediate validation layer that prevents spoofing without requiring complete redesign of the TLS protocol
2Reliability
If cross-validation of SEPP identifiers is implemented on both N32-c and N32-f interfaces, then spoofing attacks are mitigated, but processing overhead increases
Solution Approach 1:
The patent extracts only the essential SEPP identifier from the TLS certificate during handshake, rather than validating the entire certificate chain or performing complex cryptographic operations. This extraction of minimal necessary information reduces processing overhead while maintaining security
Solution Approach 2:
The patent creates a simplified copy of the SEPP identifier from the TLS certificate and stores it for later verification. Instead of repeatedly processing complex certificate data, it works with these extracted identifier copies, significantly reducing computational overhead during actual service communication
3Reliability
If PLMN identity validation is added to the N32-f interface, then unauthorized service communications are prevented, but message processing time increases
Solution Approach 1:
The patent extracts and stores PLMN identifiers from messages on the N32-c interface before service communication begins. This preliminary extraction allows for rapid verification on the N32-f interface without requiring time-consuming real-time queries or complex validation procedures
Solution Approach 2:
The patent uses simple identifier strings extracted from messages as disposable validation tokens. Rather than implementing complex, time-consuming authorization protocols, it uses these lightweight identifier comparisons that can be performed rapidly with minimal processing time
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A method for mitigating spoofing attacks on an SERF inter-PLMN forwarding interface includes obtaining, by a responding SERF, a first SEPP identifier and/or a first PLMN identifier from at least one message received over an inter-PLMN control interface. The method further includes storing the first SEPP identifier and/or the first PLMN identifier in an identity cross-validation database. The method further includes obtaining, from at least one message received over an inter-PLMN forwarding interface a second SEPP identifier and/or a second PLMN identifier and performing a lookup in the identity cross-validation database using a lookup key comprising at least one of the second SEPP identifier and the second PLMN identifier, determining that a record corresponding to the lookup key is not present in the identity cross-validation database, and, in response, preventing the at least one message received over the inter-PLMN forwarding interface from entering a PLMN protected by the responding SEPP.