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.


More information about the OpenBSC mailing list