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.