IP Identification behaviour?

asked 2018-11-14 12:41:51 +0000

NJL gravatar image

updated 2018-11-14 12:42:53 +0000

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:

C:\fakepath\Capture.PNG

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.

edit retag flag offensive close merge delete

Comments

Does this article shed some light on it?

Jaap gravatar imageJaap ( 2018-11-14 14:56:02 +0000 )edit

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.

Packet_vlad gravatar imagePacket_vlad ( 2018-11-14 17:29:39 +0000 )edit

Yes and also check MAC addresses

Short answer, It is not forbidden. But indeed it looks a little bit strange

Christian_R gravatar imageChristian_R ( 2018-11-14 18:19:42 +0000 )edit

@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?

NJL gravatar imageNJL ( 2018-11-15 11:14:57 +0000 )edit

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.

Packet_vlad gravatar imagePacket_vlad ( 2018-11-15 11:42:14 +0000 )edit

Packet capture should be available here: https://drive.google.com/file/d/1kdiS...

NJL gravatar imageNJL ( 2018-11-15 11:50:39 +0000 )edit

Do you about what kind of operating Systems we are Talking?

Christian_R gravatar imageChristian_R ( 2018-11-15 17:16:41 +0000 )edit

Not at this time, no. I'm trying to get more information, so I will hopefully know more by tomorrow.

NJL gravatar imageNJL ( 2018-11-15 17:33:52 +0000 )edit