DF, IP ID always 0 and the reassembly protections

DF, IP ID always 0 and the reassembly protections

[Rick Jones]

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

Re: DF, IP ID always 0 and the reassembly protections

[David Miller]

From: Rick Jones <rick.jones2@hp.com>
Date: Tue, 20 Jun 2006 16:44:55 -0700

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

Only the IDs in packets with DF clear matter.

Re: DF, IP ID always 0 and the reassembly protections

[Rick Jones]

David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Tue, 20 Jun 2006 16:44:55 -0700
> 
> 
>>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?
> 
> 
> 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

Re: DF, IP ID always 0 and the reassembly protections

[akepner]

On Tue, 20 Jun 2006, Rick Jones wrote:
> ....
> 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?
>

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

Re: DF, IP ID always 0 and the reassembly protections

[David Miller]

From: Rick Jones <rick.jones2@hp.com>
Date: Tue, 20 Jun 2006 17:35:50 -0700

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

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.