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

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

[Christoph Lameter]

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.

Signed-off-by: Christoph Lameter <cl@linux-foundation.org>

Index: linux-2.6/include/net/ip.h
===================================================================
--- linux-2.6.orig/include/net/ip.h	2008-07-16 08:47:50.000000000 -0500
+++ linux-2.6/include/net/ip.h	2008-07-16 08:48:01.000000000 -0500
@@ -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)

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

[David Stevens]

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

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

[David Stevens]

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

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

[Christoph Lameter]

David Stevens wrote:
> 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.

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

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

[David Miller]

From: Christoph Lameter <cl@linux-foundation.org>
Date: Wed, 16 Jul 2008 09:56:21 -0500

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

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

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

[David Miller]

From: Christoph Lameter <cl@linux-foundation.org>
Date: Wed, 16 Jul 2008 14:22:19 -0500

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

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 :-)

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

[Rick Jones]

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

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

[David Miller]

From: Rick Jones <rick.jones2@hp.com>
Date: Wed, 16 Jul 2008 13:39:37 -0700

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

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.

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

[Templin, Fred L]

 >-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net] 
>Sent: Wednesday, July 16, 2008 2:01 PM
>To: rick.jones2@hp.com
>Cc: cl@linux-foundation.org; dlstevens@us.ibm.com; 
>netdev@vger.kernel.org; netdev-owner@vger.kernel.org
>Subject: Re: IPV4: Enable IP_ID sequencing for all traffic 
>(inquiring mindswant to know why its set to zero)
>
>From: Rick Jones <rick.jones2@hp.com>
>Date: Wed, 16 Jul 2008 13:39:37 -0700
>
>> 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.
>
>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.

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
fred.l.templin@boeing.com 

>We had to do this because TCP header compression, used by SLIP et
>al., depends upon the ID value incrementing.
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Christoph Lameter]

Templin, Fred L wrote:

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

Well yes that was how the issue came about.

> 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

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

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

[Andi Kleen]

Christoph Lameter <cl@linux-foundation.org> writes:

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

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