Proposed OpenBSC application interface

[Harald Welte]

Hi!

Collin Mulliner, Tobias Engel and myself have been meeting yesterday to
discuss a generic application interface for OpenBSC.

They are both doing security analysis and want to achieve a clean way
how an external application can get access to a more or less transparent
communication channel to the phone.

The purpose of this is to be able to send intentionally malformed
packets to the mobile phone GSM stack at various different levels within
the stack.

As of now, they have both hacked some custom code into openbsc that gets
them half way where they want to be - but not quite all the way.

The requirements can be summarized as follows:

1) Ability to establish a SDCCH or TCH channel by paging the phone
   As of now, the 'silent call' feature from the VTY already does this.

2) Ability to send arbitrary layer3 protocol messages to the phone
   Adding this is relatively easy (use rsl_sendmsg on the lchan from the
   silent call)

3) Ability to receive responses from the phone, as well as error
   conditions such as 'readio link failure'.  We don't have a solution
   for this yet, and we also have no clean way to identify what might
   be a response from the phone to the external app, and what might
   be a message from the phone to the normal network code in OpenBSC

4) Ability to selectively disable partial protocol handling in
   OpenBSC.  Let's say you want to play with the mobile phone call
   control implementation.  In this case, you want to make sure all CC
   related messages go from/to the external program and not from the
   regular OpenBSC network code.

So what I've been thinking of as a solution to the problem:

* store a bypass_flags bitmask related to the subscriber structure,
  where we indicate values such as BYPASS_RR, BYPASS_MM, BYPASS_CC,
  BYPASS_SAPI3.

* if we process an incoming message from the MS in gsm0408_rcvmsg(),
  we check if a bypass flag matching the message is found.  If yes,
  forward the message to the external program

* if we want to send a message from our own protocol stack to the MS,
  we check if a bypass flag matching the message is found.  If yes,
  we drop the message that we were about to send.

* any messages received from the application will be forwarded to the MS

The application interface protocol will likely have a close resemblance
to RSL RLL.  We need to exchange the following primitives with the
application, like:

* ESTABLISH REQUEST -- app requests a channel be established to MS (by IMSI)
* ESTABLISH CONFIRM -- network confirms a channel has been established
* ESTABLISH INDICATION -- network tells app connection was made by MS
* [UNIT] DATA REQUEST -- app requests data to be sent to MS
* [UNIT] DATA INDICATION -- network indicates data was received from MS
* ERROR INDICATION -- network tells app something went wrong
* RELEASE REQUEST -- app asks network to release channel
* RELEASE CONFIRM -- net tells app that channel was released (as rqd)
* RELEASE INDICATION -- net tells app that channel was released (by MS)

The channel_number of RSL (indicating on-air timeslot) doesn't make much
sense in this context, of course.

The link_identifier on the other hand is great as it allows the app to
indicate SDCCH/FACCH or SACCH as well as the SAPI.

The actual RSL-like protocol would be encapsulated by UDP and available
on a socket of the MSC.

What do you think?

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)