Answers
Easy: What QCI value is used for the IMS bearer?
The IMS bearer seen in the E-RAB setup request, which shows the QCI 5 value set on the “ims” bearer, seen in frame #269.
Easy: What is the registration expiry?
The UE requests 3600 seconds for registration expiry in the SIP REGISTER in frame #269.
The 200 OK from the S-CSCF in #672 does not change this so that’s what’s used.
Easy: What ARP settings is used for the IMS Signaling traffic on the default bearer?
We can see in the E-RAB setup request in #269 that the ARP associated with this bearer is:
Priority Level: 1 Pre Emption Capability: Cannot trigger Pre-emption Pre Emption Vulnerability: Not Preemptable (Cannot be preempted)
Easy: What is the E-UTRAN Cell ID the Subscriber is served by?
This is in the P-Access-Network-Info header in frame #460.
ECI: 001010001000019b
Bonus points for decoding the ECI, which gives us PLMN 001/01, eNB ID 526336 and Cell ID 268435867.
Easy: What is the AMBR of the IMS APN?
This is shown in the ERAB Setup Request in frame #269.
The AMBR is set to 3840Kbps / 1472 Kbps.
Intermediate: Is this the first or subsequent registration?
In the Diameter Experimental Result for the User-Authorization-Answer we can see this is a Subsequent Registration (2002) seen in frame #355.
Intermediate: What is the Integrity-Key for the registration?
The IK used for this registration is given in the Multimedia-Authentication-Answer response, inside the 3GPP-SIP-Auth-Data-Items, seen in frame #402.
IK: e1763cf28cc2e584588800193137ec92
This is also sent in the 401 to the UE in frame #480.
Intermediate: What is the FQDN of the S-CSCF?
The S-CSCF’s FQDN is included in the Server-Assignment-Request in frame #488 where the S-CSCF tells the HSS it is serving this sub.
In this case the value is sip:scscf.ims.mnc001.mcc001.3gppnetwork.org:6060.
Intermediate: What Nonce value is used and what does it do?
The Nonce field is the Base64 encoded version of the RAND value and concatenated with the AUTN token from our AKA response.
In our case the value is:
oJRMdf88TwhTovkQqh8QT8bi9GyPQoAAfzu5uEt8P/Y=
As seen in frame #404 generated by the S-CSCF based on the MAA from the HSS.
Intermediate: What P-CSCF Addresses are returned?
The PGW returns this in the Protocol Configuration Options, we can see in the Create Session Response that the PCO only includes on P-CSCF address – 10.4.128.21.
This is in frame #267.
This info is also transferred in the E-RAB setup request inside the NAS body in frame #269.
We can see the UE is sending the SIP traffic to this address, however just looking at where traffic is sent is not a foolproof solution as we may have multiple P-CSCF addresses returned, but not used.
Intermediate: What time would the UE need to re-register by in order to stay active?
The 200 OK is sent at 08:01:00 and the expires is set to 3600 (1 hour).
So the UE would need to send another REGISTER before 09:01:00 in order to remain registered (most IMSes allow a grace period of a few seconds to allow for delays in the sub being out of coverage).
Intermediate: What is the AA-Request in #476 doing?
This installs the Traffic Flow Template into the PCRF (And by proxy in the PGW) for the AF_SIGNALING traffic.
Intermediate: Who is the OEM of the handset?
The phone is a Samsung, the User-Agent lists this, “Samsung IMS 6.0” in frame #460.
This header is optional however, but there is a way to find the model of the phone (and then the OEM) – see the later question on this.
Intermediate: What is the MSISDN associated with this user?
Multiple different ways to find this info;
The P-Associated-URI in the 200 OK to the REGISTER in frame #674 contains this information:
This is based on the data received in the Server-Assignment-Answer response, in the Cx-User-Data AVP, under the <PublicIdentity> keys in frame #670.
Hard: What port is used for the ESP data?
Trick question, ESP does not have ports – Only Security Associations.
ESP doesn’t have a “port” – Instead the IP header indicates that it is carrying ESP by setting the protocol ID to 50 (ESP).
Hard: Which encryption algorithm and algorithm is used?
This is set in the 401 back from the P-CSCF to the UE in frame #408, in the Sercurity-Server header.
In this case, the encryption algorithm (ealg) used in Null, and algorithm used in this case HMAC-SHA-1-96.
Hard: How many packets are sent over the ESP tunnel to the UE?
The SPI for the Downlink (To the UE) is 0x00006438,
So filtering in Wireshark based on:
esp.spi == 0x00006438
Gives us 18 packets, if you answered 33 packets, this is incorrect as it includes the data not sent over ESP.
Hard: Where should SIP SUBSCRIBE requests get routed?
The iFC is sent in the Server-Assignment-Answer response, in the Cx-User-Data AVP, under the <ServiceProfile> / <InitialFilterCriteria> keys in frame #670.
Inside the iFC we have a trigger point for when the event is SUBSCRIBE to route the request to sip:10.4.128.21:6060.
Hard: What’s the model of phone?
We can see from the Contact parameter the IMEI of the device is 356224104838400
Contact parameter: +sip.instance="<urn:gsma:imei:35622410-483840-0>"
We can punch this into the an IMEI search to find the model.
The phone is a Samsung Galaxy Tab A8.
That’s it!
PS – If you enjoyed this here’s the Packet Core analysis challenge from last year.
Hi!
Nice challenge!
Are you using an IMS based in Kamailio in production/enterprise systems?
BR Kim
Nick, this was a fascinating journey, I got most of the things right, some things however were new to me.
One thing to note is that I’m fairly certain it is not OK to send over to the UE in the 401 the actual keys to be used, that packet and your interpretation of it is something I do not understand.
As far as I know the flow should be: REGISTER—401 (UE calculates keys using USIM) –> REGISTER –> OK –> ESP on separate ports (UDP ports I mean). Raw key material should not travel across at any point, that would render the whole protocol useless in case of a passive, listening adversary.
Thanks in advance.
Hi Nick,
thank you for putting together this awesome quiz. I wished I had scored higher but it was definitely a fun challenge. Looking forward to more such quizzes in future.
I do have a question though. Did you use a particular version/dissector of Wireshark to decode the NAS-EPS packets in the S1AP messages? I am on the latest version (Version 4.0.8 (v4.0.8-0-g81696bb74857)) on Windows 7 but was unable to do decode any of them in full.
For e.g. #269, which contained the Activate default bearer context message was decoded only until nAS-PDU: 278863adc012, and nothing after i.e. 6202c101050403696d730501c0a865055e02b38e58322729808021100200
I tried to google the answer but found results from 9-10 years ago which arent helpful..
Any advice on how to decode the NAS-EPS messages? Any wireshark settings you can share?