DF, IP ID always 0 and the reassembly protections

A while back (I cannot recall exactly when) the issue of always setting the IP datagram ID to zero when the DF bit was set was brought-up. I suggested it might not be a good idea because there are admittedly broken devices out there that "helpfully" and silently clear DF and the start to fragment. The counter point was that coding around such broken hardware was silly.

I was just writing a missive to one of my co-workers on IP fragmentation. It got me to thinking about the stuff (I think it went-in?) to try to protect against "Frankengrams" during IP fragment reassembly.

Doesn't that mechanism rely on watching the IP ID's between the pair of IPs? For both fragmented and non-fragmented datagrams? If so, does always setting the IP ID to zero when DF is set affect that mechanism?

rick jones

From: Rick Jones <[email protected]>
Date: Tue, 20 Jun 2006 16:44:55 -0700

Only the IDs in packets with DF clear matter.

I thought the ID's even in non-fragmented datagrams gave an idea of how many IP datagrams had been sent along, and so an idea of how "unlikely" it was that a datagram with holes could be reassembled?

rick jones

Only fragmented datagrams get counted. This is arguably a weakness of the scheme, but it's still a big improvement in practice. And the more common non-fragmented datagram processing doesn't have to pay the price for the extra checks.

Arthur

From: Rick Jones <[email protected]>
Date: Tue, 20 Jun 2006 17:35:50 -0700

The code you are thinking about is in net/ipv4/ip_fragment.c and it attempts to avoid ID wrapping corruption. It only looks at IP fragments on input.