The reason why you see paging by IMSI in real-world GSM networks

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

loay abdelrazek loay.razek at gmail.com
Tue May 22 15:42:07 UTC 2018


Thanks Harald, my bad I didn’t go through your reply throughly

Much appreciated

On Sunday, 20 May 2018, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Loay,
>
> On Sun, May 20, 2018 at 03:52:55AM -0400, loay abdelrazek wrote:
> > I wanted to ask your about something regarding user privacy leakage in
> the
> > broadcast channels.  As i have been sniffing and testing myself and i
> found
> > that on the paging requests type 1 IMSI along with TMSI is sent.
>
> Please note that those two identities in one paging request message have no
> relation to each other.  There are simply Paging message types that allow
> combination of multiple (I think up to 4x TMSI), for example.
>
> So the important observation is that IMSIs are present in PCH messages at
> all, and not that they're alongside TMSI.
>
> > I have came to understand that first sending two identifications is the
> > norm,
>
> a paging request can contain 1..4 identities. See above.
>
> > but what i dont understand the high rate of sending IMSI as mobile
> > identification, and as per specification its noted that either TMSI OR
> IMSI
> > are sent,  so does that by any mean could be a configuration issues from
> > the MSC/VLR side that should be changed, is this the norm? if its the
> norm,
> > then why using TMSI.
>
> We have limited insight into what kind of equipment operators use at the
> MSC/VLR,
> and why that equipment behaves in certain ways.
>
> In general, paging by IMSI _can_ be an indication that the VLR has a fixed
> number of IMSI/TMSI mappings that it can store, and that this fixed limit
> is overflowing, causing the VLR to "forget" older mappings.  This in turn
> forces the network to page by IMSI.  Such limitations could actually be
> limitations of physical resources (memory), but they could also very well
> be licensing related (you might pay for the number of concurrent
> subscriber records).
>
> > From your experience what are the countermeasures you think that should
> be
> > taken from the operator side to protect against such information leaks,
> or
> > there is nothing that an operator can do much for this ?What could be the
> > different cases where the IMSI could be sent ?
>
> I don't think there's anything more specific than:
> * look at your paging channel
> * check for ratio of IMSI vs. TMSI pages
> * ensure your VLR doesn't overflow
> * keep debugging if you can find a valid reason for this. If not, work
>   with your VLR supplier to discover what's wrong.
>
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
> ============================================================
> ================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180522/7ea6d086/attachment.htm>


More information about the OpenBSC mailing list