RANAP Security Command can include an encryption IE. If it includes
it the RNC can still ignore it (e.g. unsupported encryption) and
return the Security Command Complete with an choosen encryption IE:
"no encryption".
Validate the encryption element and ensure the encryption is included in
the encryption mask.
Closes: OS#4144
Change-Id: Icfc135c8b8ae862defe7114db492af600c26407f
In order for osmo-hlr to be able to 100% guarantee distinct INDs for CS and PS,
set CN-Domain = CS in all SendAuthInfo Requests.
In Milenage auth, it is highly desirable that osmo-hlr guarantees use of
distinct INDs for CS and PS domains. If an MSC and SGSN attached at the same
time use the same IND bucket to generate Milenage SQN, that collision would
rapidly waste SQNs and load osmo-hlr with requesting new auth tuples on each
CS/PS Complete-Layer3.
So far, osmo-msc did not indicate the CN domain in the GSUP SendAuthInfo
Request, which was neither required nor evaluated. The CN-Domain is only sent
for the UpdateLocation Request that usually follows later.
Related: OS#4318
Change-Id: I22f44068268e62801cadbf6542efaf153423cd65
Recently, the ability to run UTRAN without encryption was added, but the config
for it was tied to the A5 GERAN encryption configuration. This affected
osmo-msc's default behavior of Iu, breaking osmo-msc ttcn3 Iu tests: the ttcn3
test suite sets A5 to 0 (no encryption) but still expects Iu to enable air
encryption. Fix this "regression".
Add a separate vty config option for UEA encryption, even if it does not
provide full granularity to select individual UEA algorithms yet.
As a result, Iu default behavior remains to enable encryption regardless of the
A5 config. UTRAN encryption can be disabled by the new cfg option
"encryption uea 0" alone.
Even though the new vty command already allows passing various combinations of
the UEA algorithm numbers, only '0' and '1 2' are accepted as valid
combinations, to reflect current osmo-msc capabilities.
Revert most changes to the msc_vlr test suite in commit "do not force
encryption on UTRAN" (I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7): use new
net->iu_encryption instead of net->a5_encryption_mask.
Adjust/add to test_nodes.vty transcript tests.
Related: OS#4144
Change-Id: Ie138f2fcb105533f7bc06a6d2e6deccf6faccc5b
Remove the conditions that always enable encryption on UTRAN.
We so far lack an explicit configuration for UTRAN encryption, and this patch
does not add any either. Instead, whether UTRAN encryption is enabled is simply
triggered on whether GERAN has A5 encryption enabled (A5/n with n > 0). Though
GERAN and UTRAN encryption are not technically related at all, this makes UTRAN
behave like GERAN for now, until we implement a proper separate configuration
for UTRAN encryption.
Adjust the msc_vlr_test_* configuration by setting the net->a5_encryption_mask
such that the expected output remains unchanged. A subsequent patch
(I54227f1f08c38c0bf69b9c48924669c4829b04b9) will add more tests, particularly
cases of UTRAN without encryption.
Adjust manual and vty doc.
Related: OS#2783
Change-Id: I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7
We also need stubs for the upcoming db_sms tests.
Due to a known bug of automake [1], we cannot use 'subdir-objects',
so as a side effect this change introduces some autoreconf warnings.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752993
Change-Id: I8846c940f2695fd33e1007fecac83e73f508bb34
3GPP TS 49.008 '4.3 Roles of MSC-A, MSC-I and MSC-T' defines distinct roles:
- MSC-A is responsible for managing subscribers,
- MSC-I is the gateway to the RAN.
- MSC-T is a second transitory gateway to another RAN during Handover.
After inter-MSC Handover, the MSC-I is handled by a remote MSC instance, while
the original MSC-A retains the responsibility of subscriber management.
MSC-T exists in this patch but is not yet used, since Handover is only prepared
for, not yet implemented.
Facilitate Inter-MSC and inter-BSC Handover by the same internal split of MSC
roles.
Compared to inter-MSC Handover, mere inter-BSC has the obvious simplifications:
- all of MSC-A, MSC-I and MSC-T roles will be served by the same osmo-msc
instance,
- messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface
(GSUP),
- no call routing between MSC-A and -I via MNCC necessary.
This is the largest code bomb I have submitted, ever. Out of principle, I
apologize to everyone trying to read this as a whole. Unfortunately, I see no
sense in trying to split this patch into smaller bits. It would be a huge
amount of work to introduce these changes in separate chunks, especially if
each should in turn be useful and pass all test suites. So, unfortunately, we
are stuck with this code bomb.
The following are some details and rationale for this rather huge refactoring:
* separate MSC subscriber management from ran_conn
struct ran_conn is reduced from the pivotal subscriber management entity it has
been so far to a mere storage for an SCCP connection ID and an MSC subscriber
reference.
The new pivotal subscriber management entity is struct msc_a -- struct msub
lists the msc_a, msc_i, msc_t roles, the vast majority of code paths however
use msc_a, since MSC-A is where all the interesting stuff happens.
Before handover, msc_i is an FSM implementation that encodes to the local
ran_conn. After inter-MSC Handover, msc_i is a compatible but different FSM
implementation that instead forwards via/from GSUP. Same goes for the msc_a
struct: if osmo-msc is the MSC-I "RAN proxy" for a remote MSC-A role, the
msc_a->fi is an FSM implementation that merely forwards via/from GSUP.
* New SCCP implementation for RAN access
To be able to forward BSSAP and RANAP messages via the GSUP interface, the
individual message layers need to be cleanly separated. The IuCS implementation
used until now (iu_client from libosmo-ranap) did not provide this level of
separation, and needed a complete rewrite. It was trivial to implement this in
such a way that both BSSAP and RANAP can be handled by the same SCCP code,
hence the new SCCP-RAN layer also replaces BSSAP handling.
sccp_ran.h: struct sccp_ran_inst provides an abstract handler for incoming RAN
connections. A set of callback functions provides implementation specific
details.
* RAN Abstraction (BSSAP vs. RANAP)
The common SCCP implementation did set the theme for the remaining refactoring:
make all other MSC code paths entirely RAN-implementation-agnostic.
ran_infra.c provides data structures that list RAN implementation specifics,
from logging to RAN de-/encoding to SCCP callbacks and timers. A ran_infra
pointer hence allows complete abstraction of RAN implementations:
- managing connected RAN peers (BSC, RNC) in ran_peer.c,
- classifying and de-/encoding RAN PDUs,
- recording connected LACs and cell IDs and sending out Paging requests to
matching RAN peers.
* RAN RESET now also for RANAP
ran_peer.c absorbs the reset_fsm from a_reset.c; in consequence, RANAP also
supports proper RESET semantics now. Hence osmo-hnbgw now also needs to provide
proper RESET handling, which it so far duly ignores. (TODO)
* RAN de-/encoding abstraction
The RAN abstraction mentioned above serves not only to separate RANAP and BSSAP
implementations transparently, but also to be able to optionally handle RAN on
distinct levels. Before Handover, all RAN messages are handled by the MSC-A
role. However, after an inter-MSC Handover, a standalone MSC-I will need to
decode RAN PDUs, at least in order to manage Assignment of RTP streams between
BSS/RNC and MNCC call forwarding.
ran_msg.h provides a common API with abstraction for:
- receiving events from RAN, i.e. passing RAN decode from the BSC/RNC and
MS/UE: struct ran_dec_msg represents RAN messages decoded from either BSSMAP
or RANAP;
- sending RAN events: ran_enc_msg is the counterpart to compose RAN messages
that should be encoded to either BSSMAP or RANAP and passed down to the
BSC/RNC and MS/UE.
The RAN-specific implementations are completely contained by ran_msg_a.c and
ran_msg_iu.c.
In particular, Assignment and Ciphering have so far been distinct code paths
for BSSAP and RANAP, with switch(via_ran){...} statements all over the place.
Using RAN_DEC_* and RAN_ENC_* abstractions, these are now completely unified.
Note that SGs does not qualify for RAN abstraction: the SGs interface always
remains with the MSC-A role, and SGs messages follow quite distinct semantics
from the fairly similar GERAN and UTRAN.
* MGW and RTP stream management
So far, managing MGW endpoints via MGCP was tightly glued in-between
GSM-04.08-CC on the one and MNCC on the other side. Prepare for switching RTP
streams between different RAN peers by moving to object-oriented
implementations: implement struct call_leg and struct rtp_stream with distinct
FSMs each. For MGW communication, use the osmo_mgcpc_ep API that has originated
from osmo-bsc and recently moved to libosmo-mgcp-client for this purpose.
Instead of implementing a sequence of events with code duplication for the RAN
and CN sides, the idea is to manage each RTP stream separately by firing and
receiving events as soon as codecs and RTP ports are negotiated, and letting
the individual FSMs take care of the MGW management "asynchronously". The
caller provides event IDs and an FSM instance that should be notified of RTP
stream setup progress. Hence it becomes possible to reconnect RTP streams from
one GSM-04.08-CC to another (inter-BSC Handover) or between CC and MNCC RTP
peers (inter-MSC Handover) without duplicating the MGCP code for each
transition.
The number of FSM implementations used for MGCP handling may seem a bit of an
overkill. But in fact, the number of perspectives on RTP forwarding are far
from trivial:
- an MGW endpoint is an entity with N connections, and MGCP "sessions" for
configuring them by talking to the MGW;
- an RTP stream is a remote peer connected to one of the endpoint's
connections, which is asynchronously notified of codec and RTP port choices;
- a call leg is the higher level view on either an MT or MO side of a voice
call, a combination of two RTP streams to forward between two remote peers.
BSC MGW PBX
CI CI
[MGW-endpoint]
[--rtp_stream--] [--rtp_stream--]
[----------------call_leg----------------]
* Use counts
Introduce using the new osmo_use_count API added to libosmocore for this
purpose. Each use token has a distinct name in the logging, which can be a
globally constant name or ad-hoc, like the local __func__ string constant. Use
in the new struct msc_a, as well as change vlr_subscr to the new osmo_use_count
API.
* FSM Timeouts
Introduce using the new osmo_tdef API, which provides a common VTY
implementation for all timer numbers, and FSM state transitions with the
correct timeout. Originated in osmo-bsc, recently moved to libosmocore.
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)
Ib9af67b100c4583342a2103669732dab2e577b04 (libosmocore)
Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore)
Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5 (libosmo-sccp)
I26be5c4b06a680f25f19797407ab56a5a4880ddc (osmo-mgw)
Ida0e59f9a1f2dd18efea0a51680a67b69f141efa (osmo-mgw)
I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw)
Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd
Add an SGs interface (3GPP TS 29.118) to osmo-msc in order to support
SMS tunneling and Circuit Switched Fallback (CSFB)
Change-Id: I73359925fc1ca72b33a1466e6ac41307f2f0b11d
Related: OS#3615
Replace locally defined enum ran_type with libosmocore's new enum
osmo_rat_type, and value_string ran_type_names with osmo_rat_type_names.
The string representations change, which has cosmetic effects on the test suite
expectations.
Depends: I659687aef7a4d67ca372a39fef31dee07aed7631 (libosmocore)
Change-Id: I2c78c265dc99df581e1b00e563d6912c7ffdb36b
Give the HLR a chance to send us updated subscriber data by indicating the CN
domain to be Circuit Switched, only during a LU Request GSUP message.
Adjust msc_vlr_tests to expect the added GSUP CN domain IE to indicate CS, i.e.
append '280102'.
Related: OS#3601
Change-Id: I0c2d33fbfdb4728e480679120d06b7f3a2ccfd76
Previously the '*#100#' USSD-request was abused in order to
conclude the current subscriber connection. This makes the unit
tests depend on each other, for example, if one break something
in the GSM 09.11 implementation, a half of tests would fail.
Moreover, the further changes in the GSM 09.11 implementation
will make the results less predictable (i.e. session ID, etc.).
So let's introduce a separate unit test with simple request-
response logic, while more complex tests will be in TTCN.
Change-Id: I40b4caac3113263f5a06c861dff5e10d43c319b5
When sending a BSSMAP Clear or Iu Release, do not immediately discard the conn,
but wait until a BSSMAP Clear Complete / Iu Release Complete has been received.
Hence we will no longer show in the log that an incoming Release/Clear Complete
belongs to an unknown subscriber, but will still be around to properly log the
release.
Related: OS#3122
Change-Id: Ie4c6aaba3866d6e5b98004e8870a215e8cf8ffc1
Match osmo-bsc's naming of the subscriber connection's FSM instance; 'conn->fi'
makes more sense anyway than 'conn->conn_fsm'.
BTW, an upcoming commit will do away with the legacy from libbsc/libmsc duality
and firmly glue the conn allocation to the fi.
Related: OS#3122
Change-Id: If442f2ba78d9722b1065ec30c9a13f372b6a8caa
Clearly distinguish between Ciphering Mode Command on GERAN and Security Mode
Control on UTRAN.
Cosmetic: explicitly verify the key strings in the testing code (not only in
the expected output).
Change-Id: Ica93ed06c4c63dc6768736d25231de8068001114
All functions in the individual msc_vlr_test_*.c files should be static; hence
we would be warned if one of them were unused (forgotten to add to the tests
array).
Change-Id: Ia169c6a1443a48879ab4777e09c2040c48810bf6
Three recently merged commits take the msc_vlr_tests in a wrong direction.
The IMSI is usually encoded in the hex streams. The rationale behind hex
streams is that it is a) easily copied from a wireshark trace and b) exactly
the bytes as sent by an actual phone. It is hard to parameterize the IMSI
because we would have to employ our encoding functions, which I intentionally
want to keep out of the loop here.
The test number should not appear in the normal test output, so that adding a
test or changing their order does not affect expected output for following
tests. The nr is simply for manual invocation, only seen when invoked with -v.
Revert
- "VLR tests: always print test parameters"
b0a4314911.
- "Expand VLR tests"
d5feadeee8.
- "Move IMSI into test parameters"
093300d141.
Change-Id: Ie1b49237746751021da88f6f07bbb9f780d077c9
For each test print:
* the test number
* IMSI
Unfortunately tests are organized in such a way that we don't know the
number of particular test in advance. Nevertheless, it make sense to
always print it regardless of -v option presense.
Related: OS#2864
Change-Id: I2e1d7701f5322d2311f32b796148a8b414f53b8e
Alexander Couzens
Harald Welte