An unprotected Registration Request using a registered UE's GUTI could
release its existing PDU sessions before authentication.
Defer session release until authentication, Security Mode Control and
the optional EIR check complete. Wait for all release responses before
continuing UDM registration, and prevent stale responses from resuming
a cancelled procedure.
Restore the previous NAS security context on authentication or SMC
failure, and ignore unverified Deregistration Requests during these
procedures.
Add unit and EIR integration regressions for session preservation and
replacement with EIR enabled or disabled and one or two PDU sessions.
Complete the SMF/BSF SBI configuration and make EIR fixtures safe to rerun.
An Attach or Registration Request can arrive on an S1/NG connection
already associated with another subscriber. The request was dispatched
through that association without checking its mobile identity.
The subsequent identity update could relabel the associated UE context
and migrate another subscriber's sessions into it. This either aborted
the MME/AMF when the target already owned sessions or silently assigned
the existing sessions to the wrong subscriber.
Re-resolve the identity before dispatch. If it differs from a registered
context or a context with sessions, release the access connection and
drop the request so the UE can retry on a newly resolved context.
Keep the existing migration behaviour for unfinished procedures without
sessions, and add regression tests for the affected MME and AMF paths.
Issues: #4739
When mme_ue_set_imsi() updates an existing UE IMSI, the previous
code overwrote mme_ue->imsi before removing the old hash entry.
As a result, the old IMSI key could remain in imsi_ue_hash and keep
pointing to the same mme_ue object. After the UE context was removed,
a later lookup by the stale IMSI key could return an invalid context
and trigger a fatal path during re-attach handling.
Remove the old IMSI hash entry before updating mme_ue->imsi, then
register the new IMSI after the update.
Issues: #4357
Limit authentication retries on repeated synchronization failures.
When the UE reports consecutive authentication failures with
"synchronization failure" cause, AMF and MME now track the failure
count per authentication procedure and send AUTHENTICATION REJECT
after two attempts, instead of retrying indefinitely.
The counter is reset on authentication state entry.
This aligns the behavior with 3GPP authentication procedures and
prevents infinite authentication loops caused by persistent
synchronization failures.
Issues: #4238
When the UE sends a Tracking Area Update (TAU) Request with active_flag=0,
the MME previously sent TAU Accept without verifying the EPS Bearer Context
Status (EBCS). This caused stale bearer sessions to remain in the MME even
if the UE had already released them.
According to 3GPP TS 24.301 §5.5.3.2, the MME should release any bearer
not reported in the UE’s EBCS when active_flag=0. This patch introduces
mme_send_delete_session_or_tau_accept(), which compares the UE’s EBCS bitmask
with the MME session list and deletes any missing default bearer session
before sending TAU Accept.
If no mismatch is found, TAU Accept is sent immediately. The Delete Session
response triggers TAU Accept when deletions are required. This ensures that
the TAU Accept message reflects the UE’s current bearer context accurately.
Also includes:
- Added OGS_GTP_DELETE_SEND_TAU_ACCEPT handling in mme-s11-handler.c
- Simplified EBCS structure (uint16_t value) for bitmask comparison
- Updated TAU-related tests with realistic EBI bitmasks (0x20, 0x60)
This change aligns TAU handling with 3GPP 24.301 and prevents bearer
mismatch issues between UE and EPC during TAU.
If the UE continuously attempts to Attach while changing PDN Type,
it will cause the wrong IP to be assigned.
(e.g PDU-Type : IPv4v6 -> IPv4 -> IPv4v6)
This is because we use two variables at the same time,
one to read and store the Static IP from the Subscriber DB and
one to store the IP assigned from SMF, called session->paa.
When the UE attaches with PDN-Type set to IPv4v6,
MME saves the allocated IP in session->paa.
However, MME thinks it has been assigned a static IP based on the information
in session->paa, so changing the PDN-Type may result in the wrong IP
being assigned.
To solve this problem, I separated the variable(session->paa) that stores
the allocated IP received from SMF and the variable(session->ue_ip) that stores
the Static IP read from the Subscriber DB.
Therefore, the information read from the Subscriber DB
(session->session_type and session->ue_ip) should not be modified.
In InitialUEMessage, send a NAS message with a message type
other than Registration Request, Deregistration Request, or Service Request,
the following messages from UE will not be accepted.
We found this issue in not only the initial state but multiple states.
We believe if an attacker has the ability to inject a NAS message to the core,
it can perform a DoS attack on the victim UE.
So, I've fixed that The MME/AMF deletes MME_UE_S1AP_ID/AMF_UE_NGAP_ID,
and will not accept any following messages from the UE.
The AMF will crash on the following locations when it receives a sequence
of NAS messages from a UE.
- ogs_nas_encrypt: Assertion `pkbuf->len' failed. (../lib/nas/common/security.c:86)
- gmm_state_authentication: Assertion `r != OGS_ERROR' failed. (../src/amf/gmm-sm.c:1561)
Besides the crashes found above, an incorrect protocol transition
is identified in Open5GS. Without any Registration/Attach Request message,
when the Identity Response message sent, the Core Network responds
with an Authentication Request message. According to the standard,
only the Registration/Attach Request message can start a state transition
from the 5GMM/EMM-DEREGISTERED state to the 5GMM/EMM-COMMON-PROCEDURE-INITIATED.
So I've modified the relevant code to address these issues.
First of all, it crashes when creating a Dedicated Bearer
on the default Session that is created for the first time.
This behavior should be possible, so the related ASSERT is removed.
Next, the InitialContextRequest is modified
during the Attach Request to include the first Bearer.
Finally, there was an issue where trying to create a Dedicated Bearer
with SGsAP enabled resulted in an InitialContextSetupRequest message
with a PTI of zero. This is because MME initializes the PTI to 0
upon receiving the Create Bearer Request while processing SGsAP.
All of these issues has been fixed.
Assume the UE has Attached, the session has been created,
and is in the IDLE state with the UEContextRelease process.
This could result in the following call flow.
1. TAU request without Integrity Protected
2. Authentication request/response
3. Security-mode command/complete
MME can be performed simultaneously by the HSS(S6A) and UE(S1AP).
Update-Location-Request
Service request
Service reject
Delete Session Request
Delete Session Response
Update-Location-Answer
UEContextReleaseCommand for Service reject
TAU reject
UEContextReleaseCommand for TAU reject
UEContextReleaseComplete
UEContextReleaseComplete
MME crashes when UE sends a service request(S1AP) during ULR/ULA(S6A) with HSS,
which has been fixed.
Problems with Purge-UE-Request/Answer can occur in the following situations
1. Attach Request
2. Authentication request
3. Authentication reject
4. UEContextReleaseCommand
5. UEContextReleaseComplete
6. Purge-UE-Request
7. Attach Request
8. Purge-UE-Answer
9. (UE Context Remove)
To resolve this issue, we have changed to delete the UE-Context
via mme_ue_remove() immediately upon receiving UEContextReleaseComplete()
without calling mme_s6a_send_pur().
* [AMF/MME] UEContextReleaseCommand in Integrity (#2786)
Modified not to send UEContextReleaseCommand in Integrity Unprotected
NAS message such like Registration or Service request.
* [AMF/MME] UEContextReleaseCommand after Interity Protected (#2786)
Modified not to send UEContextReleaseCommand in Integrity Unprotected
NAS message such like Registration or Service request.
o Generate the private key as below.
$ openssl genpkey -algorithm X25519 -out /etc/open5gs/hnet/curve25519-1.key
$ openssl ecparam -name prime256v1 -genkey -conv_form compressed -out /etc/open5gs/hnet/secp256r1-2.key
o The private and public keys can be viewed with the command.
The public key is used when creating the SIM.
$ openssl pkey -in /etc/open5gs/hnet/curve25519-1.key -text
$ openssl ec -in /etc/open5gs/hnet/secp256r1-2.key -conv_form compressed -text
In ausf/udm.yaml
hnet:
o Home network public key identifier(PKI) value : 1
Protection scheme identifier : ECIES scheme profile A
- id: 1
scheme: 1
key: /etc/open5gs/hnet/curve25519-1.key
o Home network public key identifier(PKI) value : 2
Protection scheme identifier : ECIES scheme profile B
- id: 2
scheme: 2
key: /etc/open5gs/hnet/secp256r1-2.key
o Home network public key identifier(PKI) value : 3
Protection scheme identifier : ECIES scheme profile A
- id: 3
scheme: 1
key: /etc/open5gs/hnet/curve25519-1.key
o Home network public key identifier(PKI) value : 4
Protection scheme identifier : ECIES scheme profile B
- id: 4
scheme: 2
key: /etc/open5gs/hnet/secp256r1-2.key
Related to #1779
When a UE that requests slices tries to connect and there are no slices configured, the reject message is:
5GMM cause = 0x7 (5GS Services not allowed)
however it should be:
5GMM cause = 0x3e (No network slices available)
All 5GMM cause value in reject message is reviewed in this commit
In the past only GTPv2C was supported, and had the "gtp" generic prefix.
Later on, GTPv1C support was added, and "gtp1" prefix was used.
Let's move GTPv2C specific bits to have "gtp2" prefix too, and leave
"gtp" prefix for generic stuff among different GTP versions.
The AMF shall assign a new 5G-GUTI for a particular UE:
a) during a successful initial registration procedure;
b) during a successful registration procedure
for mobility registration update; and
c) after a successful service request procedure invoked as a response
to a paging request from the network and before the release
of the N1 NAS signalling connection as specified in subclause 5.4.4.1.
The AMF should assign a new 5G-GUTI for a particular UE
during a successful registration procedure
for periodic registration update. The AMF may assign a new 5G-GUTI
at any time for a particular UE by performing
the generic UE configuration update procedure.
If both Delete-Session-Request/Response and
UEContextReleaseCommand/UEContextReleaseComplete are failed at the same time,
UE cannot attach to the EPC infinitely.
So, I've add the protection code
if timer expires when MME does not receive Delete-Session-Response.
So far, no operation was performed when Error Indication was received
from eNodeB. For that reason, I solved #568 issues by controlling
the MME to prevent this from happening.
Now, when GTP-U Error Indication is received, MME and SGW are implemented
to do what they have to do. I hope that the network can be restored
by responding appropriately even if Error Indication occurs.
