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

[Richard Wendland]

> 4. After reading the pf.conf man page from OpenBSD (where it talks about
>    scrubbing IP packets) I don't think it's a good idea to set the ip_id
>    to zero in the DF case.  It seems to cause various kinds of problems
>    when for some reason DF is removed along the path (which it shouldn't
>    but whatever).  I think it is clearly better to put a ip_id into every
>    packet no matter what.

Yes, I think we're both now agreed that zero ip_id for DF is a bad idea
because of what middle-boxes might do to DF.

>    Although the ip_randomid() function doesn't
>    look really cheap to run...  but then security comes at a cost.
> 
> 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.

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

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.

>    On the other hand the code
>    *does* zero the ip_id when DF is set in any case which is troublesome
>    as we just found out.

Yes.

	Richard
-- 
Richard Wendland				richard at wendland.org.uk