Ethereal-dev: [Ethereal-dev] Decoding problem for GTPv1

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date: Thu, 8 Apr 2004 09:52:23 +0300
Hi

I just started using Ethereal as a GTP analyser and ran into a decoding problem. I found the discussion below from your mailing lists, but I guess the problem was never found out since the latest version still has the same bug.

I believe the problem lies in decoding of the authentication quintuplet. The TS 29.060 describes how the quintuplets should be coded to MM context information element:

"The Quintuplet array contains Quintuplets encoded as the value in the Authentication Quintuplet information element. The Quintuplet array shall be present if indicated in the Security Mode. If the quintuplet array is present, the Quintuplet length field indicates its length."

So the array contains only _value_ part of the IE. It seems that Ethreal tries to decode it as it would have also the lenght field and it fails because of that. So the quintuplets (0-4) are preceeded by a separate lenght field that holds the lenght of the whole array (all quintuplets). The following quintuplets are then coded like in chapter 7.7.35 Authentication Quintuplet, but with the value part only.

The type and value are only coded when the Authentication Quintuplet is present as "standalone" as in Identification Response message.

I attached also an example of this "malformed" message. Hopefully this helps you to fix the problem, so I don't need to decode the messages manually from hex anymore :-)

Regs,
-Kimmo-





Subject: Re: [Ethereal-dev] Decoding problem for GTPv1 
From: Guy Harris <guy@xxxxxxxxxxxx> 
Date: Sun, 14 Sep 2003 18:11:31 -0700 

--------------------------------------------------------------------------------

On Fri, Sep 12, 2003 at 09:03:29AM +0200, Wuttichai Wutti-Udomlert (DU/EDD) wrote:
> > From: Guy Harris [mailto:guy@xxxxxxxxxxxx]
> > Sent: Thursday, September 11, 2003 11:03 PM
> > To: Wuttichai Wutti-Udomlert (DU/EDD)
> > Cc: 'ethereal-dev@xxxxxxxxxxxx'
> > Subject: Re: [Ethereal-dev] Decoding problem for GTPv1
> > 
> > 
> > 
> > On Sep 11, 2003, at 5:42 AM, Wuttichai Wutti-Udomlert (DU/EDD) wrote:
> > 
> > > I'm using Ethereal version 0.9.14 and 0.9.15 on Windows2000 for 
> > > capturing GTPv1 protocol.  By the way, it is not possible to decode in 
> > > some message.  Are there any posibility to decode the message 
> > > correctly?  I've attach the example below.
> > 
> > We'd probably have to see the capture file with that packet in it in 
> > order to debug the problem.
> > 
> Hello,
> 
> I send you the capture file for investigation.  Hope you can debug from this.

Well, yes, I can - but I'm not sure what the solution is, so I'm CCing
ethereal-dev in case somebody more familiar with GTP can suggest a
better way to solve this than to have a preference setting controlling
whether to assume the GSM or UMTS interpretation of a mobility
management context.

At least according to ETSI TS 101 347 V7.8.0, a/k/a 3GPP TS 09.60
version 7.8.0, section 7.9.19, the MM Context IE has, in octet 5, the 2
uppermost bits containing 11, the next 3 bits containing the number of
triplets in the IE, and the next 3 bits containing the cipher used.  The
IE contains a GSM key and triplets.

According to ETSI TS 129 060 V4.3.0, a/k/a 3GPP TS 29.060 version 4.3.0,
section 7.7.28, the MM Context IE has, in octet 5, 2 bits of security
mode, 3 bits containing the number of vectors, and the next 3 bits
containing the cipher used.

The security mode values are:

	1	GSM key and triplets
	3	GSM key and quintuplets
	2	UMTS key and quintuplets
	4	Used cipher value, UMTS keys and quintuplets

Unfortunately, 3 is two bits of 1, so that means that, according to
029.060, if the 2 uppermost bits of octet 5 are 11, the IE contains a
GSM key and quintuplets, not a GSM key and triplets.  That doesn't match
09.60.

I don't know whether that's:

	1) a typo (with 3 meaning "GSM key and triplets);

	2) an incompatibility (so that the software parsing that IE has
	   to know - either explicitly, or implicitly based on the type
	   of mobile phone network is being used - which standard
	   applies).

Frame 2 (345 bytes on wire, 345 bytes captured)
    Arrival Time: Apr  7, 2004 13:32:06.182497000
    Time delta from previous packet: 0.044295000 seconds
    Time since reference or first frame: 0.044295000 seconds
    Frame Number: 2
    Packet Length: 345 bytes
    Capture Length: 345 bytes
Ethernet II, Src: 00:0c:ce:64:49:3f, Dst: 00:a0:8e:54:43:50
    Destination: 00:a0:8e:54:43:50 (NokiaInt_54:43:50)
    Source: 00:0c:ce:64:49:3f (Cisco_64:49:3f)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.133.1 (192.168.133.1), Dst Addr: 192.168.164.225 (192.168.164.225)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 331
    Identification: 0x26cc (9932)
    Flags: 0x00
        0... = Reserved bit: Not set
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 28
    Protocol: UDP (0x11)
    Header checksum: 0xcba2 (correct)
    Source: 192.168.133.1 (192.168.133.1)
    Destination: 192.168.164.225 (192.168.164.225)
User Datagram Protocol, Src Port: 2123 (2123), Dst Port: 2123 (2123)
    Source port: 2123 (2123)
    Destination port: 2123 (2123)
    Length: 311
    Checksum: 0xbb72 (correct)
GPRS Tunneling Protocol
    Flags: 0x32
        001. .... = Version: GTP release 99 version (1)
        ...1 .... = Protocol type: 1
        .... 0... = Reserved: 0
        .... .0.. = Is Next Extension Header present?: no
        .... ..1. = Is Sequence Number present?: yes
        .... ...0 = Is N-PDU number present?: no
    Message Type: SGSN context response (0x33)
    Length: 295
    TEID: 0x1b000000
    Sequence number: 0x00b6
    N-PDU Number: 0x00
    Next extension header type: 0x00
    [--- end of GTP header, beginning of extension headers ---]
    Cause : Request accepted (128)
    IMSI: 460065004500052
    TEID Control Plane: 0x42000500
    MM context
        Length: 109
        Ciphering Key Sequence Number: 1
        Security type: 0 (Used cipher value, UMTS keys and Quintuplets)
        No of triplets: 3
        Ciphering: no ciphering
        Ciphering key CK: A1DF06FADF577EE5515098702F702729
        Integrity key CK: 572D218A58528C7F33511C83F76DB336
        Quintuplets length: de
        Quintuplet #0
            Length: c71e
            RAND: 003FF1EABEDD3DE21A193F2174920811
            XRES length: 47813
[Malformed Packet: GTP]

0000  00 a0 8e 54 43 50 00 0c ce 64 49 3f 08 00 45 00   ...TCP...dI?..E.
0010  01 4b 26 cc 00 00 1c 11 cb a2 c0 a8 85 01 c0 a8   .K&.............
0020  a4 e1 08 4b 08 4b 01 37 bb 72 32 33 01 27 1b 00   ...K.K.7.r23.'..
0030  00 00 00 b6 00 00 01 80 02 64 00 56 00 54 00 50   .........d.V.T.P
0040  f2 11 42 00 05 00 81 01 09 f9 18 a1 df 06 fa df   ..B.............
0050  57 7e e5 51 50 98 70 2f 70 27 29 57 2d 21 8a 58   W~.QP.p/p')W-!.X
0060  52 8c 7f 33 51 1c 83 f7 6d b3 36 00 de c7 1e 00   R..3Q...m.6.....
0070  3f f1 ea be dd 3d e2 1a 19 3f 21 74 92 08 11 ba   ?....=...?!t....
0080  c5 e9 83 8b da 54 fd 74 14 1e 16 f7 f8 d4 5c ae   .....T.t......\.
0090  23 76 48 3a bd b5 b1 56 38 e1 07 71 76 5a 9d b6   #vH:...V8..qvZ..
00a0  53 cd 6c 39 63 f2 10 07 f9 35 0e dd 80 00 00 26   S.l9c....5.....&
00b0  b3 88 0b be 27 da 12 99 22 b4 da 4c 64 ff 50 de   ....'..."..Ld.P.
00c0  c1 59 50 59 6c 5b a6 08 63 56 6f d8 e9 61 14 cd   .YPYl[..cVo..a..
00d0  29 f8 c0 fd 27 e1 f4 20 fd 32 92 ce 02 ca 53 7c   )...'.. .2....S|
00e0  10 7a b3 8c cd af b8 b1 8f b8 a3 ba 6c ae 8f c2   .z..........l...
00f0  10 89 51 10 38 42 68 00 00 16 34 2d 5e 09 17 f0   ..Q.8Bh...4-^...
0100  02 a1 1d 26 f8 29 92 2b 9c d2 28 5d 0e bb 88 55   ...&.).+..(]...U
0110  2a 08 ba 6b 75 d6 dc 72 6c c4 c2 98 cd c3 17 e5   *..ku..rl.......
0120  4b a2 22 e9 c8 fd f7 ec 37 4b 63 89 ed 76 65 19   K.".....7Kc..ve.
0130  43 3b 5e 8d be 88 03 4f 1a 93 10 ae 1d 18 69 b5   C;^....O......i.
0140  85 00 00 f3 27 a7 41 86 ac 21 a0 07 02 02 e5 40   ....'.A..!.....@
0150  00 00 85 00 04 c0 a8 85 01                        .........