Project

General

Profile

Actions

Bug #3164

open

invalid LAI in level 3 complete: unify BSSMAP and RANAP verification

Added by neels almost 6 years ago. Updated over 4 years ago.

Status:
Feedback
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
04/12/2018
Due date:
% Done:

0%

Resolution:
Spec Reference:

Description

So far we determine validity of the PLMN (compared against the global MNC's config) in bssmap_rx_l3_compl() for the A-interface.
<insert status quo of the Iu interface here, see #3163>

However, in the VLR, we have code stubs to accept or deny a given LAI, which always returns acceptance at the moment: lai_in_this_vlr() in vlr_lu_fsm.c.

  • Move the PLMN (LAI) check into the VLR, to serve both A and Iu interface L3 Complete requests.
    So, instead of verifying in BSSMAP and RANAP rx functions separately, just pass the received LAI onto vlr_lu_fsm.c and compare it centrally there.

As a future perspective, policy on which LAIs are permitted can then be added in the VLR for both these RAN types.

(This issue is created as a split of #2980, to clarify the confusion we created there.)


Related issues

Related to OsmoMSC - Bug #3162: BSSMAP: reject Level 3 Complete from cells with invalid LAIResolvedstsp04/12/2018

Actions
Related to OsmoMSC - Bug #3163: RANAP: reject Level 3 Complete from cells with invalid LAINewosmith04/12/2018

Actions
Related to OsmoMSC - Feature #3165: Verify LU Request's LAINewosmith04/12/2018

Actions
Actions #1

Updated by neels almost 6 years ago

  • Related to Bug #3162: BSSMAP: reject Level 3 Complete from cells with invalid LAI added
Actions #2

Updated by neels almost 6 years ago

  • Related to Bug #3163: RANAP: reject Level 3 Complete from cells with invalid LAI added
Actions #3

Updated by neels almost 6 years ago

Actions #4

Updated by neels almost 6 years ago

Wait, I might be confusing things here, again. vlr_lu_fsm.c is of course only concerned with Location Updating, not the other Level 3 Complete (Paging Response and CM Service Request).
We also have the vlr_access_req_fsm.c, concerned with the non-LU L3 Complete, which also contains a LAI, which should also be validated.
I guess part of this task is to clarify which PLMN means what exactly and should be handled where.

Actions #5

Updated by laforge over 4 years ago

  • Status changed from New to Feedback
  • Assignee changed from stsp to neels

still valid?

Actions #6

Updated by neels over 4 years ago

The most central place where all L3 Complete pass through would now be in msc_a_up_l3() in msc_a.c.
However, that function is not the right place to decode LAI from the various L3-Complete messages.
gsm0408_rcv_mm() is still responsible for LU and CM Service Requests, while gsm0408_rcv_rr() is still responsible for Paging Response.

In other words, this issue has not been affected by the refactoring and should still be open.
Probably best to first put up tests to probe the current behavior,
and then add one central function in the VLR that both the vlr_lu_fsm and vlr_access_req_fsm use to validate the received LAI.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)