IP Identification behaviour?
I've been asked to look at a capture file not captured by me. I know, asking for trouble right away...
I can also ruin your day immediately by the fact that I cannot attach a pcap, since I'm at work and our security policy prohibits even reaching sites such as cloudshark, dropbox, Google drive etc.
So for those that are still reading... : :-)
The capture contains only one TCP session (including handshake) between two hosts. It's clear that the capture is made on host A (packet sizes below 60B).
Data is flowing back and forth between the two hosts (A and B) and at one point host B sends an ACK with the SACK option, indicating that it's missing data. More data is transmitted from host A and more ACKs with SACK is received from host B.
The interesting part is that up until this point, all packets from host B has a slowly increasing IP.ID number, which is 10886 before the first SACK packet from host B (packet 4698). All of these SACK packets has sequential IP.ID starting with 3639 (packet 4701) and upwards i.e. much different than the 10886 that was increasing just prior to these SACK packets. After the data is successfully re-transmitted from host A, host B continues where it left off with IP.ID 10896.
An attempt at an illustration of this:
So, the question really is - what/how can IP.ID suddenly change in the middle of one TCP session?
Is this perfectly normal behavior to have a "secondary" train of IP.ID values to use just for SACK?
I was under the belief that IP.ID would sequentially increase per IP packet and the only way you could see large variances in values, was if you reached the max (64K) and started again from 0.
Does this article shed some light on it?
What is the path looks like? Is there some L4+ payload inspecting device in the middle? Check also if TTL of both ACKs and Dup ACKs is equal.
Yes and also check MAC addresses
Short answer, It is not forbidden. But indeed it looks a little bit strange
@Jaap: Thanks for the link. Already read that and others, but (to me at least) it doesn't really explain what I see here.
TTL is equal between ACKs and Dup ACKs. MAC Addresses are identical. Not sure of the path though. My first thought was also some in-between-device doing this, but even if there is - why would it change the IP.ID just for SACK packets?
Several times I saw firewalls that were trying to "repair" packet loss themselves, so they sent locally-generated SACKs which of course had different IP.IDs. But in your case TTL is the same. It'd be nice to have other side capture.