Project

General

Profile

Feature #4476

OsmoHLR: support IMSI pseudo in location update

Added by osmith about 2 months ago. Updated 18 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
OsmoHLR
Target version:
-
Start date:
04/01/2020
Due date:
% Done:

90%


Description

Columns for subscriber_imsi_pseudo table (reference):
  • id
  • imsi
  • imsi_pseudo
  • imsi_pseudo_i

Checklist

  • add table "subscriber_imsi_pseudo"
  • VTY config option to enable imsi pseudo
  • VTY function to show allocated pseudo imsis for one subscriber
  • VTY command to allocate one imsi pseudo to one subscriber (max. 2)
  • VTY command to deallocate one imsi pseudo
  • VTY tests
  • LU: use imsi pseudo instead of real one
  • LU: automatically deallocate old imsi pseudo if LU was done with newer one
  • LU: cancel subscriber data with previous pseudo IMSI in the connecting peer (VLR/SGSN)
  • LU: ignore location cancel error
  • LU: translate between real IMSI / pseudo IMSI in all procedures when talking to MSC
  • fix sending Location Cancel Request to MSC

Related issues

Blocks IMSI Pseudonymization - Feature #4477: OsmoHLR: send next pseudo IMSI via SMSNew04/01/2020

History

#1 Updated by osmith about 2 months ago

  • Blocks Feature #4477: OsmoHLR: send next pseudo IMSI via SMS added

#2 Updated by osmith about 2 months ago

  • Status changed from New to In Progress
  • Assignee set to osmith

#3 Updated by osmith about 2 months ago

  • Checklist item VTY function to show allocated pseudo imsis for one subscriber added
  • Checklist item add table "subscriber_imsi_pseudo" set to Done
  • Checklist item VTY config option to enable imsi pseudo set to Done
  • % Done changed from 0 to 20

WIP branch: osmith/imsi-pseudo

#4 Updated by osmith about 2 months ago

  • Checklist item VTY command to deallocate one imsi pseudo set to Done

#5 Updated by osmith about 2 months ago

  • Checklist item VTY tests added
  • Checklist item VTY command to allocate one imsi pseudo to one subscriber (max. 2) set to Done
  • % Done changed from 20 to 40

#6 Updated by osmith about 2 months ago

#7 Updated by osmith about 2 months ago

  • Checklist item deleted (LU: purge subscriber in VLR)
  • Checklist item LU: make commented out Location Cancellation code work added
  • Checklist item LU: extend Location Cancellation code to cancel the previous pseudo IMSI added
  • Checklist item LU: use imsi pseudo instead of real one set to Done
  • Checklist item LU: automatically deallocate old imsi pseudo if LU was done with newer one set to Done
  • % Done changed from 40 to 50

Regarding "LU: purge subscriber in VLR": the right GSUP procedure is Location Cancellation (Purge MS would be the opposite direction, VLR instructs HLR to purge MS).

We have unfinished (commented out) code in OsmoHLR to "Cancel in old VLR/SGSN, if new VLR/SGSN differs from old". I will make this work as it was intended (and submit patches to OsmoHLR master, whereas the rest of the IMSI pseudonymization proof of concept will likely just be in a branch).

Then I can extend it to also cancel the subscriber in the old VLR/SGSN if IMSI pseudonymization is enabled, and there is a previous pseudo IMSI allocated, and send the previous pseudo IMSI for cancellation in that case.

#8 Updated by osmith about 1 month ago

  • Checklist item deleted (LU: make commented out Location Cancellation code work)
  • Checklist item deleted (LU: extend Location Cancellation code to cancel the previous pseudo IMSI)
  • Checklist item LU: cancel subscriber data with previous pseudo IMSI in the connecting peer (VLR/SGSN) added

osmith wrote:

We have unfinished (commented out) code in OsmoHLR to "Cancel in old VLR/SGSN, if new VLR/SGSN differs from old". I will make this work as it was intended (and submit patches to OsmoHLR master, whereas the rest of the IMSI pseudonymization proof of concept will likely just be in a branch).

This is more effort than I thought, because the existing code, if enabled, would send the Location Cancellation to the peer that does the LU. This happens to be what we need for IMSI pseudonymization, but to fix it in general for OsmoHLR there is more effort involved with sending the Location Cancellation to the old peer. I've documented this in #4491 and will just directly implement it as needed for IMSI pseudonymization.

#9 Updated by laforge about 1 month ago

  • Category set to OsmoHLR

#10 Updated by osmith about 1 month ago

  • Checklist item LU: ignore location cancel error added
  • Checklist item store, which of the max. 2 allocated pseudo IMSI is currently in use (known in VLR) added
  • Checklist item LU: translate between real IMSI / pseudo IMSI in all procedures when talking to MSC added
  • Checklist item LU: cancel subscriber data with previous pseudo IMSI in the connecting peer (VLR/SGSN) set to Done
  • % Done changed from 50 to 70

I'm testing the changes in combination with the SIM applet (and ATT=1 for now).

The HLR successfully detects if the ME is connecting with the new pseudonymous IMSI, and if there is an old pseudonymous IMSI. If that is the case, it sends the Location Cancel Request to the VLR/MSC. However, the VLR/MSC does not necessarily know the subscriber's old pseudo IMSI. In my testing, because I just added it to the DB. But this could also happen if OsmoMSC gets restarted (because its VLR is not persistent).

So for the IMSI pseudonymization branch, I will let OsmoHLR ignore the location cancel errors, by printing a log message and then continuing with Insert Subscriber Data Request as if it was successful.

Furthermore, I've noticed that the HLR needs some more adjustments to translate between real IMSI <> pseudo IMSI during Insert Subscriber Data and probably during more procedures between HLR and MSC. Therefore I'll need to store which of the max. 2 allocated pseudo IMSIs is currently in use (known by the VLR). No, if there are two allocated IMSIs after the location update has started, then the previous pseudo IMSI is in use. Otherwise it would have been deleted.

#11 Updated by osmith about 1 month ago

  • Checklist item deleted (store, which of the max. 2 allocated pseudo IMSI is currently in use (known in VLR))

#12 Updated by osmith 18 days ago

  • Checklist item fix sending Location Cancel Request to MSC added
  • Checklist item LU: ignore location cancel error set to Done
  • Checklist item LU: translate between real IMSI / pseudo IMSI in all procedures when talking to MSC set to Done
  • % Done changed from 70 to 90

Code rebased on OsmoHLR master (after the D-GSM merge) and continued with implementation.

It's mostly working well now, the pseudonymous IMSI gets translated to the real IMSI in one place right after receiving GSUP messages, and the pseudonymous IMSI used in the current conversation with the MSC gets saved. When sending GSUP messages to the MSC, the saved pseudo IMSI gets used instead of the real IMSI, also in one place. This appears to be working with all GSUP messages getting sent back and forth between MSC and HLR.

The only missing thing for this issue is sending the Location Cancel Request to the MSC, that is currently failing with:

20200507092814673 DPSEUDO DEBUG subscriber_id='5': used current pseudo IMSI '1236' in LU, deallocating previous: '1235' (lu_fsm.c:115)
20200507092814676 DLGSUP ERROR GSUP 4: MSC-00-00-00-00-00-00: IMSI-1232 OSMO_GSUP_MSGT_UPDATE_LOCATION_REQUEST: Invalid response (rc=1): {Subscriber-Management OSMO_GSUP_MSGT_LOCATION_CANCEL_REQUEST: imsi="1235" cn_domain=CS} (lu_fsm.c:260)

(real IMSI: 1232, current pseudo IMSI: 1236, previous: 1235)

It's probably easy to figure that out, but I can't look into it more right now.

The code is in this branch: osmith/imsi-pseudo

https://git.osmocom.org/osmo-hlr/log/?h=osmith/imsi-pseudo

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)