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:43 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 C613521F90B4 for <dtn-security@ietfa.amsl.com>; Thu, 21 Mar 2013 07:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 De4u4YC1-pwS for <dtn-security@ietfa.amsl.com>; Thu, 21 Mar 2013 07:43:32 -0700 (PDT)
Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE7E21F90CA for <dtn-security@irtf.org>; Thu, 21 Mar 2013 07:43:30 -0700 (PDT)
Received: by mail-qc0-f181.google.com with SMTP id a22so1452876qcs.12 for <dtn-security@irtf.org>; Thu, 21 Mar 2013 07:43:30 -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=q5u6SCfD9GELV1kYxMrhdiUJmuBYkT3+LuzE0sgvwf0=; b=kCnHG2TNXMka4pTrbrJ0+F9eLMyja0UKfLiIjNqxG8TMHNtwrv/SveqVtnGrtGSVNA HeTjXeXxGuCOaVNSju1YmX9DPYnGX/MC9zhcuxoeV8pjcosHMUKJv07kjQrneM39W1Fr r4lUSAhJT9TApKvzYmNc6sv3sXS5OmDb5VS2fGO54mDsGEiDQO8mYrv76j5hOB+hSFk/ 370XvE/ybPFhF5Z6Lq2qSwArNc03rCQOT6lQv4qncgPtYhpQcQvHl+R0cP9n4bAgSFMo AipZDH0AcGXuz/0ptR83zu0At7tGOMgpmeRnTVBQih/lm0TovLgmD78pbezdK0eYvoZu l0hA==
MIME-Version: 1.0
X-Received: by 10.49.87.40 with SMTP id u8mr11265751qez.62.1363877010295; Thu, 21 Mar 2013 07:43:30 -0700 (PDT)
Received: by 10.49.81.199 with HTTP; Thu, 21 Mar 2013 07:43:30 -0700 (PDT)
In-Reply-To: <CD7002AE.120A7%william.d.ivancic@nasa.gov>
References: <CAB9rx+_G87R-ZtwBx14jX8YkmX__zjhhVXn8XesZztMaY0vZXg@mail.gmail.com> <CD7002AE.120A7%william.d.ivancic@nasa.gov>
Date: Thu, 21 Mar 2013 10:43:30 -0400
Message-ID: <CAB9rx+9F0NHwP74Uu42rcvwUjtqjhHb6ueAXZJD=01+67W1Q6w@mail.gmail.com>
From: Amy Alford <aloomis@sarn.org>
To: "Ivancic, William D. (GRC-RHN0)" <william.d.ivancic@nasa.gov>
Content-Type: multipart/alternative; boundary=047d7bdc8b0ab77b5004d8705c6c
X-Gm-Message-State: ALoCoQlBNwsjhcR2J5wnGW5wHXXRMaSsQQ6FKz1O2yt6gG5tWc6tnS04Z4SMvpmS51rb+/DCjidE
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:43:33 -0000

Isn't this fixable by defining a PIB ciphersuite that only protects the
primary block?
- Amy

On Thu, Mar 21, 2013 at 12:19 AM, Ivancic, William D. (GRC-RHN0) <
william.d.ivancic@nasa.gov> wrote:

>  A 5 GB bundle come forms Mr. Bad.  You don’t want to store anything from
> Mr. Bad, but you cannot confirm the source  using PIB until you receive the
> entire bundle thus eating up 5 GB of resources.
>
> It is broken.
>
> -- Will
>
>
> ------------------------------
> *From: *Amy Alford <aloomis@sarn.org>
> *Date: *Wed, 20 Mar 2013 18:36:32 -0500
> *To: *Peter Lovell <plovell@mac.com>
> *Cc: *dtn-security <dtn-security@irtf.org>
>
> *Subject: *Re: [dtn-security] Including fragment offset in the correlator
> doesn't prevent all fragment collisions.
>
> 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
>
>
>
>