Encryption branch / BSC-MSC split

Sylvain Munaut 246tnt at gmail.com
Wed Jun 9 14:13:08 CEST 2010


> Well we have two settings here...
> one is if we want encryption on, the second is if that subscriber can do
> encryption. With what I have in mind, you would get the subscriber
> connection (currently embedded in the lchan) on a new connection and
> then your function can decide to close the channel, or to secure it and
> then hand it to someone else.

That's what the code does now.

Basically the caller calls the 'secure channel' function and provides
a call back.
What the secure does is :
 - Check if auth/encryption is requested (from the vty config).
 - If it is, and if the MS reported supporting it in ClassMark2, and
if the subscriber has auth information in the DB, then it starts the
auth(if needed), then cipher start.
 - Once done, the call back is called with a status :
  . NO_AVAIL : For some reason, it's not supported (no keys for
subscribers or no CM2 support or not configured ...) But the channel
is up and ready
  . FAIL : It should have been supported but the client failed to pass
authentication, channel is closed.
  . OK : All OK.


I've taken Harald's forward port and modded a couple of things, I'll
test that tonight. The support for ciphering on MS initiated call and
location update doesn't require paging system change.

Sylvain




More information about the OpenBSC mailing list