On Nov 19, 2011, at 11:52 PM, Sylvain Munaut wrote:
>> So A5/x will be inside OpenBTS, but A3/A8 can still be outside, up in L4 in sipauthserve.
> Yes, and as you said, using an external executable for this solves the
> issue of trying to find/linking source code for comp128v3 :) AFAIK
> that's how it's done in commercial HLR as well.
> So you store the Kc and key_seq in TMSI table. And I if the client
> does a request (can be LOC UPD, CM SERV, or PAG. RESP) with either :
> - A different key_seq than the one you have
> - No key_seq
> - TMSI table doesn't contain a Kc.
> Then you need to do an AUTH REQUEST first and do a matching SIP
> REGISTER before continuing.
The local copy of the current session key Kc should be put in the transaction record and also copied down to L1 where it is actually used. (That also means that LURs will need transaction records, which they don't yet have. It's a minor complication, but will also produce other benefits in terms of performance monitoring.) Note that L1 should *not* be accessing the transaction table directly, since it's way up in L3/L4. The transaction record has a pointer to the logical channel, which has a pointer to the L1FEC, and that's the path for setting Kc in L1.
I think there should also be a copy of Kc in the registry, though, to support the use of key_seq globally. I don't think that should be in the TMSI table, since the TMSI table is local and temporary and cipher key sequence numbers are supposed to be network-wide and persistent. (In fact, I think the TMSI table, in the future, should just go away, with most of that information going into the registry.) Sure, we could assume that the handset always does an LUR when it enters a new cell, to insure that there's a Kc in the local TMSI table, but there are other network configuration possibilities that we want to leave open.
>> A5/1 is available under BSD and A5/2 is depreciated anyway.
> Well, that's because you're thinking of "production value". Which I
> couldn't care less about :) A5/2 can be useful for research /
Have at it, then. As long as it doesn't get in the way of keeping the commercial and public branches in sync.
>> Linking in a bunch of GPL-only code in L1FEC is a sure way to create a stray branch that will never be unified with the mainline.
> Altough I don't agree, I can understand.
It remains important that we have the freedom to license the software that we write in any way we want; infecting it with someone else's GPL code strips us of that right. So thank you for understanding our position, even if you don't agree.
> The first published version
> was still missing proper credits tough (to the original author of the
> algo where is was copied from, not to libosmogsm).
That seems to happen a lot and it makes me nervous. The CLA indemnifies us against 3rd party license violations, but it would still be a legal and practical mess if something got in here that was not supposed be.
David A. Burgess
Range Networks, Inc.
560 Brannan St.
San Francisco, CA 94107
cell +1 707 208 2622