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

PIB 3 with correlator x -> 0-25

25-50 -> PIB 3 wit= h correlator x

PIB 4 with correlator y -> 50-75

75-100 -> PIB 4 with = correlator y

The receiving node has no way to real= ize that that pre-payload PIB 1 with correlator x doesn't match up to t= he post-payload PIB 3 with correlator x.

- Amy

On Tue, Mar 1= 9, 2013 at 9:11 PM, Peter Lovell <plovell@mac.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Amy Alford <aloomis@sarn.org> wrote:

>A bundle can be fragmented multiple times independently, so a node may<= br> >receive multiple fragments with the same offset and length that have >traveled different paths (and accumulated different BSP blocks along th= e
>way). =A0Collisions in the correlator values once the bundle is reassem= bled
>are inevitable.
>- Amy

Hi Amy,

my thought is that we have covered the problem of multiple-fragmentation an= d multi-path, but perhaps not.

Can you describe a bundle scenario that exemplifies the issue you see, so w= e can think about it.

Thanks.....Peter

--002354471a502cb17404d863b110-- From elwynd@folly.org.uk Wed Mar 20 18:00:07 2013 Return-Path: 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 7976611E8117 for ; Wed, 20 Mar 2013 18:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 fJ3TnGnHJOtA for ; Wed, 20 Mar 2013 18:00:06 -0700 (PDT) Received: from a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by ietfa.amsl.com (Postfix) with ESMTP id 8888E11E810D for ; Wed, 20 Mar 2013 18:00:06 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtp (Exim 4.77) (envelope-from ) id 1UITrQ-0002ji-Rb; Thu, 21 Mar 2013 01:00:04 +0000 From: Elwyn Davies To: Amy Alford In-Reply-To: References: <20130320011114.1072992195@smtp.mail.me.com> Content-Type: text/plain Organization: Folly Consulting Date: Thu, 21 Mar 2013 00:56:59 +0000 Message-Id: <1363827420.23866.3526.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: dtn-security 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 01:00:07 -0000 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 wrote: > Amy Alford 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 From aloomis@sarn.org Wed Mar 20 18:12:14 2013 Return-Path: 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 5FB2211E8117 for ; Wed, 20 Mar 2013 18:12:12 -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=[AWL=-0.000, 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 9oj-lsMLDCPu for ; Wed, 20 Mar 2013 18:12:10 -0700 (PDT) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id C20FF11E80FD for ; Wed, 20 Mar 2013 18:11:52 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id 7so1533999qeb.0 for ; Wed, 20 Mar 2013 18:11:51 -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=kBzZCKvA4GWkvDjuhNAPp1CCFFmfn1RD/7jFMiIXulI=; b=Qu8YS9LoM6mF5EddMAU3tDNcUB4xeJuJfEnEQN/eeIFwo/J+rXXXR8+jqn2y2Ljyuq YgBzulFiijb4Q+3fiX2lSGqIU8hKKAP3KL9tO7CsSfwalu65UjVdH83ecmknbTguYcDT V51hQmYEepQzlMapcDLkitjsqnQ0Fw0DR3SNmhm/1IV+hdl1JGOmQg5FXC1xj0ChGVsh ti2VBJ4EdZy1XkF14sDrHF4wgVj5aOdzbB9eGz8jdsU4rH58VQUerPH2Rxk8JMtVJx4x cJeluFBMSg54JlQ1V6VCFUJBZZbXL/vUpvcPA2f8lL65BzTqXZEd/UIsa72BwppFdt53 nknQ== MIME-Version: 1.0 X-Received: by 10.224.188.13 with SMTP id cy13mr7977074qab.53.1363828311620; Wed, 20 Mar 2013 18:11:51 -0700 (PDT) Received: by 10.49.81.199 with HTTP; Wed, 20 Mar 2013 18:11:51 -0700 (PDT) In-Reply-To: <1363827420.23866.3526.camel@mightyatom> References: <20130320011114.1072992195@smtp.mail.me.com> <1363827420.23866.3526.camel@mightyatom> Date: Wed, 20 Mar 2013 21:11:51 -0400 Message-ID: From: Amy Alford To: Elwyn Davies Content-Type: multipart/alternative; boundary=485b397dd3b50cb2a704d8650623 X-Gm-Message-State: ALoCoQm+XFyk/yk1TTXuut3iYmqj6hI1B7ziBiBSFW9qRrTb0KSnxOtoHS9A5f2KHykb/YuBk9oz Cc: dtn-security 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 01:12:14 -0000 --485b397dd3b50cb2a704d8650623 Content-Type: text/plain; charset=ISO-8859-1 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 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 wrote: > > Amy Alford 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 > > --485b397dd3b50cb2a704d8650623 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A metadata block that tied the fragments together (and was unique to that f= ragmentation 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)= .=A0

- Amy

On Wed, Mar 2= 0, 2013 at 8:56 PM, Elwyn Davies <elwynd@folly.org.uk> wro= te:

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. =A0Different nodes independently fragmen= t
> it into 50 byte fragments. =A0A subsequent node adds PIB and PCB (so w= e
> have correlated PCB blocks) to each fragment with a security
> destination of the bundle destination. =A0 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. =A0It's independently fragmented= into
> 50 byte bundles. =A0A subsequent node adds a PIB ciphersuite with a > correlated block trailing the payload. =A0Again, the correlators
> collide. =A0Now, each 50 byte fragment is fragmented again. =A0So, we = have
> fragments:
>
>
> (I'm numbering the PIB instances so that we can distinguish them i= n
> the discussion. =A0The numbers don't correspond to anything identi= fiable
> 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<= br> > correlator x.
>
>
> - Amy
>
> On Tue, Mar 19, 2013 at 9:11 PM, Peter Lovell <plovell@mac.com> wrote:
> =A0 =A0 =A0 =A0 Amy Alford <alo= omis@sarn.org> wrote:
>
> =A0 =A0 =A0 =A0 >A bundle can be fragmented multiple times independ= ently, so a
> =A0 =A0 =A0 =A0 node may
> =A0 =A0 =A0 =A0 >receive multiple fragments with the same offset an= d length
> =A0 =A0 =A0 =A0 that have
> =A0 =A0 =A0 =A0 >traveled different paths (and accumulated differen= t BSP
> =A0 =A0 =A0 =A0 blocks along the
> =A0 =A0 =A0 =A0 >way). =A0Collisions in the correlator values once = the bundle is
> =A0 =A0 =A0 =A0 reassembled
> =A0 =A0 =A0 =A0 >are inevitable.
> =A0 =A0 =A0 =A0 >- Amy
>
>
> =A0 =A0 =A0 =A0 Hi Amy,
>
> =A0 =A0 =A0 =A0 my thought is that we have covered the problem of
> =A0 =A0 =A0 =A0 multiple-fragmentation and multi-path, but perhaps not= .
>
> =A0 =A0 =A0 =A0 Can you describe a bundle scenario that exemplifies th= e issue
> =A0 =A0 =A0 =A0 you see, so we can think about it.
>
> =A0 =A0 =A0 =A0 Thanks.....Peter
>
>

> __________________= _____________________________
> dtn-security mailing list
> dtn-security@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-security

--485b397dd3b50cb2a704d8650623-- From william.d.ivancic@nasa.gov Wed Mar 20 21:19:35 2013 Return-Path: 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 3CB4711E80EE for ; Wed, 20 Mar 2013 21:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=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 iA+MFDFvZ20P for ; Wed, 20 Mar 2013 21:19:33 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (NDJSNPF03.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id 4E02B11E80BA for ; Wed, 20 Mar 2013 21:19:29 -0700 (PDT) Received: from ndjsppt103.ndc.nasa.gov (NDJSPPT103.ndc.nasa.gov [198.117.1.197]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 07C6A2D8205; Wed, 20 Mar 2013 23:19:29 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt103.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r2L4JSpi017238; Wed, 20 Mar 2013 23:19:28 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Wed, 20 Mar 2013 23:19:28 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Amy Alford , Peter Lovell Date: Wed, 20 Mar 2013 23:19:58 -0500 Thread-Topic: [dtn-security] Including fragment offset in the correlator doesn't prevent all fragment collisions. Thread-Index: Ac4lw8UUioJBUzfWRem5xtXjA/y+qQAJ5Pdk Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD7002AE120A7williamdivancicnasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-20_12:2013-03-20, 2013-03-20, 1970-01-01 signatures=0 Cc: dtn-security 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 04:19:35 -0000 --_000_CD7002AE120A7williamdivancicnasagov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A 5 GB bundle come forms Mr. Bad. You don=92t 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 Date: Wed, 20 Mar 2013 18:36:32 -0500 To: Peter Lovell Cc: dtn-security Subject: Re: [dtn-security] Including fragment offset in the correlator doe= sn't prevent all fragment collisions. A 100 byte bundle is created. Different nodes independently fragment it in= to 50 byte fragments. A subsequent node adds PIB and PCB (so we have corre= lated PCB blocks) to each fragment with a security destination of the bundl= e destination. The correlators can collide. (In DTN2, they will collide.) If the fragments are reassembled before the destination, the destination ha= s no way to distinguish the PCB blocks that should correlate with each othe= r. Alternatively, if we assume reassembly only happens at the destination (whi= ch 5050 doesn't guarantee), we still have a problem if we use a two block P= IB 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 by= te bundles. A subsequent node adds a PIB ciphersuite with a correlated blo= ck trailing the payload. Again, the correlators collide. Now, each 50 byt= e fragment is fragmented again. So, we have fragments: (I'm numbering the PIB instances so that we can distinguish them in the dis= cussion. The numbers don't correspond to anything identifiable in the bloc= ks 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 c= orrelator 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 wrote: Amy Alford 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 an= d multi-path, but perhaps not. Can you describe a bundle scenario that exemplifies the issue you see, so w= e can think about it. Thanks.....Peter --_000_CD7002AE120A7williamdivancicnasagov_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Re: [dtn-security] Including fragment offset in the correlator = doesn't prevent all fragment collisions. A 5 GB bundle c= ome forms Mr. Bad. You don=92t want to store anything from Mr. Bad, b= ut you cannot confirm the source using PIB until you receive the enti= re bundle thus eating up 5 GB of resources.

It is broken.

-- Will

From: Amy Alford <<= a href=3D"aloomis@sarn.org">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 correla= tor 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 ha= s no way to distinguish the PCB blocks that should correlate with each othe= r.

Alternatively, if we assume reassembly only happens at the destination (whi= ch 5050 doesn't guarantee), we still have a problem if we use a two block P= IB 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 corr= elated block trailing the payload. Again, the correlators collide. &n= bsp;Now, each 50 byte fragment is fragmented again. So, we have fragm= ents:

(I'm numbering the PIB instances so that we can distinguish them in the dis= cussion. 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 c= orrelator 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<= br> >receive multiple fragments with the same offset and length that have >traveled different paths (and accumulated different BSP blocks along th= e
>way). Collisions in the correlator values once the bundle is reas= sembled
>are inevitable.
>- Amy

Hi Amy,

my thought is that we have covered the problem of multiple-fragmentation an= d multi-path, but perhaps not.

Can you describe a bundle scenario that exemplifies the issue you see, so w= e can think about it.

Thanks.....Peter

--_000_CD7002AE120A7williamdivancicnasagov_-- From aloomis@sarn.org Thu Mar 21 07:43:33 2013 Return-Path: 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 ; 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 ; 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 ; Thu, 21 Mar 2013 07:43:30 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id a22so1452876qcs.12 for ; 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: References: Date: Thu, 21 Mar 2013 10:43:30 -0400 Message-ID: From: Amy Alford To: "Ivancic, William D. (GRC-RHN0)" Content-Type: multipart/alternative; boundary=047d7bdc8b0ab77b5004d8705c6c X-Gm-Message-State: ALoCoQlBNwsjhcR2J5wnGW5wHXXRMaSsQQ6FKz1O2yt6gG5tWc6tnS04Z4SMvpmS51rb+/DCjidE Cc: dtn-security 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:43:33 -0000 --047d7bdc8b0ab77b5004d8705c6c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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=92t want to store anything fr= om > Mr. Bad, but you cannot confirm the source using PIB until you receive t= he > entire bundle thus eating up 5 GB of resources. > > It is broken. > > -- Will > > > ------------------------------ > *From: *Amy Alford > *Date: *Wed, 20 Mar 2013 18:36:32 -0500 > *To: *Peter Lovell > *Cc: *dtn-security > > *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 th= e > 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 5= 0 > 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 wrote: > > Amy Alford 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 reassemble= d > >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 > > > > --047d7bdc8b0ab77b5004d8705c6c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Isn't this fixable by defining a PIB ciphersuite that only protects the= primary block?=A0

- Amy

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

A 5 GB bundle c= ome forms Mr. Bad. =A0You don=92t want to store anything from Mr. Bad, but = you cannot confirm the source =A0using PIB until you receive the entire bun= dle thus eating up 5 GB of resources.

It is broken.

-- Will

From: Amy Alford <<= a href=3D"http://aloomis@sarn.org" target=3D"_blank">aloomis@sarn.org&g= t;
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 correla= tor doesn't prevent all fragment collisions.

A 100 byte bundle is created. =A0Different nodes independently fragment it = into 50 byte fragments. =A0A subsequent node adds PIB and PCB (so we have c= orrelated PCB blocks) to each fragment with a security destination of the b= undle destination. =A0 The correlators can collide. (In DTN2, they will col= lide.) =A0 =A0=A0

If the fragments are reassembled before the destination, the destination ha= s no way to distinguish the PCB blocks that should correlate with each othe= r.

Alternatively, if we assume reassembly only happens at the destination (whi= ch 5050 doesn't guarantee), we still have a problem if we use a two blo= ck PIB ciphersuite where one block comes before the payload and one comes a= fter. =A0

A node creates a 100 byte bundle. =A0It's independently fragmented into= 50 byte bundles. =A0A subsequent node adds a PIB ciphersuite with a correl= ated block trailing the payload. =A0Again, the correlators collide. =A0Now,= each 50 byte fragment is fragmented again. =A0So, we have fragments:

(I'm numbering the PIB instances so that we can distinguish them in the= discussion. =A0The numbers don't correspond to anything identifiable i= n 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 c= orrelator 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<= br> >receive multiple fragments with the same offset and length that have >traveled different paths (and accumulated different BSP blocks along th= e
>way). =A0Collisions in the correlator values once the bundle is reassem= bled
>are inevitable.
>- Amy

Hi Amy,

my thought is that we have covered the problem of multiple-fragmentation an= d multi-path, but perhaps not.

Can you describe a bundle scenario that exemplifies the issue you see, so w= e can think about it.

Thanks.....Peter

--047d7bdc8b0ab77b5004d8705c6c-- From aloomis@sarn.org Thu Mar 21 07:49:04 2013 Return-Path: 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 ; 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 ; 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 ; Thu, 21 Mar 2013 07:49:02 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id p6so311474qad.7 for ; 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: References: <20130320011114.1072992195@smtp.mail.me.com> <1363827420.23866.3526.camel@mightyatom> Date: Thu, 21 Mar 2013 10:49:01 -0400 Message-ID: From: Amy Alford To: Elwyn Davies Content-Type: multipart/alternative; boundary=047d7b5dbce27d18ca04d87070cc X-Gm-Message-State: ALoCoQnzoYXwLL9EJAipgHswSj1cz41f5qnAp0kmKvJyV9g6AuhwD8StJHi6LU5RfH5TA6ZxxxcB Cc: dtn-security 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:49:04 -0000 --047d7b5dbce27d18ca04d87070cc Content-Type: text/plain; charset=ISO-8859-1 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 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 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 wrote: >> > Amy Alford 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 >> >> > --047d7b5dbce27d18ca04d87070cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To make reassembly somewhere other than the destination succeed, either rea= ssembling nodes need to be required to understand all the extension blocks = (so they can recombine them sensibly), or the reassembly process needs to s= omehow preserve information about the fragment structure. =A0In the latter = case, reassembly seems useless anyway. =A0You're unlikely to save any s= pace over just forwarding the fragments. =A0

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 f= ragmentation 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)= .=A0

- Amy

On Wed, Mar 20, 2013 at 8:56 PM, E= lwyn 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. =A0Different nodes independently fragmen= t
> it into 50 byte fragments. =A0A subsequent node adds PIB and PCB (so w= e
> have correlated PCB blocks) to each fragment with a security
> destination of the bundle destination. =A0 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. =A0It's independently fragmented= into
> 50 byte bundles. =A0A subsequent node adds a PIB ciphersuite with a > correlated block trailing the payload. =A0Again, the correlators
> collide. =A0Now, each 50 byte fragment is fragmented again. =A0So, we = have
> fragments:
>
>
> (I'm numbering the PIB instances so that we can distinguish them i= n
> the discussion. =A0The numbers don't correspond to anything identi= fiable
> 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<= br> > correlator x.
>
>
> - Amy
>
> On Tue, Mar 19, 2013 at 9:11 PM, Peter Lovell <plovell@mac.com> wrote:
> =A0 =A0 =A0 =A0 Amy Alford <aloomis@sarn.org> wrote:
>
> =A0 =A0 =A0 =A0 >A bundle can be fragmented multiple times independ= ently, so a
> =A0 =A0 =A0 =A0 node may
> =A0 =A0 =A0 =A0 >receive multiple fragments with the same offset an= d length
> =A0 =A0 =A0 =A0 that have
> =A0 =A0 =A0 =A0 >traveled different paths (and accumulated differen= t BSP
> =A0 =A0 =A0 =A0 blocks along the
> =A0 =A0 =A0 =A0 >way). =A0Collisions in the correlator values once = the bundle is
> =A0 =A0 =A0 =A0 reassembled
> =A0 =A0 =A0 =A0 >are inevitable.
> =A0 =A0 =A0 =A0 >- Amy
>
>
> =A0 =A0 =A0 =A0 Hi Amy,
>
> =A0 =A0 =A0 =A0 my thought is that we have covered the problem of
> =A0 =A0 =A0 =A0 multiple-fragmentation and multi-path, but perhaps not= .
>
> =A0 =A0 =A0 =A0 Can you describe a bundle scenario that exemplifies th= e issue
> =A0 =A0 =A0 =A0 you see, so we can think about it.
>
> =A0 =A0 =A0 =A0 Thanks.....Peter
>
>

> _______________________________________________<= br> > dtn-security mailing list
> dtn-securit= y@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-security

--047d7b5dbce27d18ca04d87070cc-- From plovell@mac.com Fri Mar 22 17:58:41 2013 Return-Path: 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 EF48721F8FE8 for ; Fri, 22 Mar 2013 17:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 8ZwGEs7Chgod for ; Fri, 22 Mar 2013 17:58:40 -0700 (PDT) Received: from st11p00mm-asmtp003.mac.com (st11p00mm-asmtpout003.mac.com [17.172.81.2]) by ietfa.amsl.com (Postfix) with ESMTP id E6DBE21F8E84 for ; Fri, 22 Mar 2013 17:58:39 -0700 (PDT) Received: from [192.168.1.97] (pool-96-241-42-32.washdc.fios.verizon.net [96.241.42.32]) by st11p00mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0MK300I3N9DPNJ70@st11p00mm-asmtp003.mac.com> for dtn-security@irtf.org; Sat, 23 Mar 2013 00:58:38 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-03-22_06:2013-03-22, 2013-03-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1302030000 definitions=main-1303220244 From: Peter Lovell To: Amy Alford , dtn-security Date: Fri, 22 Mar 2013 20:58:38 -0400 Message-id: <20130323005838.947157858@smtp.mail.me.com> In-reply-to: References: <20130320011114.1072992195@smtp.mail.me.com> X-Mailer: CTM PowerMail version 6.1.5b1 build 4653 English (intel) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Subject: [dtn-security] Re(2): 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 00:58:42 -0000 Hi Amy, thanks for your example. One thing I discovered in looking at the 2.9 code is that there's a bug, = and fixing that would help things. In Ciphersuite::create=5Fcorrelator( ) [file = ~/dtn-2.9.0/servlib/security/Ciphersuite.cc] we intend to make the new correlator bigger than any existing = one. But we don't quite do that. Line 480 reads result |=3D high=5Fval; // put high=5Fval into low-order two bytes and that should be result |=3D high=5Fval + 1; // put high=5Fval into low-order two = bytes =46or the following discussion, let's assume that change. The correlator is a triple, comprising the fragment-offset, ciphersuite = number, and sequence number. The sequence number allows us to differentiate = between separate applications of the same ciphersuite, such as signing with both = an old and a new key (one may debate the wisdom of such cryptographic usage, = but that's a different discussion). One important item to remember is that a = correlator is only present if there are two or more related blocks in a = bundle. If there are multiple security blocks but they're unrelated then they = don't have correlators. Looking at your second example, four bundles eventually arrive at the = destination (assuming destination-reassembly, for the moment). For the sake of = discussion, let's hypothetically have the PI ciphersuite number be 7 using = trailing block. Bundle A data 0 - 24 Bundle B data 50 - 74 Bundle C data 25 - 49 PIB with range 0-49 Bundle D data 75 - 99 PIB with range 50 - 99 When the two 50-blocks are split into four 25-blocks, the PIBs are = replicated into the second block in each case because the PIBs trailed the payload = (see 5050 sec. 5.8). Each of the PI operations resulted in a single PI block = so there is no correlator needed (in fact, it's prohibited). So let's create a more problematic scenario with the hundred-byte message. = The first node it encounters has known 60-byte limits for onforwarding so we = get one 60- and one 40-byte bundle. The outbound policy requires PI so both = fragments will have a trailing PIB without a correlator. The two bundles are = sent on their way, but the node is unsure whether the first was properly = received (let's say that the CL ACK was lost) so it sends the first one again on = a different link. Whatever the mechanism, we now have two copies of this = bundle A (bytes 0 - 59) in flight via two separate nodes. At this second stage, one node has a 40-byte outgoing limit so fragments = bundle A into 40- and 20-byte fragments, with the PIB in the second fragment. = Per this node's policy, it applies PC3 to both outgoing bundles Aa and Ab and = sends them on. These contents are ... Bundle Aa PCBa with range 0 - 39 encrypted data 0 - 39 Bundle Ab PCBb with range 40 - 59, correlator 40 - 3 - 1 encrypted data 40 - 59 encrypted PIB, with correlator 40 - 3 - 1 The other node, quite unaware that the bundle exists elsewhere, processes = it too. By perverse chance, its outgoing links also have 40-byte limits, so = the outgoing stream is ... Bundle Ac PCBc with range 0 - 39 encrypted data 0 - 39 Bundle Ad PCBd with range 40 - 59, correlator 40 - 3 - 1 encrypted data 40 - 59 encrypted PIB, with correlator 40 - 3 - 1 I wonder if any DTN code today will nicely handle this case but it's quite = possible. The decryption is contained within each bundle and is not complex. ------------------ A more difficult setup is to change the PI above to PC3. We have two = copies of bundle A at separate nodes, unaware of one another. Each has the PC3 = block containing the parameters etc for the encryption of bytes 0-59 of the = original bundle, i.e. bundle A. Bundle A contains ... PCB-k with range 0 - 59 (w/o correlator) encrypted data 0 - 59 The "PCB-k" indicates a "first-block" PCB, containing key-info. Such a = block MUST be replicated in every fragment. The 40-byte limit applies so this = bundle, at each node, is now fragmented 40 + 20. We assume that the = security-dest is the bundle-dest, for simplicity (yeah, right :) So these two = independent copies of bundle A become new bundles Aa/Ab and Ac/Ad The contents will be ... Bundle Aa PCBa-k with range 0 - 39, correlator 0 - 3 - 1 encrypted (PCB-k with range 0 - 59 w/o corr), correlator 0 - 3 - 1 doubly-encrypted data 0 - 39 Bundle Ab PCBb-k with range 40 - 59, correlator 0 - 3 - 1 encrypted (PCB-k with range 0 - 59 w/o corr), correlator 0 - 3 - 1 doubly-encrypted data 40-59 The other copy of bundle A will look very much the same ... PCBc-k with range 0 - 39, correlator 0 - 3 - 1 encrypted (PCB-k with range 0 - 59 w/o corr), correlator 0 - 3 - 1 doubly-encrypted data 0 - 39 Bundle Ab PCBd-k with range 40 - 59, correlator 0 - 3 - 1 encrypted (PCB-k with range 0 - 59 w/o corr), correlator 0 - 3 - 1 doubly-encrypted data 40-59 It's fairly clear that there's no possibility that merge-and-reassemble = will work. The sequence that must happen is to first unwrap PC from each = bundle. The attempt to do the second PC unwrap will fail since no bundle has the = data range to match the range of the PCBs (0 - 59). So reassembly looks for = suitable data and finds two copies of both 0 - 39 and 40 - 59. Fortunately, = these respective copies are identical, so reassembly happens and the duplicates = are discarded, along with a duplicate copy of PCB-k. Decryption of bytes 0 - 59 now proceeds and hopefully the bundle = containing 60 - 99 has also arrived. These two are reassembled and we have our = original message. 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. Regards.....Peter p.s. the descriptions above are believed to be correct but it has been a = while since I did this for real and I may be rusty. Please let me know if = there are errors 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 wrote: > >> Amy Alford 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 >> >> From plovell@mac.com Sat Mar 23 14:32:58 2013 Return-Path: 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 44B3921F8951 for ; Sat, 23 Mar 2013 14:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 VNTwQJ3VSOlL for ; Sat, 23 Mar 2013 14:32:57 -0700 (PDT) Received: from st11p00mm-asmtp003.mac.com (st11p00mm-asmtpout003.mac.com [17.172.81.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7DACF21F8B96 for ; Sat, 23 Mar 2013 14:32:57 -0700 (PDT) Received: from [192.168.1.97] (pool-96-241-42-32.washdc.fios.verizon.net [96.241.42.32]) by st11p00mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0MK400KR1UIN8V50@st11p00mm-asmtp003.mac.com> for dtn-security@irtf.org; Sat, 23 Mar 2013 21:32:52 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-03-23_03:2013-03-22, 2013-03-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1302030000 definitions=main-1303230253 From: Peter Lovell To: Amy Alford Date: Sat, 23 Mar 2013 17:32:52 -0400 Message-id: <20130323213252.461319491@smtp.mail.me.com> In-reply-to: References: <20130320011114.1072992195@smtp.mail.me.com> <20130323005838.947157858@smtp.mail.me.com> X-Mailer: CTM PowerMail version 6.1.5b1 build 4653 English (intel) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Cc: dtn-security Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 21:32:58 -0000 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. Is there a specific reason for a two-block PIB=3F >> 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. >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. Regards.....Peter From shepherd0309@qq.com Sun Mar 24 21:06:20 2013 Return-Path: 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 8A9A221F8E23 for ; Sun, 24 Mar 2013 21:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.012 X-Spam-Level: **** X-Spam-Status: No, score=4.012 tagged_above=-999 required=5 tests=[AWL=2.443, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 GEPhl+PYWYEX for ; Sun, 24 Mar 2013 21:06:19 -0700 (PDT) Received: from smtpbg64.qq.com (smtpbg62.qq.com [103.7.29.139]) by ietfa.amsl.com (Postfix) with SMTP id 33A3521F8E14 for ; Sun, 24 Mar 2013 21:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907; t=1364184368; bh=e5IG/swB5OAa1Z17iju7WIjqH6NJwZIXTMeyvgnod/A=; h=X-QQ-mid:Received:X-QQ-SSF:Date:From:To:Reply-To:Subject: References:X-Priority:X-Has-Attach:X-Mailer:Mime-Version: Message-ID:Content-Type; b=UTQu56gmS3a8fuHx+i2QVEVPYoA2mrwtOyWe0fsBzwoqOIPZ7WFk+U+Ta/mmTBVA+ g0YeKsgzTttc5TFU5SPWCvA+8pu1kt2ehH2cgHUyWAtpRlTCE6/fzUi4obO8Zkz X-QQ-mid: esmtp30t1364184367t452t27128 Received: from WWW-337DD9F2496 (unknown [58.18.168.125]) by esmtp4.qq.com (ESMTP) with id ; Mon, 25 Mar 2013 12:06:06 +0800 (CST) X-QQ-SSF: 01000000000000F0FxF00F000000000 Date: Mon, 25 Mar 2013 12:06:12 +0800 From: jiangxin To: dtn-security , dtn-security References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201303251206112819950@qq.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart437758556335_=----" Subject: Re: [dtn-security] dtn-security Digest, Vol 11, Issue 5 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: shepherd0309 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 04:06:20 -0000 This is a multi-part message in MIME format. ------=_001_NextPart437758556335_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Y291bGQgeW91IHBsZWFzZSB0ZWxsIG1lIGhvdyB0byBpbXBsZW1lbnQgdGhlIERUTiBpbmNlbnRp dmUgbWVjaGFuaXNtIG9uIFRoZSBPTkUgPyBBbmQgY291bGQgeW91IHBsZWFzZSBzZW5kIG1lIHNv bWUgc2ltdWxhdGlvbiBzY3JpcHRzPw0KDQoNCg0KDQpqaWFuZ3hpbg0KDQpGcm9tOiBkdG4tc2Vj dXJpdHktcmVxdWVzdA0KRGF0ZTogMjAxMy0wMy0yNSAwMzowMA0KVG86IGR0bi1zZWN1cml0eQ0K U3ViamVjdDogZHRuLXNlY3VyaXR5IERpZ2VzdCwgVm9sIDExLCBJc3N1ZSA1DQpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGRpZ2VzdCB3aXRob3V0IGFsbCB0aGUgaW5kaXZpZHVhbCBtZXNzYWdl DQphdHRhY2htZW50cyB5b3Ugd2lsbCBuZWVkIHRvIHVwZGF0ZSB5b3VyIGRpZ2VzdCBvcHRpb25z IGluIHlvdXIgbGlzdA0Kc3Vic2NyaXB0aW9uLiAgVG8gZG8gc28sIGdvIHRvIA0KDQpodHRwczov L3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bi1zZWN1cml0eQ0KDQpDbGljayB0aGUg J1Vuc3Vic2NyaWJlIG9yIGVkaXQgb3B0aW9ucycgYnV0dG9uLCBsb2cgaW4sIGFuZCBzZXQgIkdl dA0KTUlNRSBvciBQbGFpbiBUZXh0IERpZ2VzdHM/IiB0byBNSU1FLiAgWW91IGNhbiBzZXQgdGhp cyBvcHRpb24NCmdsb2JhbGx5IGZvciBhbGwgdGhlIGxpc3QgZGlnZXN0cyB5b3UgcmVjZWl2ZSBh dCB0aGlzIHBvaW50Lg0KDQoNCg0KU2VuZCBkdG4tc2VjdXJpdHkgbWFpbGluZyBsaXN0IHN1Ym1p c3Npb25zIHRvDQpkdG4tc2VjdXJpdHlAaXJ0Zi5vcmcNCg0KVG8gc3Vic2NyaWJlIG9yIHVuc3Vi c2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0DQpodHRwczovL3d3dy5pcnRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2R0bi1zZWN1cml0eQ0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1l c3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvDQpkdG4tc2VjdXJpdHktcmVxdWVz dEBpcnRmLm9yZw0KDQpZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3Qg YXQNCmR0bi1zZWN1cml0eS1vd25lckBpcnRmLm9yZw0KDQpXaGVuIHJlcGx5aW5nLCBwbGVhc2Ug ZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljDQp0aGFuICJSZTog Q29udGVudHMgb2YgZHRuLXNlY3VyaXR5IGRpZ2VzdC4uLiINCg0KDQoNClRvZGF5J3MgVG9waWNz Og0KDQogICAxLiBSZSg0KTogSW5jbHVkaW5nIGZyYWdtZW50IG9mZnNldCBpbiB0aGUgY29ycmVs YXRvciBkb2Vzbid0DQogICAgICBwcmV2ZW50IGFsbCBmcmFnbWVudCBjb2xsaXNpb25zLiAoUGV0 ZXIgTG92ZWxsKQ== ------=_001_NextPart437758556335_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

could you please tell me how to implement the DTN incentive mechanism= on=20 The ONE ? And could you please send me some simulation scripts?

jiangxin

From: dtn-security-request

Date: 2013-03-25 03:00

To: dtn-security

Subject: dtn-security Digest, Vol 11, Issue 5