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.comHi Harald Yes yes I totally understand , so what could be the cases for sending the IMSI and what would be the possible remediation for such thing 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/20180520/34cf0bd9/attachment.htm>