10 Mar
2016
10 Mar
'16
10:51 p.m.
Hi list,
today I saw an MM Authentication Response sent from a 3G UE that
mismatches the GSM 04.08 spec. The spec says 0x14, the 3G phone sent 0x94.
And wireshark agrees that 0x94 is an Authentication Response.
The spec ETSI TS 100 940 V7.21.0 (2003-12) chapter 10.4 defines the MM
Authentication Response message type as
8 7 6 5 4 3 2 1
0 x 0 1 - - - - Security messages:
0 1 0 0 AUTHENTICATION RESPONSE
So this would be 0x14 or 0x54, depending on the don't-care bit 7.
The Osmocom code acts according to spec by applying a bitmask of
0xbf (0b10111111) before comparing to 0x14, caring about bit 8.
However, the 3G phone sent an Authentication Response message type of
0x94 (0b10010100) with bit 8 set. Interestingly enough, wireshark
interprets this as a 0x14 with the highest two bits as sequence nr.
So it seems the reality in the field differs from the spec in that bit 8
should be masked away before comparing to the MM message type code.
In consequence, I need to adjust the MM message type bitmask to 0x3f in
upcoming patches.
The thing is, our code has the apparently wrong 0xbf bitmask hardcoded in
numerous places. So as a first step, I will introduce bitmask #defines in
libosmocore and apply these in openbsc.
I will introduce separate bitmask defines for MM and CC messages, because
I'm not sure yet whether CC message types should also be masked with 0x3f
in the field and will leave the CC mask as 0xbf for now.
While doing that, I also noticed that some places apply a 0xbf bitmask
even though the message types in question aren't defined as having any
don't-care bit in TS 100 940. I'll adjust those in a separate patch.
- So at first, I will replace 0xbf with GSM48_MT_MM_MSG_TYPE_MASK or
GSM48_MT_CC_MSG_TYPE_MASK.
- Then I'll adjust the MM mask to 0x3f to allow testing 3G auth.
- Finally I'll remove bit masks where they shouldn't be applicable,
which could use a second opinion by you guys. Are the upper bits always
some sequence number, and the spec simply doesn't reflect the field?
The patch submissions will follow right up...
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
11 Mar
11 Mar
4:18 p.m.
Hi Neels,
On Thu, Mar 10, 2016 at 10:51:45PM +0100, Neels Hofmeyr wrote:
today I saw an MM Authentication Response sent from a
3G UE that
mismatches the GSM 04.08 spec. The spec says 0x14, the 3G phone sent 0x94.
And wireshark agrees that 0x94 is an Authentication Response.
Please see 11.2.3.2.1 and 11.2.3.2.2 of 3GPP TS 24.007, e.g. the latest
version 12.0.0 Release 12 as available from
http://www.etsi.org/deliver/etsi_ts/124000_124099/124007/12.00.00_60/ts_124…
There you can see that in Release99 and later networks, the message type
for MM, CC and SS is defined as having the upper two bits as "N (SD)",
whereas other protocols have other definitions for those bits.
"N (SD)" is described in 11.2.3.2.3 of the same spec
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
14 Mar
14 Mar
2:05 a.m.
On Fri, Mar 11, 2016 at 10:18:57PM +0700, Harald Welte wrote:
Please see 11.2.3.2.1 and 11.2.3.2.2 of 3GPP TS
24.007, e.g. the latest
version 12.0.0 Release 12 as available from
http://www.etsi.org/deliver/etsi_ts/124000_124099/124007/12.00.00_60/ts_124…
There you can see that in Release99 and later networks, the message type
for MM, CC and SS is defined as having the upper two bits as "N (SD)",
whereas other protocols have other definitions for those bits.
"N (SD)" is described in 11.2.3.2.3 of the same spec
Ah, interesting!
I'm not entirely sure how we want to handle whether we're Release99 or not
... is all our code Release99 per se (that's 17 years ago, right!?), or
should that be decided at compile or run time?
Here, I'd use the 0x3f mask for MM and CC, period; particularly because
none of our message type definitions use bit 8 anyway. Opinions?
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
10:33 a.m.
Hi Neels,
On Mon, Mar 14, 2016 at 02:05:11AM +0100, Neels Hofmeyr wrote:
I'm not entirely sure how we want to handle
whether we're Release99 or not
... is all our code Release99 per se (that's 17 years ago, right!?), or
should that be decided at compile or run time?
We should aim at implementing later releases, so the question is rather
'do we want rel 4, rel 5, rel 7' and not 'do we want rel 98 or 99'. As
all the later releases >= R99 use the two upper bits as sequence numbers, the question
is simple: simply use the >= R99 definition.
IIRC, there is a bit somewhere where the GPRS core network (SGSN)
indicates to the MS whether it is a R98 or R99 core network. I think we
have to make sure to set this bit right, and apart from that use the >=
R99 definitions.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
16 Mar
16 Mar
11:18 a.m.
On Mon, Mar 14, 2016 at 10:33:39AM +0100, Harald Welte wrote:
We should aim at implementing later releases, so the
question is rather
'do we want rel 4, rel 5, rel 7' and not 'do we want rel 98 or 99'. As
all the later releases >= R99 use the two upper bits as sequence numbers, the question
is simple: simply use the >= R99 definition.
Nice, I like simple ;)
IIRC, there is a bit somewhere where the GPRS core
network (SGSN)
indicates to the MS whether it is a R98 or R99 core network. I think we
have to make sure to set this bit right, and apart from that use the >=
R99 definitions.
Daniel / Max, have you come across that bit yet?
Thanks!
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
11:42 a.m.
Hi Neels,
On Wed, Mar 16, 2016 at 11:18:46AM +0100, Neels Hofmeyr wrote:
It's the SGSNR bit of the SI13 rest octets. It is already set to H,
indicating "R99 or later". See line 430 of src/libbsc/rest_octets.c.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
IIRC, there is
a bit somewhere where the GPRS core network (SGSN)
indicates to the MS whether it is a R98 or R99 core network. I think we
have to make sure to set this bit right, and apart from that use the >=
R99 definitions.
Daniel / Max, have you come across that bit yet?
3384
days inactive
3390
days old
5 comments
2 participants
participants (2)
-
Harald Welte -
Neels Hofmeyr