[PATCH] sysmobts: Deal with ciphering when we have a transport clash

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Mon Aug 11 07:59:47 UTC 2014


Hi Holger,

the patches look fine to me, although it hurts that such a hack and
layering violations is actually needed.  I'm wondering if the spec
designers didn't come up with a more elegant method.

In OpenBSC we could of course disable early classmark sending, but we
cannot exclude osmo-bts / sysmobts from being used with other
implementations either.

What about OpenBSC waiting for the classmark change to arrive _if_ early
classmark sending is enabled?  At least, if A5/4 is ever used, this is
the only way to support it anyway, as A5/4 is indicated only in CM3, and
CM3 is only part of CLASSMARK CHANGE, but not part of the CM SERVICE
REQUEST or PAGING RESPONSE.

However, as we are probably all quite sure that the GSM industry is not
capable of rolling out a 'new' cipher in less than 10 years, I'm not
sure if we should worry about this here.

-- 
- 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)




More information about the OpenBSC mailing list