Hi,
I landed the first big change, the gsm48_rcvmsg is now inside the bsc_api.c. And on first msg the BSC API will call the compl_l3 (COMPLETE LAYER3) callback. This method will always be called for any new connection and is the perfect place to enable encryption..
I would be very happy if someone could take the task and change the osmo_msc.c and gsm_04_08.c to first make use of the ACCEPT/REJECT policy and then enable the auth/security on this new connection and then dispatch the original message (but CM Service Reject).
Another task would be to move the Cipher Mode code into the BSC API, the gsm_04_08.c code should not directly change the attributes in the lchan and should not send the cipher mode RR message.
The next thing to kill is the unconditional usage of &lchan->conn as I will start allocating the conn dynamically... (one conn can have multiple lchan's for handover and early assignment).
I will now work on refcounting and moving the transaction into the subscriber connection...(some other work before) so I will probably not make it before sunday as I will be out of town.
regards holger
I landed the first big change, the gsm48_rcvmsg is now inside the bsc_api.c. And on first msg the BSC API will call the compl_l3 (COMPLETE LAYER3) callback. This method will always be called for any new connection and is the perfect place to enable encryption..
Looking into it, however I'm not yet sure how it will turn out because of the quirks of encryption I mentionned on IRC. Namely: - ciph mode command is implicit cm serv accept - need to extract key_seq from the various possible message - not all incoming message can trigger the auth procedure. (IMSI DETACH for example doesn't support it AFAICT)
So it'll have to somehow be a three step process: - Pre-treatment of the first message (possibly the end of the treatment if nothing else supported or if it's a reject of some kind) - Run the auth/ciphering procedure (and possibly other could be plugged in, like the class mark or identity request procedure) but then again, there are interaction between those, they're not fully isolated. - Proceed with the rest of the first message (but need some feed back from the other procedure that have been run ...)
I'm wondering : Can those 'initial l3 messages' sometime appear 'in the middle' of an already established channel ?
Another task would be to move the Cipher Mode code into the BSC API, the gsm_04_08.c code should not directly change the attributes in the lchan and should not send the cipher mode RR message.
Ok, I'm on it.
My current approach will be to just implement cipher related BSSMAP messages of GSM 08.08 as function calls back & forth the msc / bsc domain. This way for a real worlds msc connection, it would just need to implement the wrapping / unwrapping of those in a real SCCP/BSSMAP connection.
(that's the idea if I understood the code correctly)
Sylvain
-
Holger Hans Peter Freyther -
Sylvain Munaut