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

Amy Alford <aloomis@sarn.org> Mon, 25 March 2013 19:58 UTC

Return-Path: <aloomis@sarn.org>
X-Original-To: dtn-security@ietfa.amsl.com
Delivered-To: dtn-security@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B14921F942F for <dtn-security@ietfa.amsl.com>; Mon, 25 Mar 2013 12:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-WXWjWoGM1U for <dtn-security@ietfa.amsl.com>; Mon, 25 Mar 2013 12:58:34 -0700 (PDT)
Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id F26EE21F88A1 for <dtn-security@irtf.org>; Mon, 25 Mar 2013 12:58:33 -0700 (PDT)
Received: by mail-qa0-f52.google.com with SMTP id bs12so1436910qab.11 for <dtn-security@irtf.org>; Mon, 25 Mar 2013 12:58:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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 10.224.188.13 with SMTP id cy13mr3430989qab.53.1364241513298; Mon, 25 Mar 2013 12:58:33 -0700 (PDT)
Received: by 10.49.81.199 with HTTP; Mon, 25 Mar 2013 12:58:33 -0700 (PDT)
In-Reply-To: <20130323213252.461319491@smtp.mail.me.com>
References: <CAB9rx+85HHsNj=EhmsqhCdtY5k=S4p1Jgzz4VsmEC+43ERygWA@mail.gmail.com> <20130320011114.1072992195@smtp.mail.me.com> <CAB9rx+_EK7u8kkDhscBdqnGHYSeoROTSfhNaALZUodMt4em=_Q@mail.gmail.com> <20130323005838.947157858@smtp.mail.me.com> <CAB9rx+-kKNEUH0VWA_ffrcHfh59eSAxbgHNXWhkm+BrC44rqWw@mail.gmail.com> <20130323213252.461319491@smtp.mail.me.com>
Date: Mon, 25 Mar 2013 15:58:33 -0400
Message-ID: <CAB9rx+-5yowPPSHfmME8Mhu5Y1B6hzVOPyRk3qpsZ200A=n6WA@mail.gmail.com>
From: Amy Alford <aloomis@sarn.org>
To: Peter Lovell <plovell@mac.com>
Content-Type: multipart/alternative; boundary=485b397dd3b5c9d53e04d8c53a61
X-Gm-Message-State: ALoCoQmFFjYHYWa3itCgn2QA0hxzBmO0/PRwhFHqWKOeZCBWRhT9VF373/yXXaFpwtWKpBS7dfzk
Cc: dtn-security <dtn-security@irtf.org>
Subject: Re: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions.
X-BeenThere: dtn-security@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." <dtn-security.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-security>
List-Post: <mailto:dtn-security@irtf.org>
List-Help: <mailto:dtn-security-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2013 19:58:35 -0000

On Sat, Mar 23, 2013 at 5:32 PM, Peter Lovell <plovell@mac.com> wrote:

> Hi Amy,
>
> Amy Alford <aloomis@sarn.org> 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
>
>