kern/60889 - zero IP id change issues in 5.2RC2

[Andre Oppermann]

Richard Wendland wrote:
> > 5. Random ip_id is already a kernel option but it is *not* enabled by
> >    default in 5.2RC2 GENERIC or -current.
> 
> I don't think random ip_id should be enabled by default.  The reduction
> in ip_id cycle from 64k is a real re-assembly risk on modern high-speed
> networks.  Random ip_id brings debatable benefits.  There was a good
> discussion about this on tech-net at NetBSD.org last November, where they
> rejected random ip_id as default.

Ok.

> One issue is that they (claim to have) discovered the OpenBSD random
> ip_id code has a 12k cycle rather than the advertised 30k:
> 
>   http://mail-index.netbsd.org/tech-net/2003/11/26/0005.html
>   http://mail-index.netbsd.org/tech-net/2003/11/27/0007.html
> 
> The other is a consideration of what the maximum safe data transfer rate
> is for a given ip_id cycle.  You want long ip_id cycle times for non-DF
> gigabit networking, like NFS.  I buy into these arguments by Robert Elz
> and Jonathan Stone:
> 
>   http://mail-index.netbsd.org/tech-net/2003/11/26/0013.html
>   http://mail-index.netbsd.org/tech-net/2003/11/26/0015.html
> 
> though a good contrary view is:
> 
>   http://mail-index.netbsd.org/tech-net/2003/11/26/0021.html

Haven't read all of that yet.

> It's important to remember that if fragmentation takes place, and a
> fragment is lost, the other fragment(s) will wait for quite some time in
> a re-assembly buffer (maybe up to 63 seconds).  While they are waiting
> they are at quite some risk of being joined onto a fragment from the
> next ip_id cycle if a lot of packets are flowing:
> 
>   http://mail-index.netbsd.org/tech-net/2003/11/26/0022.html
>   http://mail-index.netbsd.org/tech-net/2003/11/26/0023.html
> 
> Remember a 64k cycle is consumed by 64MB of transfer if average datagram
> size is 1024 bytes.  Thats not a lot on a gigabit network.
> 
> The better solution in my opinion is to do similar to Solaris, have
> per-destination ip_id counters (or at least a hash of destination IP
> to one of N ip_id counters).  You typically get longer cycle times and
> improved privacy, with a method that is faster than random ip_id.

I have an idea how to something like this in an efficient manner.
Have a global incrementing ip_id counter and a small fixed size
hash table.  The hash is computed from faddr/fport (see tcp_hostcache
for a good hash function).  The hash table contains seeds in every
bucket which are refreshed periodically (every second or ten or
whatever).  For an outgoing packet you take the global ip_id counter,
increment it by one, take the result and XOR it with the seed in
the apropriate bucket.  The chance of collisions is very low and
you get the full 64k cycle (globally).  Or you can do it the other
way around and have a counter in every bucket and a global seed.
Need to think about which is actually better.

-- 
Andre