Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

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. All of these SACK packets has sequential IP.ID starting with 3639 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.

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