GTPv1 - 14-digit IMSI marked as malformed
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
Can you share a sample capture on a public file share and update the question with a link to it?
Sure, I've added a link to a sample capture.
Can you add a link to version of
3GPP TS 29.060spec 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:
So maybe just a case of handling the double
ffbytes.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: 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 theis_imsi_string_valid. The dissect function already applies the"?" for overdecadic digits, thus theis_imsi_string_validrightfully returnsFALSE. 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?
Yes - please open a Gitlab issue and include a link back to this question please.
I included
is_imsi_string_validto show the length check. Sorry for not adding a note.