23 Jan
2020
23 Jan
'20
5:32 p.m.
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