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

[Amy Alford <[e-mail]>]

On Sat, Mar 23, 2013 at 5:32 PM, Peter Lovell <[e-mail]> wrote:

> Hi Amy,
>
> Amy Alford <[e-mail]> wrote:
>
> >Yes, my example was assuming a PIB ciphersuite that used two blocks
> >(similar to BAB).  That case is the most problematic, because when the
> >bundle is fragmented, the two blocks will end up in separate fragments.
> > Otherwise, the correlator collision isn't a problem as long as reassembly
> >happens at the destination.
>
> PIB is, in some ways, a more difficult scenario than PCB. When a bundle
> with PCB arrives at the security-dest, the payload is decrypted (and other
> blocks as appropriate) and the PCB itself is deleted. But some folks want
> to have PIBs remain even after verification, as evidence I guess. That is
> messy.
>
Leaving PIBs on after verification is problematic anyway, if the PIB was
added after a PCB.  Once the PCB reaches it's security destination, the PIB
is invalid anyhow.


>
> Is there a specific reason for a two-block PIB?
>

6257 mentions the idea of PIB ciphersuites that use a trailing block
similar to BAB.  I assume you'd still want an up front block to warn nodes
that are doing one pass processing that they need to start hashing.


>
> >> As you can see, this is a quite involved process. A couple of things are
> >> worthy of note:
> >> 1. correlators are local to their bundle
> >> 2. a block with a correlator may be encapsulated, with PCB for example.
> >> The original correlator is hidden until decapsulation occurs (not shown
> >> above for sake of brevity :)
> >> 3. reassembly is a very, very complex process.
> >>
> >I was pondering how to support these sorts of cases (which end up needing
> >validation and reassembly interleaved somehow).  In thinking about it, I
> >started running into scenarios that aren't supportable.  The example I
> gave
> >is one (which I think shows that bundles with two block PIBs need to have
> >the do not fragment flag set).
> It may be sufficient to apply the replicate-key-info-in-every-block rule.
> I don't know without thinking about it some more.
>

I think it would fix the example I gave.  The last fragment would contain
both the leading and trailing PIB blocks.  The leading block could be used
to match this up with the corresponding fragment (which also has a leading
PIB block but is missing the trailing one).  It would be a pain in terms of
processing, since defragmentation would need to match up the corresponding
fragments by comparing their leading PIB blocks.



>
> >Additionally, in general, if an intermediate node reassembles fragments
> >that have had BSP blocks added after fragmentation, we can't validate.
>  Too
> >much information is lost on reassembly (even if it's done sensibly).  5050
> >allows intermediate nodes to reassemble, but doesn't mandate a procedure
> >for reassembling the extension blocks (so it may not be done sensibly).
>
> It's not just an issue of reassembling/reordering extension blocks. As the
> final example shows, any attempt to reassemble-first is doomed to failure
> because the two parts were encrypted under different second-stage keys.


> It's clear to me that reassembly of bundles containing security blocks
> must be done in concert with security processing. This needs to be
> incorporated into any update to 5050. And, as you say, there are cases that
> aren't supportable with the capabilities we now have.
>

Yes.  In general, nodes shouldn't reassemble a bundle if they don't
understand all the extension blocks.  BSP aware nodes shouldn't reassemble
fragments except in concert with security processing.



>
> Regards.....Peter
>
>