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/.
Neels Hofmeyr nhofmeyr at sysmocom.deThanks for your feedback! On Thu, Jan 23, 2020 at 12:09:47PM +0100, Oliver Smith wrote: > Some notes: > * In the ladder diagrams, it shows that the AKAs are cached in both the > MSC and the HLR. Why not just cache them in the HLR? The MSC is the usual place where (normally 5) auth tuples are cached. That is done to reduce the amount of traffic to the HLR. The MSC requests 5 tuples, uses them up, then requests 5 more. When the MSC has used up its tuples, it needs new tuples *immediately*. That is where the HLR proxy can help out. This made me think, maybe we should just increase the tuple cache size in the MSC and request new tuples before they are all used up? It would be easier than introducing yet another tuple cache in the HLR. Nevertheless, what I like about having another tuple cache in the HLR proxy is: - OsmoMSC's VLR is volatile. The plan is to make the proxy cache persistent, so that it still works after a power outage. Meaning the proxy HLR tuple cache would be more resilient than the MSC cache. - Practically all D-GSM configuration is in a single place: OsmoHLR. No need to remember to also configure OsmoMSC's tuple cache. > * It might be a good idea to make AKA reuse optional with a VTY config > option? Yes, that is the plan, indeed. Also have it switched off by default, since it is in fact a security flaw which the user should consciously decide to use. > * Potential use case: phone is home in village A, gets turned off, owner > travels to village B with the phone, the link to village A is down. That is indeed a situation that cannot be solved with the current design. But it is possible to limit this problem so that it only happens the very first time that a subscriber visits another village after a long long absence: UMTS AKA has sequence numbers (SQN) which must not move backwards, but it does keep (normally 32) separate "slots" of SQN, to be used for different MSCs and SGSNs. So that if a user comes back from another MSC, it can still carry on with the older SQNs from this MSC without needing new tuples, because the two different SQN slots are managed distinctly. So, if we make the proxy cache keep the tuple data for a very long time, then, as soon as a subscriber has once in a cache lifetime shown up in village B, the next time it arrives in B with no link to A, it *can* connect immediately. I think there is a limit to how far the different SQN slots may diverge, but it should be possible to do this to a certain degree, by configuring the proxy. Thanks, it helps to discuss :) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200123/46abe9db/attachment.bin>