Hi Neels,
D-GSM proxy cache -- if you have the time, feedback on this design document would be appreciated: http://git.osmocom.org/osmo-hlr/commit/?h=neels/dgsm&id=8071c561405a031f... (when that commit is checked out, building osmo-hlr with manuals enabled should render the ladder diagrams in proxy_cache.adoc, which illustrate what I'm planning to implement) (and disregard "(7) Skip the Insert Subscriber Data", as explained in the prose)
I like that the key of the home HLR is not shared with the proxy HLRs. All in all, it sounds like a very smart solution!
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? * It might be a good idea to make AKA reuse optional with a VTY config option? * 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. Phone gets turned on, then there will be no AKAs cached in village B's (proxy) HLR and the LU will fail. But there does not seem a way around this without sharing the keys (or without spaming other HLRs with AKAs for all subscribers in the HLR that they might use in the future, but that would just waste traffic).
Regards, Oliver
Thanks 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
-
Neels Hofmeyr -
Oliver Smith