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

Amy Alford <> Mon, 25 March 2013 19:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B14921F942F for <>; Mon, 25 Mar 2013 12:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N-WXWjWoGM1U for <>; Mon, 25 Mar 2013 12:58:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F26EE21F88A1 for <>; Mon, 25 Mar 2013 12:58:33 -0700 (PDT)
Received: by with SMTP id bs12so1436910qab.11 for <>; Mon, 25 Mar 2013 12:58:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=NJYqAnrq6sOOukuwzGZxpCh4Wx91WQmdluaGC2VM/fc=; b=WeZV2QO+1k2BocmhMTrdeoiUkCEDvaer6YI953VyqwQz9RQtc3Ki+ni72ZAmpiVk20 /LKVoL8adSxUb5DvIQ330iQ/59WX14Bb6QiaePZo42YrX2UFPJfhoPRTQ93PWzC/TB9T XUOxxdM8UpIFJnCkM08+MC3WJbUPSrSC04Ckmt/kQxwnFERx/4aYchQC/MdOrLi60R5r tU5bCqkHNlvb2FaeanVzbJZF6CEUedPoRGqXaxmTslnxshYYyliXBmBXZ+phyF/DcbCw OkBo5c1SAKalDfHL+yzNqBw6BXDVGF7gAIQJPxshd8NzMBfemwHtDblQ1GUpCBQbVCco JLaA==
MIME-Version: 1.0
X-Received: by with SMTP id cy13mr3430989qab.53.1364241513298; Mon, 25 Mar 2013 12:58:33 -0700 (PDT)
Received: by with HTTP; Mon, 25 Mar 2013 12:58:33 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Mon, 25 Mar 2013 15:58:33 -0400
Message-ID: <>
From: Amy Alford <>
To: Peter Lovell <>
Content-Type: multipart/alternative; boundary=485b397dd3b5c9d53e04d8c53a61
X-Gm-Message-State: ALoCoQmFFjYHYWa3itCgn2QA0hxzBmO0/PRwhFHqWKOeZCBWRhT9VF373/yXXaFpwtWKpBS7dfzk
Cc: dtn-security <>
Subject: Re: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions.
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Mar 2013 19:58:35 -0000

On Sat, Mar 23, 2013 at 5:32 PM, Peter Lovell <> wrote:

> Hi Amy,
> Amy Alford <> 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