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

From: Richard Wendland (richard_at_starburst.demon.co.uk)
Date: 01/08/04

  • Next message: Q: "Re: Intermittent problems with LAN transfer speeds" 
    To: andre@freebsd.org (Andre Oppermann)
Date: Thu, 8 Jan 2004 02:02:08 +0000 (GMT)

    > 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@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@wendland.org.uk
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Q: "Re: Intermittent problems with LAN transfer speeds"

    Relevant Pages

    • Re: [PATCH upate] iso transmit cycle skip patch
      ... I have to admit that I didn't write the patch with the idea of mainline inclusion in mind, but merely as a proof of concept. ... If the transmit fifo can't contain more than one packet (big packets), the DMA should provide a new packet each cycle. ... the meaning of the dropped parameter is: if it's nonzero, ...
      (Linux-Kernel)
    • [PATCH upate] iso transmit cycle skip patch
      ... Subject: ieee1394: rawiso: requeue packet for transmission after skipped cycle ... skip cycles now and then when using large packets. ... is due to DMA not succeeding in time. ... libraw simply passes this dropped parameter to the user application ...
      (Linux-Kernel)
    • Re: [PATCH upate] iso transmit cycle skip patch
      ... If the transmit fifo can't contain more than one packet (big packets), the DMA should provide a new packet each cycle. ... the meaning of the dropped parameter is: if it's nonzero, ...
      (Linux-Kernel)
    • Re: Shannon -- the stream cipher, that is
      ... For small packets, I suppose so. ... though it doesn't look favorably compared to Salsa20, let alone ... cycle counts on 6 different machines for ... py was considerably faster than salsa20. ...
      (sci.crypt)
    • Re: Negation of boolean
      ... It takes only 1 cycle for register-register (which is what we ... SBB AX,AX -- saves inverted state of carry flag ... Testing for Zero ... Ordinary positive numbers are little disturbed by subtracting ...
      (comp.lang.java.help)