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