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

[Amy Alford <[e-mail]>]

A metadata block that tied the fragments together (and was unique to that
fragmentation event: perhaps EID and time) would help, as long as
reassembly is handled by the destination (so that it can take advantage of
this info).

- Amy

On Wed, Mar 20, 2013 at 8:56 PM, Elwyn Davies <[e-mail]> wrote:

> Hi, Amy.
>
> I grok the problem properly now (I hope).
>
> Does pushing a metadata block into the bundle with the EID (or if too
> long) a short nonce or abbreviated digest of some part of the bundle
> (e.g. some part of the PIB) into all the fragments at the node where it
> is fragmented help?
>
> Not a very satisfactory solution but it would help tie the two parts of
> the PIB together.
>
> /Elwyn
>
>
> On Wed, 2013-03-20 at 19:36 -0400, Amy Alford wrote:
> > 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
> >
> >
> > _______________________________________________
> > dtn-security mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/dtn-security
>
>