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

Amy Alford <aloomis@sarn.org> Sat, 13 April 2013 22:12 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 BE6A921F851C for <dtn-security@ietfa.amsl.com>; Sat, 13 Apr 2013 15:12:40 -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 FoffX64WUkCa for <dtn-security@ietfa.amsl.com>; Sat, 13 Apr 2013 15:12:39 -0700 (PDT)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCC221F84F5 for <dtn-security@irtf.org>; Sat, 13 Apr 2013 15:12:39 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id bv4so330356qab.1 for <dtn-security@irtf.org>; Sat, 13 Apr 2013 15:12:38 -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=J4wEMvSbvvBITMcdGle1E7eeW/7QdTFOuSzL8t4CelU=; b=b9HSfmJEISVCCptbtBKRH3E0yKM0w4vFcfmOw57ji4mtN0QekLBd25qX6xj1QvHm4l NpFFyDgVumEe9WDZeleT/QABFVEqUaucF5u7pt+kkFpJKAqA66AUv1m5kl1xJxWA9yRa UZ/lRiULP6BRhJswKkcdhMKbtPklZqGGDuAvUkwOzFCFLvohGSXwy9xpuNXat3wHhZoE o1fIayL7HDnq7b/IZIv2kIAXYmtPhi1N2Va4xNGPsm68ch05lVAz/y9hxxy3DfWnJDda AwxhzGn5I1yOoYMJ3EjMU7puEf4eayni+b0QqQ6XwKBAZxtxIqT7fP1zyZESvtdsHDU0 5QqQ==
MIME-Version: 1.0
X-Received: by 10.49.106.40 with SMTP id gr8mr18132803qeb.42.1365891158581; Sat, 13 Apr 2013 15:12:38 -0700 (PDT)
Received: by 10.49.76.71 with HTTP; Sat, 13 Apr 2013 15:12:38 -0700 (PDT)
In-Reply-To: <1365876632.5273.8820.camel@mightyatom>
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> <CAB9rx+-5yowPPSHfmME8Mhu5Y1B6hzVOPyRk3qpsZ200A=n6WA@mail.gmail.com> <1365876632.5273.8820.camel@mightyatom>
Date: Sat, 13 Apr 2013 18:12:38 -0400
Message-ID: <CAB9rx+-3H6coewGAL8w4H6eJ4-R91DUZ-y3tjPOqewW-R2JF=A@mail.gmail.com>
From: Amy Alford <aloomis@sarn.org>
To: Elwyn Davies <elwynd@folly.org.uk>
Content-Type: multipart/alternative; boundary="047d7b675db04f35ba04da4551ab"
X-Gm-Message-State: ALoCoQkUW4z5+nb9noeywlha7rxOI/hLbclNo9VprU/1jt9lyPs8/041v87rGSVRfMRGP+G5FiSx
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: Sat, 13 Apr 2013 22:12:40 -0000

If you think about a "fragmentation path" similar to a security path,
whenever fragmentation paths and security paths overlap (instead of one
nesting inside the other), Bad Things (TM) are probably going to happen in
DTN2.

If it's fragment -> add bsp -> defragment -> remove bsp, you're up against
the fact that defragmentation doesn't necessarily preserve enough info to
validate the BSP blocks.  Even if it does, DTN2 currently doesn't recognize
that a set of valid BSP blocks that cover the payload are enough to satisfy
policy requirements.

If it's add bsp -> fragment -> remove bsp -> defragment, you're obviously
sunk because you can't validate the BSP blocks which apply to the whole
payload when you only have a fragment.  In this case, you obviously need to
reconstitute the bundle before you remove the BSP blocks.

This doesn't even touch the headaches involved with multiple BSP instances
and multiple fragmentation.

BiB will need to deal with the second case (the easy one - DTN2 will
probably handle this with no changes), but avoids the first case because an
encapsulated fragment is not itself a fragment (so it can't be
reconstituted until after it's been decapsulated).

The new BSP draft may not sidestep these problems though, because it still
allows security sources and hop-by-hop ciphersuites still need to be able
to handle non-security-aware nodes in the middle.




On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies <elwynd@folly.org.uk> wrote:

> Hi.
>
> It just occurred to me that the way DTN2 handles fragment payloads
> probably gets very screwed up if two paths either with different
> encrypted security tunnels or with one encrypted and one unencrypted
> converge at some point after fragmentation.  I haven't looked in detail
> into the code, but I suspect that there are some cases in which order
> of delivery via the two different paths might lead to  the payload
> getting a mix of data from the two sources and becoming unintelligible.
>
> Not certaim if I am right, but may be another argument for using b-i-b
> encapsulation.
>
> Regards,
> Elwyn
>
> On Mon, 2013-03-25 at 15:58 -0400, Amy Alford wrote:
> >
> >
> > 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
> >
> >
> > _______________________________________________
> > dtn-security mailing list
> > dtn-security@irtf.org
> > https://www.irtf.org/mailman/listinfo/dtn-security
>
>