Wireshark · Ethereal-dev: ODP: [Ethereal-dev] Decoding problem for GTPv1

[<Michal.Melerowicz@xxxxxxxxx>]

Hi. Patch will be available soon.
 
Regs, Michal

	-----Wiadomość oryginalna----- 
	Od: ethereal-dev-bounces@xxxxxxxxxxxx w imieniu ext 
	Wysłano: Cz 2004-04-08 08:52 
	Do: ethereal-dev@xxxxxxxxxxxx 
	DW: Rantala Kimmo.P (Nokia-NET/Helsinki) 
	Temat: [Ethereal-dev] Decoding problem for GTPv1
	
	

	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).