GTPv1 - 14-digit IMSI marked as malformed

3GPP
imsi
GTP
retag add tags

3GPP TS 29.060 (GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface) states that IMSI is

TBCD-coded with a fixed length of 8 octets

and that

Each unused half octets shall be coded as binary "1 1 1 1"

However, some IMSIs can be 14-digits long (3GPP TS 23.003 states the length as "not more than 15 digits"), meaning that the last octet is completely padded (0xFF). Sending such IMSI data in GTPv1 Forward Relocation Request results in Wireshark marking the IMSI as malformed and adding the padding octet as another digit '?'.

Is this a false positive in Wireshark and the data is correct? Or is there an exception somewhere in the specifications that allow encoding the IMSI in fewer than 8 octets if it fits?

Sample PCAP: https://filebin.net/zbbyiowc9cj9sy2w

Bliellough

asked 2024-03-19 15:09:49 +0000, updated 2024-03-20 08:37:46 +0000

edit flag offensive 0 remove flag close merge delete

Comments

Can you share a sample capture on a public file share and update the question with a link to it?

Chuckc (2024-03-19 19:39:40 +0000) edit

Sure, I've added a link to a sample capture.

Bliellough (2024-03-20 08:38:57 +0000) edit

Can you add a link to version of 3GPP TS 29.060 spec you're working with.
I found ETSI TS 129 060 V12.6.0 (2014-10) but would be better to use the one you're working with.

There is a capture attached to 5179: GTPv2: IMSI is decoded improperly with padding in one nibble that displays without error:

0000   21 43 65 87 09 65 87 f9
IMSI: 123456789056789

So maybe just a case of handling the double ff bytes.

Current check for valid imsi (epan/dissectors/packet-e212.c):

is_imsi_string_valid(const gchar *imsi_str)
{
    size_t len;

    if (imsi_str == NULL)
        return FALSE;
    len = strlen(imsi_str);
    /* According to TS 23.003 2.2 and 2.3, the number of digits in IMSI shall not exceed 15.
     * Even if in the reality imsis are always 14 or 15 digits long, the standard doesn't say
     * anything about minimum length, except for the ...

(more)

Chuckc (2024-03-20 12:46:03 +0000) edit

@Chuckc: Thanks for looking into this. I'm working with Release-15 of the specs - 29.060, 23.003

I believe the issue is only with a full padding octet. In majority of cases the IMSI is not boxed to a fixed width, instead just the information-carrying octets are coded, hence at most one nibble of padding.

I'm looking into the packet-e212.c and there's dissect_e212_imsi() called first that then calls the is_imsi_string_valid. The dissect function already applies the "?" for overdecadic digits, thus the is_imsi_string_valid rightfully returns FALSE. Not saying you implied otherwise, just quoting the interesting part of the function comment here for the record.

@johnthacker: Thanks for your input. Should I log an issue in the Wireshark GitLab repo or is this something you'd prefer to do, seeing as you know what should be changed and where?

Bliellough (2024-03-20 13:05:46 +0000) edit

Yes - please open a Gitlab issue and include a link back to this question please.
I included is_imsi_string_valid to show the length check. Sorry for not adding a note.

Chuckc (2024-03-20 13:30:15 +0000) edit

add a comment see more comments

1 Answer

Sort by

oldest

newest

most voted

That looks like a bug, there should be an issue. Note that the GTPv2 spec is different, as it specifically indicates a variable length IMSI IE instead of a fixed size. All version of the GTPv1 spec indicate a fixed 8 octets for the IMSI IE (in 7.7.2). Very early on clarification was added indicating that the used digits must be contiguous (i.e., 0xf cannot be used as internal filler, only at the end.)

tvb_get_bcd_string() in epan/tvbuff.c would need to be changed to consider any 0xf as a stop indicator, not just in the extra nibble when there are an odd number of nibbles. I don't _think_ there are any specifications where 0xf is used as internal filler, though that wouldn't work anyway currently if such appeared in the upper nibble (or lower in big endian.)

156

johnthacker

answered 2024-03-20 13:00:05 +0000

edit flag offensive 0 remove flag delete link

Comments

I've created the issue: https://gitlab.com/wireshark/wireshar... The sample PCAP is uploaded there as well, since the filebin storage will time out within a few days. Thanks to you both for confirming the issue, I'd be happy to confirm your answer if you're collecting internet points on this portal.

Bliellough (2024-03-20 14:26:25 +0000) edit

Fixed in 14900: epan: BCD strings with multiple filler nibbles at the end.
Available to test in the 4.3.0rc0 development builds.
Currently only in master branch.

Chuckc (2024-03-24 22:06:35 +0000) edit

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer

GTPv1 - 14-digit IMSI marked as malformed edit

Comments

1 Answer

Comments