Can someone please explain or point me to the proper documentation that explains what the IP.ID field tells me and how to properly interpret it? I have done some searching and have been unable to find a clear definition. Thanks. asked 09 Jul '14, 14:12  madcap |
One Answer:
The following RFC explains it pretty much in detail The short story: One purpose (probably the most important one) of the IP ID field is to enable systems to distinguish IP fragments and to do de-fragmentation or reassembly. For a troubleshooter the IP ID field is interesting as well. If you see duplicate IP IDs in a capture file, it's usually a sign for a switching/routing loop somewhere, given the capture setup is O.K. and does not create duplicate frames itself (like mirroring the wrong ports on a switch). Furthermore, if you capture at two different places between client and server you can use the IP ID field to figure out if some frames got lost on the way, given there is no network devices on the path that does IP ID rewriting (for security reasons, or as a result of some NAT operation). You do that by comparing the (sorted) list of the IP IDs of both capture files. Regards answered 09 Jul '14, 14:27  Kurt Knochner ♦ |
One other use-case for the IP ID field is actually vendor detection.
For example, in mobile wireless networks when looking at dynamic "GTP" tunnel setup and teardown exchanges between operators, one major vendor uses all zeros for the IP ID fields and another follows a specific sequence for that field. Since different vendors have different default settings, timer values, and standards complacency levels, you can actually use the IP ID field from an unknown router and make a really good guess on what optional fields or procedures that router will understand, how quickly it will retransmit something, when it considers a procedure to have implicitely failed, etc., all based on the IP ID field.
There's more:
@Quadratic: Interesting aspect. Is that some kind of 'convention' of those vendors or just a matter of fact that's being used by the carriers to do what you are describing?
Well, I guess you could say that vendor detection in mobile/telecom is really just OS detection, and the IP ID traits probably just come form different people having different takes on the RFC.
In oldschool telecom vendors have very monolithic systems, often developing their own protocol stacks and running them on proprietary hardware. Since a couple of the top vendors just happen to have developed fairly unique IP ID field characteristics, the result is that you can very often eye-ball the IP ID field of a GTP signaling stream and figure the vendor out. Figuring out the vendor effectively figures out the OS, and from that you have all the known limitations, features and default settings of that OS to go on.
I wouldn't say it's that useful, but it can make educated guesses a bit more educated.
For example, let's say that I knew the Cisco ASR 5K platform had a unique IP ID signature, and that Cisco was unique among "SGSN" vendors for not properly supporting a given data barring parameter (eg: it translates the data barring parameter into an error code to the mobile phone that knocks it off the network until a reboot, where all other vendors support the parameter and give the mobile phone a cleaner backoff time). Now, if I am thinking about using that barring parameter for my subscriber database (my "HLR"), it's useful to know how many of my subscribers are registering on Cisco ASR 5K's all around the world to gauge what that impact or trade-off would be, but there's no Vendor ID concept in SS7/MAP messages that I'm getting from those SGSNs, nor is there any in GTP setup messaging, nor is it practical to rely on cold calls to all the operators or rely on old records.
The solution? - Look for the IP ID field in GTP setup requests coming from other operators, and measure how many subscribers register how often on SGSNs with that ID signature. From that, you have an educated guess on what the impact would be if you decided you needed to start using that parameter.
That's a fictitious example, but that's the concept.