Subject: Re: RFC5722 and network packet duplication

From: Dennis Ferguson <[email-masked]>
Date: Tue, 1 Sep 2015 12:43:26 -0700

Suresh,

On 31 Aug, 2015, at 11:16 , Suresh Krishnan <[email-masked]> wrote:
> One thing I would like to point out though is that depending on the implementation of the reassembly (specifically the context retained about the fragments) it might be difficult or impossible to differentiate between duplicates and overlaps.

Though if the goal is to resist the attack outlined in RFC5722, which is a
more specific problem than duplicates and overlaps, I think it might be
sufficient to just drop incoming fragments that duplicate (the offset and
extent of) data you've already received, independent of where the packet
boundaries are, while only abandoning the reassembly if an incoming fragment
carries both data you still need and data you've already got (though I would
thoroughly enjoy being told I am wrong about this).  This would permit a
reassembly implementation to continue to only keep track of where the holes
it needs to fill are.

> Another thing that might complicate issues is that calling something a duplicate requires checking whether the contents of the fragment are actually duplicate. This may also require additional processing.

But what attack would this be preventing?  If the goal is to resist the
attack in RFC5722 then I think defining "duplicate fragments" as fragments
with the same offset and extent should be sufficient (though I welcome
correction).

The goal should be to resist the RFC5722 attack while leaving the fragmentation
protocol as robust as possible (as in not dropping data that could have been sent
by a legitimate sender).  The lowest cost implementation that manages this is
the best one, so for a standard the task is to define the problem in terms which
allow that low cost implementation to be written.

Dennis Ferguson