IPV4: Enable IP_ID sequencing for all traffic (inquiring minds want to know why its set to zero)

There is some security reason why we set IP_ID == 0 right? Could someone point me at the discussions that lead to having IP_ID be zero? Have not been involved in network that much so forgive my ignorance.... and I can only find some hints about why this was done here and there using google.

Here is a patch that would reenable IP_ID sequencing

Subject: [IPV4] Enable IP_ID sequencing on all traffic

The current Linux sources disable IP_ID if the DF flag is set (not always. There is an exception for VJ compression on certain windows platforms).

Just remove the check for the DF flag and always generate the ipid.

Index: linux-2.6/include/net/ip.h
===================================================================
@@ -217,16 +217,7 @@
 
 static inline void ip_select_ident(struct iphdr *iph, struct dst_entry *dst, struct sock *sk)
 {
-	if (iph->frag_off & htons(IP_DF)) {
-		/* This is only to work around buggy Windows95/2000
-		 * VJ compression implementations.  If the ID field
-		 * does not change, they drop every other packet in
-		 * a TCP stream using header compression.
-		 */
-		iph->id = (sk && inet_sk(sk)->daddr) ?
-					htons(inet_sk(sk)->id++) : 0;
-	} else
-		__ip_select_ident(iph, dst, 0);
+	__ip_select_ident(iph, dst, 0);
 }
 
 static inline void ip_select_ident_more(struct iphdr *iph, struct dst_entry *dst, struct sock *sk, int more)

IP_ID is needed for reassembly of fragments, but a fast network can go through all the ID's available before datagrams you've already sent have reached their time to live.

That means you can end up with two different datagrams with the same ID and incorrectly reassemble parts of them together (which you can hope the checksum will catch and cause a drop).

By not using IDs for non-fragmented datagrams, the time to wrap the ID space is increased, which reduces the chance of getting into that situation.

That really is the only protocol use of IP_IDs, so there isn't any point in consuming them for non-fragment datagrams. It's useful sometimes when looking at packet traces to correlate pieces on two different networks, which I'm guessing is why you want it, but I don't think it's a good idea to do it all the time.

                                                +-DLS

Oops, I didn't see all of your message when I replied....

But the explanation is still true. I don't think we should put an ID on every packet.

                                                +-DLS

Wasnt there a time when we did IP_ID on every packet? Any changelogs from that time?

From: Christoph Lameter <[email protected]>
Date: Wed, 16 Jul 2008 14:22:19 -0500

The current behavior existed way before GIT and BK so this might be hard to come by.

A quick check shows that 2.2.x does an unconditional iph->id = ip_id_count++ so you can work forwards from there :-)

I have vague recollections of wanting to avoid (then) locks on the increment in the non-fragmented paths, assertions that covering cases like intermediate devices ignoring DF and fragmenting anyway didn't warrant concern etc.

rick jones

From: Rick Jones <[email protected]>
Date: Wed, 16 Jul 2008 13:39:37 -0700

Partially, yes.

If you look, we do increment the ID for TCP connections which will be setting IP_DF, but we allocate such IDs in a socket-local manner which keeps these allocations from depleating the real ID cache for that destination.

This is legal because when IP_DF is set, the IDs serve no purpose.

We had to do this because TCP header compression, used by SLIP et al., depends upon the ID value incrementing.

The other implied use for IP_ID is as a uniquifier for duplicate packet detection (DPD), e.g., to detect routing loops in the network. But, 16 bits doesn't give sufficient uniqueness for today's data rates anway, so flooding-based protocols like Simplified Multicast Forwarding (SMF) really can't use IP_ID by itself for that purpose.

SEAL extends the IP_ID to 32 bits. With 32 bits, it makes sense to set it as monotonically-incrementing for every packet out since a network-based DPD mechanism could potentially make use of it. Also, 32 bits avoids the ID wraparound issue such that a segmentation and reassembly mechanism can be used even at high data rates.

SEAL is specified in 'draft-templin-seal', and is also implemented at:

http://osprey67.com/seal

This is linux kernel code, but it is not yet ready to be submitted to netdev. It would be good to get some extra eyes on the code to get some independent verification testing and to weed out any bugs. If anyone is interested in checking it out, please let me know.

Thanks - Fred
[email protected]

Well yes that was how the issue came about.

Ahh... interesting. Maybe that would help. I will have a look at that.

From: Christoph Lameter <[email protected]>
Date: Wed, 16 Jul 2008 09:56:21 -0500

As David mentioned, one reason is that the less you allocate the less often ID wrap occurs, which is a very real issue on high speed networks.

I think a more important question is what do you want it re-enabled? You must have stumbled upon this for a reason. :-)

AFAIK it was just for efficiency. The way Linux generates ipids currently is somewhat expensive, because it aims to generate a per ip ipid counter, so it was turned off when not needed. I used to patch that out because it always seemed like overkill to me.

-Andi