Re: [dtn-security] Including fragment offset in the correlator doesn't prevent all fragment collisions.

[Amy Alford <[e-mail]>]

Isn't this fixable by defining a PIB ciphersuite that only protects the
primary block?
- Amy

On Thu, Mar 21, 2013 at 12:19 AM, Ivancic, William D. (GRC-RHN0) <
[e-mail]> wrote:

>  A 5 GB bundle come forms Mr. Bad.  You don’t want to store anything from
> Mr. Bad, but you cannot confirm the source  using PIB until you receive the
> entire bundle thus eating up 5 GB of resources.
>
> It is broken.
>
> -- Will
>
>
> ------------------------------
> *From: *Amy Alford <[e-mail]>
> *Date: *Wed, 20 Mar 2013 18:36:32 -0500
> *To: *Peter Lovell <[e-mail]>
> *Cc: *dtn-security <[e-mail]>
>
> *Subject: *Re: [dtn-security] Including fragment offset in the correlator
> doesn't prevent all fragment collisions.
>
> A 100 byte bundle is created.  Different nodes independently fragment it
> into 50 byte fragments.  A subsequent node adds PIB and PCB (so we have
> correlated PCB blocks) to each fragment with a security destination of the
> bundle destination.   The correlators can collide. (In DTN2, they will
> collide.)
>
> If the fragments are reassembled before the destination, the destination
> has no way to distinguish the PCB blocks that should correlate with each
> other.
>
> Alternatively, if we assume reassembly only happens at the destination
> (which 5050 doesn't guarantee), we still have a problem if we use a two
> block PIB ciphersuite where one block comes before the payload and one
> comes after.
>
> A node creates a 100 byte bundle.  It's independently fragmented into 50
> byte bundles.  A subsequent node adds a PIB ciphersuite with a correlated
> block trailing the payload.  Again, the correlators collide.  Now, each 50
> byte fragment is fragmented again.  So, we have fragments:
>
> (I'm numbering the PIB instances so that we can distinguish them in the
> discussion.  The numbers don't correspond to anything identifiable in the
> blocks themselves.)
>
> PIB 1 with correlator x -> 0-25
> 25-50 -> PIB 1 with correlator x
> PIB 2 with correlator y -> 50-75
> 75-100 -> PIB 2 with correlator y
>
> PIB 3 with correlator x -> 0-25
> 25-50 -> PIB 3 with correlator x
> PIB 4 with correlator y -> 50-75
> 75-100 -> PIB 4 with correlator y
>
> The receiving node has no way to realize that that pre-payload PIB 1 with
> correlator x doesn't match up to the post-payload PIB 3 with correlator x.
>
> - Amy
>
> On Tue, Mar 19, 2013 at 9:11 PM, Peter Lovell <[e-mail]> wrote:
>
> Amy Alford <[e-mail]> wrote:
>
> >A bundle can be fragmented multiple times independently, so a node may
> >receive multiple fragments with the same offset and length that have
> >traveled different paths (and accumulated different BSP blocks along the
> >way).  Collisions in the correlator values once the bundle is reassembled
> >are inevitable.
> >- Amy
>
> Hi Amy,
>
> my thought is that we have covered the problem of multiple-fragmentation
> and multi-path, but perhaps not.
>
> Can you describe a bundle scenario that exemplifies the issue you see, so
> we can think about it.
>
> Thanks.....Peter
>
>
>
>