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

Amy Alford <aloomis@sarn.org> Thu, 21 March 2013 14:49 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 15B9321F8AB8 for <dtn-security@ietfa.amsl.com>; Thu, 21 Mar 2013 07:49:04 -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 p9EPSfUfDE7B for <dtn-security@ietfa.amsl.com>; Thu, 21 Mar 2013 07:49:03 -0700 (PDT)
Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id BCC8121F8AAC for <dtn-security@irtf.org>; Thu, 21 Mar 2013 07:49:02 -0700 (PDT)
Received: by mail-qa0-f41.google.com with SMTP id p6so311474qad.7 for <dtn-security@irtf.org>; Thu, 21 Mar 2013 07:49:02 -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=etxlkAD7/q4DDFPOE5+2mnykW4WyXrL4Hpzp7FdcdFw=; b=PyQu2xaSrn39UmQdegJVaq9xfd8ECQsBPj/gPJSMZZ0yC1Z9tFvr1G/ze4JJbHGOoz UwT25hAAG47IKEEDlVJ66eaAUUxA3NPJQjc28jfluYAhj52wfpElAISqDJcwiAKPH8K8 gTfWpSnf7UTRVkDDcTYsPobyK8wnyjYKqk9d27KZwD/7AruQ6hRRyj1+CKywJvqAtOIY uc1thygxIVViRbltuNI4kztjhRoLR3y30b3X16cNqm6DcgUMGBZvrFdnFJBiGxxu0Vad 1dnrHO+Wzhrvn6kYJJlqGeIZEhMHbsTCxzly97ht25OXpEFwH4+05rVlWHu3mxw+QZao uyQQ==
MIME-Version: 1.0
X-Received: by 10.49.25.84 with SMTP id a20mr11390697qeg.61.1363877342013; Thu, 21 Mar 2013 07:49:02 -0700 (PDT)
Received: by 10.49.81.199 with HTTP; Thu, 21 Mar 2013 07:49:01 -0700 (PDT)
In-Reply-To: <CAB9rx+8KVadQvmPMvtc_C=UszF=5PkKBq=-p=BgTy=nxFSaQdQ@mail.gmail.com>
References: <CAB9rx+85HHsNj=EhmsqhCdtY5k=S4p1Jgzz4VsmEC+43ERygWA@mail.gmail.com> <20130320011114.1072992195@smtp.mail.me.com> <CAB9rx+_G87R-ZtwBx14jX8YkmX__zjhhVXn8XesZztMaY0vZXg@mail.gmail.com> <1363827420.23866.3526.camel@mightyatom> <CAB9rx+8KVadQvmPMvtc_C=UszF=5PkKBq=-p=BgTy=nxFSaQdQ@mail.gmail.com>
Date: Thu, 21 Mar 2013 10:49:01 -0400
Message-ID: <CAB9rx+8iiniTKR_cVOZ_aMFJae+RZT0RKdubE6XeoXOtAdM=CQ@mail.gmail.com>
From: Amy Alford <aloomis@sarn.org>
To: Elwyn Davies <elwynd@folly.org.uk>
Content-Type: multipart/alternative; boundary=047d7b5dbce27d18ca04d87070cc
X-Gm-Message-State: ALoCoQnzoYXwLL9EJAipgHswSj1cz41f5qnAp0kmKvJyV9g6AuhwD8StJHi6LU5RfH5TA6ZxxxcB
Cc: dtn-security <dtn-security@irtf.org>
Subject: Re: [dtn-security] 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: Thu, 21 Mar 2013 14:49:04 -0000

To make reassembly somewhere other than the destination succeed, either
reassembling nodes need to be required to understand all the extension
blocks (so they can recombine them sensibly), or the reassembly process
needs to somehow preserve information about the fragment structure.  In the
latter case, reassembly seems useless anyway.  You're unlikely to save any
space over just forwarding the fragments.

On Wed, Mar 20, 2013 at 9:11 PM, Amy Alford <aloomis@sarn.org> wrote:

> 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 <elwynd@folly.org.uk> 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 <plovell@mac.com> wrote:
>> >         Amy Alford <aloomis@sarn.org> 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
>> > dtn-security@irtf.org
>> > https://www.irtf.org/mailman/listinfo/dtn-security
>>
>>
>