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
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_1240...
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
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_1240...
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
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.
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
Hi Neels,
On Wed, Mar 16, 2016 at 11:18:46AM +0100, Neels Hofmeyr wrote:
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?
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 -
Neels Hofmeyr