From scott.c.burleigh@jpl.nasa.gov Mon Apr 1 11:35: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 3C6E311E80EA for ; Mon, 1 Apr 2013 11:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 YCdI+x9izCfk for ; Mon, 1 Apr 2013 11:35:13 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 6672A11E80E6 for ; Mon, 1 Apr 2013 11:35:10 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r31IZ9ds021446 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Mon, 1 Apr 2013 11:35:09 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.50]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.02.0342.003; Mon, 1 Apr 2013 11:35:09 -0700 From: "Burleigh, Scott C (313B)" To: "dtn-security@irtf.org" Thread-Topic: [dtn-security] dtn-security Digest, Vol 9, Issue 4 Thread-Index: AQHN+ZPuFbqQaeuxFUeSJ76vVDa5BphXOFZQgGriacA= Date: Mon, 1 Apr 2013 18:35:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 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: Mon, 01 Apr 2013 18:35:14 -0000 Following up on this thread: I've posted an Internet Draft for a somewhat r= evised bundle-in-bundle encapsulation spec that does the kinds of things I = was hoping to accomplish with bundle encapsulation and is, I think, a littl= e simpler than the original design. It's at http://datatracker.ietf.org/do= c/draft-irtf-burleigh-bibe/. Scott -----Original Message----- From: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org] = On Behalf Of Burleigh, Scott C (313B) Sent: Wednesday, January 23, 2013 11:05 AM To: dtn-security@irtf.org Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 You're right, Angela, I definitely wouldn't want bundles to have to be enca= psulated every time any security block was added. The idea here would be t= hat you only encapsulate bundle Q whose source is A and whose destination i= s Z if you know -- at the time you are forwarding Q -- that in order for Q = to reach its destination safely it has got to traverse an additionally secu= red path segment from node X to node Y. In this case you'd create a new bu= ndle R whose source is X, whose destination is Y, and whose payload is Q, t= o which you would attach the required additional security blocks. That is, you'd encapsulate under exactly those conditions under which, in 6= 257 as written, you would annotate your additional BSP extension blocks wit= h security source and security destination other than the original source a= nd final destination. The reason to do this would be to delegate to Routin= g, in a straightforward and transparent manner, the job of ensuring that th= e bundle is forwarded to the security destination. If a node just wants to add a signature to a bundle, the question is whethe= r the node that will validate that signature (and therefore must know the c= orresponding key) is the final destination or some interim destination that= the bundle MUST be routed through. If the latter, then yes, you'd have to= encapsulate, because you're constraining the routing system. If the forme= r -- and if the validating destination node doesn't care which node attache= d the signature -- then no. You're right that encapsulation would eliminate non-destination nodes' abil= ity to peer into the original bundle's payload. Is that really a desirable= feature? I'm a little skeptical that we should rely on any node other tha= n the final destination having access to the payload; certainly if the payl= oad were encrypted this ought to be moot. Maybe there's still some desire = to be able to support deep packet/bundle inspection in firewall-like struct= ures, but I'd think that anything as intrusive as that wouldn't be deterred= by a bit of encapsulation. If a node wanted to sign and then encrypt a bundle, there would need to be = additional encapsulation if the node that must decrypt the bundle and/or th= e node that must validate the signature is other than the destination node.= Again, you'd have to encapsulate in order to cause the bundle to be route= d in the manner in which you require it to be routed. The same general principle would apply to extension security blocks. If th= e bundle has to be routed to a specific node in order for extension blocks = to be decrypted or validated -- and that node is different from the destina= tion node and from node to which it must be routed for the purpose of decry= pting/validating the payload -- then you'd have to encapsulate in order to = cause the bundle to be routed in the manner in which you require it to be r= outed. I think you could still encrypt different extension blocks with different k= eys without encapsulation, so long as the bundle's destination knew all of = the keys. Maybe you'd still want correlators to indicate which keys apply = to which blocks, but I would think that would be managed by policy rather t= han by instructions carried in the bundle. If not, though, then you're rig= ht, we wouldn't be able to get rid of correlators. One thing that this concept does is force the forwarding node to actually k= now what it's doing. It's no longer sufficient just to attach several secu= rity blocks and let the network try to figure out what you meant. You have= to have an actual plan for effecting all of the processing that you are go= ing to require, because that plan will drive the order of encapsulation and= security block attachment. I see that as an advantage rather than a drawb= ack, though. Scott -----Original Message----- From: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org] = On Behalf Of Angela Hennessy Sent: Wednesday, January 23, 2013 10:03 AM To: dtn-security@irtf.org Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 Hi Scott, I like how this approach simplifies the routing and gets rid of the securit= y src/dest and EID refs. I was a little confused though about how this woul= d work with some of the combinations of security blocks: If a node just wants to add a signature to a bundle, would this require the= bundle to be encapsulated? One of the advantages of BSP is that non securi= ty-aware nodes can still access the payload by just ignoring the PIB block.= Wouldn't we lose that feature if the bundle were encapsulated? If a node wants to sign and then encrypt the bundle, does this require the = bundle to be encapsulated twice? How would we handle signing/encrypting extension blocks? Would this require= a third encapsulation? Wouldn't we still need correlators in case multiple= extension blocks are encrypted with the same key, or would we not allow di= fferent extension blocks to be encrypted with different keys? From elwynd@folly.org.uk Sat Apr 13 11:15:45 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 D578A21F8B3A for ; Sat, 13 Apr 2013 11:15:45 -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 Ow-8l3FGW1iW for ; Sat, 13 Apr 2013 11:15:45 -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 DF36421F8B15 for ; Sat, 13 Apr 2013 11:15:44 -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 1UR4zG-0007Wz-R8; Sat, 13 Apr 2013 19:15:43 +0100 From: Elwyn Davies To: Amy Alford In-Reply-To: References: <20130320011114.1072992195@smtp.mail.me.com> <20130323005838.947157858@smtp.mail.me.com> <20130323213252.461319491@smtp.mail.me.com> Content-Type: text/plain Organization: Folly Consulting Date: Sat, 13 Apr 2013 19:10:32 +0100 Message-Id: <1365876632.5273.8820.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: dtn-security 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 18:15:46 -0000 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 wrote: > 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. > 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 From aloomis@sarn.org Sat Apr 13 15:12:40 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 BE6A921F851C for ; 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 ; 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 ; Sat, 13 Apr 2013 15:12:39 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id bv4so330356qab.1 for ; 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: <20130320011114.1072992195@smtp.mail.me.com> <20130323005838.947157858@smtp.mail.me.com> <20130323213252.461319491@smtp.mail.me.com> <1365876632.5273.8820.camel@mightyatom> Date: Sat, 13 Apr 2013 18:12:38 -0400 Message-ID: From: Amy Alford To: Elwyn Davies Content-Type: multipart/alternative; boundary=047d7b675db04f35ba04da4551ab X-Gm-Message-State: ALoCoQkUW4z5+nb9noeywlha7rxOI/hLbclNo9VprU/1jt9lyPs8/041v87rGSVRfMRGP+G5FiSx Cc: dtn-security 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 22:12:40 -0000 --047d7b675db04f35ba04da4551ab Content-Type: text/plain; charset=ISO-8859-1 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 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 wrote: > > 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. > > 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 > > --047d7b675db04f35ba04da4551ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If you think about a "fragmentation path" simila= r to a security path, whenever fragmentation paths and security paths overl= ap (instead of one nesting inside the other), Bad Things (TM) are probably = going to happen in DTN2.=A0

If it's fragment -> add bsp -> defragment -> re= move bsp, you're up against the fact that defragmentation doesn't n= ecessarily preserve enough info to validate the BSP blocks. =A0Even if it d= oes, DTN2 currently doesn't recognize that a set of valid BSP blocks th= at cover the payload are enough to satisfy policy requirements.

If it's add bsp -> fragment -&= gt; remove bsp -> defragment, you're obviously sunk because you can&= #39;t validate the BSP blocks which apply to the whole payload when you onl= y have a fragment. =A0In this case, you obviously need to reconstitute the = bundle before you remove the BSP blocks.

This doesn't even touch the headaches i= nvolved with multiple BSP instances and multiple fragmentation.

BiB will need to deal with the second case (the e= asy one - DTN2 will probably handle this with no changes), but avoids the f= irst 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 pr= oblems though, because it still allows security sources and hop-by-hop ciph= ersuites still need to be able to handle non-security-aware nodes in the mi= ddle. =A0


=

On Sat, Apr 13, 2013 at 2:10 PM, Elwyn D= avies <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. =A0I haven't looked in deta= il
into the code, but I suspect that there are some cases in which order
of delivery via the two different paths might lead to =A0the 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:
> =A0 =A0 =A0 =A0 Hi Amy,
>
> =A0 =A0 =A0 =A0 Amy Alford <alo= omis@sarn.org> wrote:
>
> =A0 =A0 =A0 =A0 >Yes, my example was assuming a PIB ciphersuite tha= t used two
> =A0 =A0 =A0 =A0 blocks
> =A0 =A0 =A0 =A0 >(similar to BAB). =A0That case is the most problem= atic, because
> =A0 =A0 =A0 =A0 when the
> =A0 =A0 =A0 =A0 >bundle is fragmented, the two blocks will end up i= n separate
> =A0 =A0 =A0 =A0 fragments.
> =A0 =A0 =A0 =A0 > Otherwise, the correlator collision isn't a p= roblem as long
> =A0 =A0 =A0 =A0 as reassembly
> =A0 =A0 =A0 =A0 >happens at the destination.
>
> =A0 =A0 =A0 =A0 PIB is, in some ways, a more difficult scenario than P= CB. When
> =A0 =A0 =A0 =A0 a bundle with PCB arrives at the security-dest, the pa= yload is
> =A0 =A0 =A0 =A0 decrypted (and other blocks as appropriate) and the PC= B itself
> =A0 =A0 =A0 =A0 is deleted. But some folks want to have PIBs remain ev= en after
> =A0 =A0 =A0 =A0 verification, as evidence I guess. That is messy.
> Leaving PIBs on after verification is problematic anyway, if the PIB > was added after a PCB. =A0Once the PCB reaches it's security
> destination, the PIB is invalid anyhow.
>
>
> =A0 =A0 =A0 =A0 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. =A0I assume you'd still want an up front block to = warn
> nodes that are doing one pass processing that they need to start
> hashing.
>
>
> =A0 =A0 =A0 =A0 >> As you can see, this is a quite involved proc= ess. A couple
> =A0 =A0 =A0 =A0 of things are
> =A0 =A0 =A0 =A0 >> worthy of note:
> =A0 =A0 =A0 =A0 >> 1. correlators are local to their bundle
> =A0 =A0 =A0 =A0 >> 2. a block with a correlator may be encapsula= ted, with PCB
> =A0 =A0 =A0 =A0 for example.
> =A0 =A0 =A0 =A0 >> The original correlator is hidden until decap= sulation
> =A0 =A0 =A0 =A0 occurs (not shown
> =A0 =A0 =A0 =A0 >> above for sake of brevity :)
> =A0 =A0 =A0 =A0 >> 3. reassembly is a very, very complex process= .
> =A0 =A0 =A0 =A0 >>
> =A0 =A0 =A0 =A0 >I was pondering how to support these sorts of case= s (which
> =A0 =A0 =A0 =A0 end up needing
> =A0 =A0 =A0 =A0 >validation and reassembly interleaved somehow). = =A0In thinking
> =A0 =A0 =A0 =A0 about it, I
> =A0 =A0 =A0 =A0 >started running into scenarios that aren't sup= portable. =A0The
> =A0 =A0 =A0 =A0 example I gave
> =A0 =A0 =A0 =A0 >is one (which I think shows that bundles with two = block PIBs
> =A0 =A0 =A0 =A0 need to have
> =A0 =A0 =A0 =A0 >the do not fragment flag set).
> =A0 =A0 =A0 =A0 It may be sufficient to apply the
> =A0 =A0 =A0 =A0 replicate-key-info-in-every-block rule. I don't kn= ow without
> =A0 =A0 =A0 =A0 thinking about it some more.
>
>
> I think it would fix the example I gave. =A0The last fragment would > contain both the leading and trailing PIB blocks. =A0The leading block=
> could be used to match this up with the corresponding fragment (which<= br> > also has a leading PIB block but is missing the trailing one). =A0It > would be a pain in terms of processing, since defragmentation would > need to match up the corresponding fragments by comparing their
> leading PIB blocks.
>
>
>
>
> =A0 =A0 =A0 =A0 >Additionally, in general, if an intermediate node = reassembles
> =A0 =A0 =A0 =A0 fragments
> =A0 =A0 =A0 =A0 >that have had BSP blocks added after fragmentation= , we can't
> =A0 =A0 =A0 =A0 validate. =A0Too
> =A0 =A0 =A0 =A0 >much information is lost on reassembly (even if it= 's done
> =A0 =A0 =A0 =A0 sensibly). =A05050
> =A0 =A0 =A0 =A0 >allows intermediate nodes to reassemble, but doesn= 't mandate
> =A0 =A0 =A0 =A0 a procedure
> =A0 =A0 =A0 =A0 >for reassembling the extension blocks (so it may n= ot be done
> =A0 =A0 =A0 =A0 sensibly).
>
> =A0 =A0 =A0 =A0 It's not just an issue of reassembling/reordering = extension
> =A0 =A0 =A0 =A0 blocks. As the final example shows, any attempt to
> =A0 =A0 =A0 =A0 reassemble-first is doomed to failure because the two = parts
> =A0 =A0 =A0 =A0 were encrypted under different second-stage keys.
>
> =A0 =A0 =A0 =A0 It's clear to me that reassembly of bundles contai= ning
> =A0 =A0 =A0 =A0 security blocks must be done in concert with security<= br> > =A0 =A0 =A0 =A0 processing. This needs to be incorporated into any upd= ate to
> =A0 =A0 =A0 =A0 5050. And, as you say, there are cases that aren't= supportable
> =A0 =A0 =A0 =A0 with the capabilities we now have.
>
> Yes. =A0In general, nodes shouldn't reassemble a bundle if they do= n't
> understand all the extension blocks. =A0BSP aware nodes shouldn't<= br> > reassemble fragments except in concert with security processing.
>
>
>
>
> =A0 =A0 =A0 =A0 Regards.....Peter
>
>
> _______________________________________________
> dtn-security mailing list
> dtn-security@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-security


--047d7b675db04f35ba04da4551ab-- From scott.c.burleigh@jpl.nasa.gov Sat Apr 13 17:25:10 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 1B7D621F8DDF for ; Sat, 13 Apr 2013 17:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 cTX2UcXZLp4x for ; Sat, 13 Apr 2013 17:25:08 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id BCCA121F8A6B for ; Sat, 13 Apr 2013 17:25:08 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3E0P5ew005688 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Sat, 13 Apr 2013 17:25:05 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.50]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.100]) with mapi id 14.02.0342.003; Sat, 13 Apr 2013 17:25:04 -0700 From: "Burleigh, Scott C (313B)" To: Amy Alford , Elwyn Davies Thread-Topic: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions. Thread-Index: AQHOKA4AwAq0n0zXUkuQfuDcUCFv7Zi3S36AgB2+HgCAAEOkAP//rp7y Date: Sun, 14 Apr 2013 00:25:03 +0000 Message-ID: References: <20130320011114.1072992195@smtp.mail.me.com> <20130323005838.947157858@smtp.mail.me.com> <20130323213252.461319491@smtp.mail.me.com> <1365876632.5273.8820.camel@mightyatom>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.113] Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B235B2E1Eapembxsp40RESAD_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Cc: dtn-security 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 00:25:10 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B235B2E1Eapembxsp40RESAD_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Amy, I certainly agree on the potential for Bad Things happening when fragm= entation and security aren't cleanly nested. Can you say a little more abo= ut how the proposed new BSP draft's support for security sources could expo= se nodes to these problems? Scott ________________________________ From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] on beha= lf of Amy Alford [aloomis@sarn.org] Sent: Saturday, April 13, 2013 3:12 PM To: Elwyn Davies Cc: dtn-security Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions. If you think about a "fragmentation path" similar to a security path, whene= ver 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 v= alidate 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 s= unk because you can't validate the BSP blocks which apply to the whole payl= oad when you only have a fragment. In this case, you obviously need to rec= onstitute 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 probab= ly handle this with no changes), but avoids the first case because an encap= sulated fragment is not itself a fragment (so it can't be reconstituted unt= il 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 t= o handle non-security-aware nodes in the middle. On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies > 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 > wrote: > 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. > 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 --_000_A5BEAD028815CB40A32A5669CF737C3B235B2E1Eapembxsp40RESAD_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Amy, I certainly agree on the potential for Bad Things happening whe= n fragmentation and security aren't cleanly nested.  Can you say a lit= tle more about how the proposed new BSP draft's support for security sources could expose nodes to these problems?

Scott
From: dtn-security-bounces@irtf.org [dtn-= security-bounces@irtf.org] on behalf of Amy Alford [aloomis@sarn.org]
Sent: Saturday, April 13, 2013 3:12 PM
To: Elwyn Davies
Cc: dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the = correlator doesn't prevent all fragment collisions.

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

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

If it's add bsp -> fragment -> remove bsp -> defra= gment, you're obviously sunk because you can't validate the BSP blocks whic= h apply to the whole payload when you only have a fragment.  In this c= ase, you obviously need to reconstitute the bundle before you remove the BSP blocks.

This doesn't even touch the headaches involved with multipl= e 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 r= econstituted until after it's been decapsulated).

The new BSP draft may not sidestep these problems though, b= ecause it still allows security sources and hop-by-hop ciphersuites still n= eed 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.o= rg.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 detai= l
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 cip= hersuite that used two
>         blocks
>         >(similar to BAB).  That case is t= he most problematic, because
>         when the
>         >bundle is fragmented, the two blocks w= ill end up in separate
>         fragments.
>         > Otherwise, the correlator collision i= sn't a problem as long
>         as reassembly
>         >happens at the destination.
>
>         PIB is, in some ways, a more difficult sce= nario 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 PI= Bs 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 w= arn
> nodes that are doing one pass processing that they need to start
> hashing.
>
>
>         >> As you can see, this is a quite i= nvolved 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 com= plex process.
>         >>
>         >I was pondering how to support these s= orts of cases (which
>         end up needing
>         >validation and reassembly interleaved = somehow).  In thinking
>         about it, I
>         >started running into scenarios that ar= en't supportable.  The
>         example I gave
>         >is one (which I think shows that bundl= es 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 bl= ock
> could be used to match this up with the corresponding fragment (which<= br> > also has a leading PIB block but is missing the trailing one).  I= t
> 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 interm= ediate node reassembles
>         fragments
>         >that have had BSP blocks added after f= ragmentation, we can't
>         validate.  Too
>         >much information is lost on reassembly= (even if it's done
>         sensibly).  5050
>         >allows intermediate nodes to reassembl= e, 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/reo= rdering extension
>         blocks. As the final example shows, any at= tempt to
>         reassemble-first is doomed to failure beca= use the two parts
>         were encrypted under different second-stag= e keys.
>
>         It's clear to me that reassembly of bundle= s containing
>         security blocks must be done in concert wi= th security
>         processing. This needs to be incorporated = into any update to
>         5050. And, as you say, there are cases tha= t 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-securit= y@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-security


--_000_A5BEAD028815CB40A32A5669CF737C3B235B2E1Eapembxsp40RESAD_-- From aloomis@sarn.org Sun Apr 14 13:50:51 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 62ADC21F8C98 for ; Sun, 14 Apr 2013 13:50:51 -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 vkWgWv40FAgF for ; Sun, 14 Apr 2013 13:50:50 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id AA1AE21F851C for ; Sun, 14 Apr 2013 13:50:49 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id bs12so387509qab.2 for ; Sun, 14 Apr 2013 13:50:44 -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=2O8z9prelcY9zI0Ta2i8CNQoyqTRZB6Nl18sBd6OtM0=; b=DcJXJe6/BUbjs6s4CBm4rsmX00YAdIdZkhWeWPvEdO+Z0i83HmONOsIVmTvfVMZbKz Di/0f8oHrnidyuwZbWyOs1l5tLEwUWwJzdxSy4WZ4uYD5cy5Y/rhCZbH0gNBC4flwfmy B5vUYMEQJXPjQs4QlSDqvpdWyfWlq26vFYF2hg/IA/CZa3F9Teu/2hu95Cml+YUAZBix 2waD7VxeVmgLTg/v6lV12iheZlJK2mxJgDIqzdApokSFDWVP2ICgdCfkK1McirxPKnKk +M/77ZObCQ29FxzpkOQ3kmY8TUg2c2KpZ4Xx1Hab6qp37FpyA5eD6uLZXznF7lDSpnlx NA3A== MIME-Version: 1.0 X-Received: by 10.224.210.10 with SMTP id gi10mr20066585qab.36.1365972644112; Sun, 14 Apr 2013 13:50:44 -0700 (PDT) Received: by 10.49.76.71 with HTTP; Sun, 14 Apr 2013 13:50:43 -0700 (PDT) In-Reply-To: References: <20130320011114.1072992195@smtp.mail.me.com> <20130323005838.947157858@smtp.mail.me.com> <20130323213252.461319491@smtp.mail.me.com> <1365876632.5273.8820.camel@mightyatom> Date: Sun, 14 Apr 2013 16:50:43 -0400 Message-ID: From: Amy Alford To: "Burleigh, Scott C (313B)" Content-Type: multipart/alternative; boundary=20cf300faeed39bc9104da584afe X-Gm-Message-State: ALoCoQkml2gHP4hihmudp0Ss8C0P8IN18ltstwgz52OpXonc40PM69bvzaD/b2PLalNkPvSP2sE2 Cc: dtn-security 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 20:50:51 -0000 --20cf300faeed39bc9104da584afe Content-Type: text/plain; charset=ISO-8859-1 5050 allows any node to reassemble fragments. So, if fragmentation occurs before security blocks are added, any subsequent node may then reassemble the bundle. Additionally, hop-by-hop ciphersuites may have intermediate non-security aware nodes. These can potentially fragment/reassemble, creating the same overlapping fragmentation path/security path scenarios. The example I sent out earlier in response to Peter Lovell is still a possibility if you have a PIB ciphersuite that uses two blocks (one before the payload and one after). BIBE does mitigate this, since we can use the "DO_NOT_FRAGMENT" flag whenever we add a two block PIB, and then encapsulate. Once we've encapsulated, we can fragment again. There's a problem with enforcing the one logical security block of each type/target per bundle rule if a bundle is reassembled by an intermediate node. Security blocks may have been applied to different fragments which are then recombined in such a way that there is more than one logical security block of the same type/target. These may apply to overlapping payload regions, or even the same payload region (depending on how the recombining node handles receiving duplicate fragments over different links). These are the cases I've thought of. I'm nervous that there's enough complexity in the intersection of fragmentation/encapsulation/BSP that it's hard to be confident that all the possible combinations will work correctly. - Amy On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott C (313B) < scott.c.burleigh@jpl.nasa.gov> wrote: > Amy, I certainly agree on the potential for Bad Things happening when > fragmentation and security aren't cleanly nested. Can you say a little > more about how the proposed new BSP draft's support for security sources > could expose nodes to these problems? > > Scott > ------------------------------ > *From:* dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] on > behalf of Amy Alford [aloomis@sarn.org] > *Sent:* Saturday, April 13, 2013 3:12 PM > *To:* Elwyn Davies > *Cc:* dtn-security > *Subject:* Re: [dtn-security] Re(4): Including fragment offset in the > correlator doesn't prevent all fragment collisions. > > 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 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 wrote: >> > 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. >> > 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 >> >> > --20cf300faeed39bc9104da584afe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
5050 allows any node to reassemble fragments. =A0So, if fr= agmentation occurs before security blocks are added, any subsequent node ma= y then reassemble the bundle.

Additionally, hop-by-hop c= iphersuites may have intermediate non-security aware nodes. =A0These can po= tentially fragment/reassemble, creating the same overlapping fragmentation = path/security path scenarios.

The example I sent out earlier in response to Peter Lov= ell is still a possibility if you have a PIB ciphersuite that uses two bloc= ks (one before the payload and one after). =A0BIBE does mitigate this, sinc= e we can use the "DO_NOT_FRAGMENT" flag whenever we add a two blo= ck PIB, and then encapsulate. =A0Once we've encapsulated, we can fragme= nt again.

There's a problem with enforcing the one logical security block of= each type/target per bundle rule if a bundle is reassembled by an intermed= iate node. Security blocks may have been applied to different fragments whi= ch are then recombined in such a way that there is more than one logical se= curity block of the same type/target. =A0These may apply to overlapping pay= load regions, or even the same payload region (depending on how the recombi= ning node handles receiving duplicate fragments over different links).

These are the cases I've thought of. =A0I'= ;m nervous that there's enough complexity in the intersection of fragme= ntation/encapsulation/BSP that it's hard to be confident that all the p= ossible combinations will work correctly.

- Amy


On Sat, Apr 13, 2013 at 8:25 PM, Burlei= gh, Scott C (313B) <scott.c.burleigh@jpl.nasa.gov> wrote:
Amy, I certa= inly agree on the potential for Bad Things happening when fragmentation and= security aren't cleanly nested. =A0Can you say a little more about how= the proposed new BSP draft's support for security sources could expose nodes to these probl= ems?

Scott
Fro= m: d= tn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] on behalf of A= my Alford [aloomis@sa= rn.org]
Sent: Saturday, April 13, 2013 3:12 PM
To: Elwyn Davies
Cc: dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the = correlator doesn't prevent all fragment collisions.

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

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. =A0Even if it does, DTN2 = currently doesn't recognize that a set of valid BSP blocks that cover the payload are enough to satisfy policy requirement= s.

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

This doesn't even touch the headaches involved with multiple BSP i= nstances and multiple fragmentation.

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

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




On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies <elwynd@folly.o= rg.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. =A0I haven't looked in deta= il
into the code, but I suspect that there are some cases in which order
of delivery via the two different paths might lead to =A0the 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:
> =A0 =A0 =A0 =A0 Hi Amy,
>
> =A0 =A0 =A0 =A0 Amy Alford <aloomis@sarn.org> wrote:
>
> =A0 =A0 =A0 =A0 >Yes, my example was assuming a PIB ciphersuite tha= t used two
> =A0 =A0 =A0 =A0 blocks
> =A0 =A0 =A0 =A0 >(similar to BAB). =A0That case is the most problem= atic, because
> =A0 =A0 =A0 =A0 when the
> =A0 =A0 =A0 =A0 >bundle is fragmented, the two blocks will end up i= n separate
> =A0 =A0 =A0 =A0 fragments.
> =A0 =A0 =A0 =A0 > Otherwise, the correlator collision isn't a p= roblem as long
> =A0 =A0 =A0 =A0 as reassembly
> =A0 =A0 =A0 =A0 >happens at the destination.
>
> =A0 =A0 =A0 =A0 PIB is, in some ways, a more difficult scenario than P= CB. When
> =A0 =A0 =A0 =A0 a bundle with PCB arrives at the security-dest, the pa= yload is
> =A0 =A0 =A0 =A0 decrypted (and other blocks as appropriate) and the PC= B itself
> =A0 =A0 =A0 =A0 is deleted. But some folks want to have PIBs remain ev= en after
> =A0 =A0 =A0 =A0 verification, as evidence I guess. That is messy.
> Leaving PIBs on after verification is problematic anyway, if the PIB > was added after a PCB. =A0Once the PCB reaches it's security
> destination, the PIB is invalid anyhow.
>
>
> =A0 =A0 =A0 =A0 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. =A0I assume you'd still want an up front block to = warn
> nodes that are doing one pass processing that they need to start
> hashing.
>
>
> =A0 =A0 =A0 =A0 >> As you can see, this is a quite involved proc= ess. A couple
> =A0 =A0 =A0 =A0 of things are
> =A0 =A0 =A0 =A0 >> worthy of note:
> =A0 =A0 =A0 =A0 >> 1. correlators are local to their bundle
> =A0 =A0 =A0 =A0 >> 2. a block with a correlator may be encapsula= ted, with PCB
> =A0 =A0 =A0 =A0 for example.
> =A0 =A0 =A0 =A0 >> The original correlator is hidden until decap= sulation
> =A0 =A0 =A0 =A0 occurs (not shown
> =A0 =A0 =A0 =A0 >> above for sake of brevity :)
> =A0 =A0 =A0 =A0 >> 3. reassembly is a very, very complex process= .
> =A0 =A0 =A0 =A0 >>
> =A0 =A0 =A0 =A0 >I was pondering how to support these sorts of case= s (which
> =A0 =A0 =A0 =A0 end up needing
> =A0 =A0 =A0 =A0 >validation and reassembly interleaved somehow). = =A0In thinking
> =A0 =A0 =A0 =A0 about it, I
> =A0 =A0 =A0 =A0 >started running into scenarios that aren't sup= portable. =A0The
> =A0 =A0 =A0 =A0 example I gave
> =A0 =A0 =A0 =A0 >is one (which I think shows that bundles with two = block PIBs
> =A0 =A0 =A0 =A0 need to have
> =A0 =A0 =A0 =A0 >the do not fragment flag set).
> =A0 =A0 =A0 =A0 It may be sufficient to apply the
> =A0 =A0 =A0 =A0 replicate-key-info-in-every-block rule. I don't kn= ow without
> =A0 =A0 =A0 =A0 thinking about it some more.
>
>
> I think it would fix the example I gave. =A0The last fragment would > contain both the leading and trailing PIB blocks. =A0The leading block=
> could be used to match this up with the corresponding fragment (which<= br> > also has a leading PIB block but is missing the trailing one). =A0It > would be a pain in terms of processing, since defragmentation would > need to match up the corresponding fragments by comparing their
> leading PIB blocks.
>
>
>
>
> =A0 =A0 =A0 =A0 >Additionally, in general, if an intermediate node = reassembles
> =A0 =A0 =A0 =A0 fragments
> =A0 =A0 =A0 =A0 >that have had BSP blocks added after fragmentation= , we can't
> =A0 =A0 =A0 =A0 validate. =A0Too
> =A0 =A0 =A0 =A0 >much information is lost on reassembly (even if it= 's done
> =A0 =A0 =A0 =A0 sensibly). =A05050
> =A0 =A0 =A0 =A0 >allows intermediate nodes to reassemble, but doesn= 't mandate
> =A0 =A0 =A0 =A0 a procedure
> =A0 =A0 =A0 =A0 >for reassembling the extension blocks (so it may n= ot be done
> =A0 =A0 =A0 =A0 sensibly).
>
> =A0 =A0 =A0 =A0 It's not just an issue of reassembling/reordering = extension
> =A0 =A0 =A0 =A0 blocks. As the final example shows, any attempt to
> =A0 =A0 =A0 =A0 reassemble-first is doomed to failure because the two = parts
> =A0 =A0 =A0 =A0 were encrypted under different second-stage keys.
>
> =A0 =A0 =A0 =A0 It's clear to me that reassembly of bundles contai= ning
> =A0 =A0 =A0 =A0 security blocks must be done in concert with security<= br> > =A0 =A0 =A0 =A0 processing. This needs to be incorporated into any upd= ate to
> =A0 =A0 =A0 =A0 5050. And, as you say, there are cases that aren't= supportable
> =A0 =A0 =A0 =A0 with the capabilities we now have.
>
> Yes. =A0In general, nodes shouldn't reassemble a bundle if they do= n't
> understand all the extension blocks. =A0BSP aware nodes shouldn't<= br> > reassemble fragments except in concert with security processing.
>
>
>
>
> =A0 =A0 =A0 =A0 Regards.....Peter
>
>
> _______________________________________________
> dtn-security mailing list
> dtn-securit= y@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-security



--20cf300faeed39bc9104da584afe-- From scott.c.burleigh@jpl.nasa.gov Mon Apr 15 02:16: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 AAFEA21F935F for ; Mon, 15 Apr 2013 02:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 wOWZuEZDZY0g for ; Mon, 15 Apr 2013 02:16:33 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id CC2E821F935E for ; Mon, 15 Apr 2013 02:16:30 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3F9GPff005966 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 15 Apr 2013 02:16:26 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.50]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.02.0342.003; Mon, 15 Apr 2013 02:16:25 -0700 From: "Burleigh, Scott C (313B)" To: Amy Alford Thread-Topic: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions. Thread-Index: AQHOKA4AwAq0n0zXUkuQfuDcUCFv7Zi3S36AgB2+HgCAAEOkAP//rp7ygAHM1ICAAEv8dw== Date: Mon, 15 Apr 2013 09:16:25 +0000 Message-ID: References: <20130320011114.1072992195@smtp.mail.me.com> <20130323005838.947157858@smtp.mail.me.com> <20130323213252.461319491@smtp.mail.me.com> <1365876632.5273.8820.camel@mightyatom> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.114] Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B235B8C38apembxsp40RESAD_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Cc: dtn-security 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 09:16:35 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B235B8C38apembxsp40RESAD_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Okay, this may or may not be optimal, but here's how I think the proposed n= ew BSP concepts might handle the fragmentation/security combinations: * The key rule we're working with is that you can never have more than = one occurrence of any single security activity (logical block, device, stru= cture -- essentially, either a single physical block or two cooperating phy= sical blocks) in any bundle bundle. * This implies that no ciphersuite or policy can require that a PIB or = PCB be added to a bundle that is a fragment (that is, a bundle whose payloa= d is a fragment of the payload of some original bundle with the same ID). = That's because the 5050 fragmentation rules require that any extension bloc= k that precedes the payload of a bundle that is to be fragmented must be pr= eserved in the FIRST resulting fragment. That means that it is always poss= ible for a fragment to contain a payload BIB or BCB that pertains to the or= iginal bundle -- not to itself -- and therefore in at least one case the ad= dition of a fragment payload BIB would result in the bundle having two payl= oad BIBs, a violation. * Therefore, in the event that you want to protect a fragmentary payloa= d with a BIB or BCB, the only way to do so is to encapsulate the fragment b= undle in an encapsulating, non-fragmentary bundle whose payload contains th= e fragment -- and then attach a payload BIB and/or BCB that protects the en= capsulating bundle's payload. * So if fragmentation occurs and you then want to add security blocks, = the blocks will be added to encapsulating -- hence non-fragmentary -- bundl= es. So in order for reassembly to happen, all of the bundles encapsulating= the fragments need to be received at the same node. That node then necess= arily has to be able to extract the fragment bundles from the payloads of t= he encapsulating bundles, and at that point you've got the pre-security fra= gments; reassembling the original bundle payload from those fragments shoul= d be straightforward. * Since there are no security destinations in the proposed simplified B= SP spec, (a) the only hop-by-hop ciphersuites are the ones for BABs and (b)= it would be a configuration nightmare (though not impossible, I guess) to = have any non-BAB-capable nodes interposed between two nodes that are BAB ne= ighbors. If you do have a topology where you need any sort of hop-by-hop s= ecurity association other than adjacency, then you encapsulate; the destina= tion of the encapsulating bundle is the intended "next hop" destination, an= d now you're back in a non-problematic topology. I think the same principles address the other cases you identify. I'll admit that all of this encapsulation does seem a little heavyweight, b= ut in its defense I would argue that: * It's a simple mechanism that handles an unlimited range of cases (inc= luding, I think, cases that nobody has thought of yet) in a common, underst= andable way that is completely compatible with RFC 5050. * The overhead of the extra primary block for the encapsulating bundle = can be kept pretty low if you're using CBHE. * The cases we're talking about are entirely plausible for some operati= onal environments, but for the bulk of secure DTN communications activity I= think they are not likely. It makes more sense, to me, to optimize overh= ead for the common case so long as there's still a way to support all of th= e more complex cases. Scott ________________________________ From: Amy Alford [aloomis@sarn.org] Sent: Sunday, April 14, 2013 1:50 PM To: Burleigh, Scott C (313B) Cc: Elwyn Davies; dtn-security Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions. 5050 allows any node to reassemble fragments. So, if fragmentation occurs = before security blocks are added, any subsequent node may then reassemble t= he bundle. Additionally, hop-by-hop ciphersuites may have intermediate non-security aw= are nodes. These can potentially fragment/reassemble, creating the same ov= erlapping fragmentation path/security path scenarios. The example I sent out earlier in response to Peter Lovell is still a possi= bility if you have a PIB ciphersuite that uses two blocks (one before the p= ayload and one after). BIBE does mitigate this, since we can use the "DO_N= OT_FRAGMENT" flag whenever we add a two block PIB, and then encapsulate. O= nce we've encapsulated, we can fragment again. There's a problem with enforcing the one logical security block of each typ= e/target per bundle rule if a bundle is reassembled by an intermediate node= . Security blocks may have been applied to different fragments which are th= en recombined in such a way that there is more than one logical security bl= ock of the same type/target. These may apply to overlapping payload region= s, or even the same payload region (depending on how the recombining node h= andles receiving duplicate fragments over different links). These are the cases I've thought of. I'm nervous that there's enough compl= exity in the intersection of fragmentation/encapsulation/BSP that it's hard= to be confident that all the possible combinations will work correctly. - Amy On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott C (313B) > wrote: Amy, I certainly agree on the potential for Bad Things happening when fragm= entation and security aren't cleanly nested. Can you say a little more abo= ut how the proposed new BSP draft's support for security sources could expo= se nodes to these problems? Scott ________________________________ From: dtn-security-bounces@irtf.org [= dtn-security-bounces@irtf.org] on beh= alf of Amy Alford [aloomis@sarn.org] Sent: Saturday, April 13, 2013 3:12 PM To: Elwyn Davies Cc: dtn-security Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions. If you think about a "fragmentation path" similar to a security path, whene= ver 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 v= alidate 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 s= unk because you can't validate the BSP blocks which apply to the whole payl= oad when you only have a fragment. In this case, you obviously need to rec= onstitute 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 probab= ly handle this with no changes), but avoids the first case because an encap= sulated fragment is not itself a fragment (so it can't be reconstituted unt= il 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 t= o handle non-security-aware nodes in the middle. On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies > 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 > wrote: > 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. > 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 --_000_A5BEAD028815CB40A32A5669CF737C3B235B8C38apembxsp40RESAD_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Okay, this may or may not be optimal, but here's how I think the pro= posed new BSP concepts might handle the fragmentation/security combinations= :
  • The key rule we're working with is that you can never have more than&nb= sp;one occurrence of any single security a= ctivity (logical block, device, structure -- essentially, either a single p= hysical block or two cooperating physical blocks) in any bundle bundle.
  • This implies that no ciphersu= ite or policy can require that a PIB or PCB be added to a bundle that is a = fragment (that is, a bundle whose payload is a fragment of the payload of s= ome original bundle with the same ID).  That's because the 5050 fragme= ntation rules require that any extension block that precedes the payload of a bund= le that is to be fragmented must be preserved in the FIRST resulting fragme= nt.  That means that it is always possible for a fragment to contain a= payload BIB or BCB that pertains to the original bundle -- not to itself -- and therefore in at least one case= the addition of a fragment payload BIB would result in the bundle having t= wo payload BIBs, a violation.
  • Therefore, in the event that you want= to protect a fragmentary payload with a BIB or BCB, the only way to do so = is to encapsulate the fragment bundle in an encapsulating, non-fragmentary = bundle whose payload contains the fragment -- and then attach a payload BIB and/or BCB that protects the encapsulating bundle's payload.
  • S= o if fragmentation occurs and you then want to add security blocks, the blo= cks will be added to encapsulating -- hence non-fragmentary -- bundles. &nb= sp;So in order for reassembly to happen, all of the bundles encapsulating t= he fragments need to be received at the same node.  That node then necessarily has to be able to extra= ct the fragment bundles from the payloads of the encapsulating bundles, and= at that point you've got the pre-security fragments; reassembling the orig= inal bundle payload from those fragments should be straightforward.
  • Since there are no security destination= s in the proposed simplified BSP spec, (a) the only hop-by-hop ciphersuites= are the ones for BABs and (b) it would be a configuration nightmare (thoug= h not impossible, I guess) to have any non-BAB-capable nodes interposed between two nodes that are BAB neighbors.  If you do have a topology = where you need any sort of hop-by-hop security association other than adjac= ency, then you encapsulate; the destination of the encapsulating bundle is = the intended "next hop" destination, and now you're back in a non-problematic topology.
I think the same principles address the ot= her cases you identify.

I'll admit that all of this encapsula= tion does seem a little heavyweight, but in its defense I would argue that:=
  • It's a simple mechanism that handles an unlimited range of cases (inclu= ding, I think, cases that nobody has thought of yet) in a common, understan= dable way that is completely compatible with RFC 5050.
  • The overhead= of the extra primary block for the encapsulating bundle can be kept pretty= low if you're using CBHE.
  • The cases we're talking about are entire= ly plausible for some operational environments, but for the bulk of secure = DTN communications activity I think they are not  likely.  It mak= es more sense, to me, to optimize overhead for the common case so long as there's still a way to support all of the more complex cases.
Scott
From: Amy Alford [aloomis@sarn.org]
Sent: Sunday, April 14, 2013 1:50 PM
To: Burleigh, Scott C (313B)
Cc: Elwyn Davies; dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the = correlator doesn't prevent all fragment collisions.

5050 allows any node to reassemble fragments.  So, if= fragmentation occurs before security blocks are added, any subsequent node= may then reassemble the bundle.

Additionally, hop-by-hop ciphersuites may have intermediate non-securi= ty aware nodes.  These can potentially fragment/reassemble, creating t= he same overlapping fragmentation path/security path scenarios.

The example I sent out earlier in response to Peter Lovell is still a = possibility if you have a PIB ciphersuite that uses two blocks (one before = the payload and one after).  BIBE does mitigate this, since we can use= the "DO_NOT_FRAGMENT" flag whenever we add a two block PIB, and then encapsulate.  Once we've encapsulate= d, we can fragment again.

There's a problem with enforcing the one logical security block of eac= h type/target per bundle rule if a bundle is reassembled by an intermediate= node. Security blocks may have been applied to different fragments which a= re then recombined in such a way that there is more than one logical security block of the same type/target= .  These may apply to overlapping payload regions, or even the same pa= yload region (depending on how the recombining node handles receiving dupli= cate fragments over different links).

These are the cases I've thought of.  I'm nervous that= there's enough complexity in the intersection of fragmentation/encapsulati= on/BSP that it's hard to be confident that all the possible combinations wi= ll work correctly.

- Amy


On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott= C (313B) <scott.c.burleigh@jpl.nasa.gov> wrote:
Amy, I cer= tainly agree on the potential for Bad Things happening when fragmentation a= nd security aren't cleanly nested.  Can you say a little more about ho= w the proposed new BSP draft's support for security sources could expose nodes to these problems?

Scott
Fro= m: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] on behalf of = Amy Alford [aloomis@s= arn.org]
Sent: Saturday, April 13, 2013 3:12 PM
To: Elwyn Davies
Cc: dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the = correlator doesn't prevent all fragment collisions.

If you think about a "fragmentation path" simila= r to a security path, whenever fragmentation paths and security paths overl= ap (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 en= ough 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 ob= viously need to reconstitute the bundle before you remove the BSP blocks.

This doesn't even touch the headaches involved with multiple BSP insta= nces and multiple fragmentation.

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

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




On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies <elwynd@folly.o= rg.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 detai= l
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 cip= hersuite that used two
>         blocks
>         >(similar to BAB).  That case is t= he most problematic, because
>         when the
>         >bundle is fragmented, the two blocks w= ill end up in separate
>         fragments.
>         > Otherwise, the correlator collision i= sn't a problem as long
>         as reassembly
>         >happens at the destination.
>
>         PIB is, in some ways, a more difficult sce= nario 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 PI= Bs 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 w= arn
> nodes that are doing one pass processing that they need to start
> hashing.
>
>
>         >> As you can see, this is a quite i= nvolved 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 com= plex process.
>         >>
>         >I was pondering how to support these s= orts of cases (which
>         end up needing
>         >validation and reassembly interleaved = somehow).  In thinking
>         about it, I
>         >started running into scenarios that ar= en't supportable.  The
>         example I gave
>         >is one (which I think shows that bundl= es 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 bl= ock
> could be used to match this up with the corresponding fragment (which<= br> > also has a leading PIB block but is missing the trailing one).  I= t
> 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 interm= ediate node reassembles
>         fragments
>         >that have had BSP blocks added after f= ragmentation, we can't
>         validate.  Too
>         >much information is lost on reassembly= (even if it's done
>         sensibly).  5050
>         >allows intermediate nodes to reassembl= e, 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/reo= rdering extension
>         blocks. As the final example shows, any at= tempt to
>         reassemble-first is doomed to failure beca= use the two parts
>         were encrypted under different second-stag= e keys.
>
>         It's clear to me that reassembly of bundle= s containing
>         security blocks must be done in concert wi= th security
>         processing. This needs to be incorporated = into any update to
>         5050. And, as you say, there are cases tha= t 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-securit= y@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-security



--_000_A5BEAD028815CB40A32A5669CF737C3B235B8C38apembxsp40RESAD_-- From l.wood@surrey.ac.uk Tue Apr 16 03:26:31 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 0F78F21F935D for ; Tue, 16 Apr 2013 03:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 f6zXAwTquIFD for ; Tue, 16 Apr 2013 03:26:29 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC9421F914C for ; Tue, 16 Apr 2013 03:26:28 -0700 (PDT) Received: from [195.245.231.67:42349] by server-4.bemta-5.messagelabs.com id 5D/C9-01980-3572D615; Tue, 16 Apr 2013 10:26:27 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-6.tower-82.messagelabs.com!1366107986!30386446!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4505 invoked from network); 16 Apr 2013 10:26:26 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-6.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 16 Apr 2013 10:26:26 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.180]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Tue, 16 Apr 2013 11:26:26 +0100 From: To: , Date: Tue, 16 Apr 2013 11:26:25 +0100 Thread-Topic: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions. Thread-Index: AQHOKA4AwAq0n0zXUkuQfuDcUCFv7Zi3S36AgB2+HgCAAEOkAP//rp7ygAHM1ICAAEv8d4ABsdVP Message-ID: <290E20B455C66743BE178C5C84F12408223F494E66@EXMB01CMS.surrey.ac.uk> References: <20130320011114.1072992195@smtp.mail.me.com> <20130323005838.947157858@smtp.mail.me.com> <20130323213252.461319491@smtp.mail.me.com> <1365876632.5273.8820.camel@mightyatom> , , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 10:26:31 -0000 You're going to need to pursue this fragment-in-bundle and bundle-in-bundle= nesting.=20 As well as simplifying the handling, this encapsulation can also solve the = reliability problem - outer bundle with reliability check (widely known key= ) that can be verified at each hop, inner bundle with secured contents read= able only by destination. Just like an IPsec EH packet in an Ethernet frame= with CRC that is checked by all switches... Dumping the fragment in a bundle for further transport discourages simply d= ropping fragments. Though the eventual reassembly and recursive patching to= gether of bundles of fragmented bundles of fragments of... could be interes= ting and processor-intensive, and identifying fragments that can be reassem= bled before the destination at an intermediate node is likely a lost cause. Encapsulation is the only behaviour that is sane, tractable, and debuggable= . Lloyd Wood http://sat-net.com/L.Wood/dtn/ ________________________________________ From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On Beha= lf Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] Sent: 15 April 2013 10:16 To: Amy Alford Cc: dtn-security Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions. Okay, this may or may not be optimal, but here's how I think the proposed n= ew BSP concepts might handle the fragmentation/security combinations: * The key rule we're working with is that you can never have more than o= ne occurrence of any single security activity (logical block, device, struc= ture -- essentially, either a single physical block or two cooperating phys= ical blocks) in any bundle bundle. * This implies that no ciphersuite or policy can require that a PIB or P= CB be added to a bundle that is a fragment (that is, a bundle whose payload= is a fragment of the payload of some original bundle with the same ID). T= hat's because the 5050 fragmentation rules require that any extension block= that precedes the payload of a bundle that is to be fragmented must be pre= served in the FIRST resulting fragment. That means that it is always possi= ble for a fragment to contain a payload BIB or BCB that pertains to the ori= ginal bundle -- not to itself -- and therefore in at least one case the add= ition of a fragment payload BIB would result in the bundle having two paylo= ad BIBs, a violation. * Therefore, in the event that you want to protect a fragmentary payload= with a BIB or BCB, the only way to do so is to encapsulate the fragment bu= ndle in an encapsulating, non-fragmentary bundle whose payload contains the= fragment -- and then attach a payload BIB and/or BCB that protects the enc= apsulating bundle's payload. * So if fragmentation occurs and you then want to add security blocks, t= he blocks will be added to encapsulating -- hence non-fragmentary -- bundle= s. So in order for reassembly to happen, all of the bundles encapsulating = the fragments need to be received at the same node. That node then necessa= rily has to be able to extract the fragment bundles from the payloads of th= e encapsulating bundles, and at that point you've got the pre-security frag= ments; reassembling the original bundle payload from those fragments should= be straightforward. * Since there are no security destinations in the proposed simplified BS= P spec, (a) the only hop-by-hop ciphersuites are the ones for BABs and (b) = it would be a configuration nightmare (though not impossible, I guess) to h= ave any non-BAB-capable nodes interposed between two nodes that are BAB nei= ghbors. If you do have a topology where you need any sort of hop-by-hop se= curity association other than adjacency, then you encapsulate; the destinat= ion of the encapsulating bundle is the intended "next hop" destination, and= now you're back in a non-problematic topology. I think the same principles address the other cases you identify. I'll admit that all of this encapsulation does seem a little heavyweight, b= ut in its defense I would argue that: * It's a simple mechanism that handles an unlimited range of cases (incl= uding, I think, cases that nobody has thought of yet) in a common, understa= ndable way that is completely compatible with RFC 5050. * The overhead of the extra primary block for the encapsulating bundle c= an be kept pretty low if you're using CBHE. * The cases we're talking about are entirely plausible for some operatio= nal environments, but for the bulk of secure DTN communications activity I = think they are not likely. It makes more sense, to me, to optimize overhe= ad for the common case so long as there's still a way to support all of the= more complex cases. Scott ________________________________ From: Amy Alford [aloomis@sarn.org] Sent: Sunday, April 14, 2013 1:50 PM To: Burleigh, Scott C (313B) Cc: Elwyn Davies; dtn-security Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions. 5050 allows any node to reassemble fragments. So, if fragmentation occurs = before security blocks are added, any subsequent node may then reassemble t= he bundle. Additionally, hop-by-hop ciphersuites may have intermediate non-security aw= are nodes. These can potentially fragment/reassemble, creating the same ov= erlapping fragmentation path/security path scenarios. The example I sent out earlier in response to Peter Lovell is still a possi= bility if you have a PIB ciphersuite that uses two blocks (one before the p= ayload and one after). BIBE does mitigate this, since we can use the "DO_N= OT_FRAGMENT" flag whenever we add a two block PIB, and then encapsulate. O= nce we've encapsulated, we can fragment again. There's a problem with enforcing the one logical security block of each typ= e/target per bundle rule if a bundle is reassembled by an intermediate node= . Security blocks may have been applied to different fragments which are th= en recombined in such a way that there is more than one logical security bl= ock of the same type/target. These may apply to overlapping payload region= s, or even the same payload region (depending on how the recombining node h= andles receiving duplicate fragments over different links). These are the cases I've thought of. I'm nervous that there's enough compl= exity in the intersection of fragmentation/encapsulation/BSP that it's hard= to be confident that all the possible combinations will work correctly. - Amy On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott C (313B) > wrote: Amy, I certainly agree on the potential for Bad Things happening when fragm= entation and security aren't cleanly nested. Can you say a little more abo= ut how the proposed new BSP draft's support for security sources could expo= se nodes to these problems? Scott ________________________________ From: dtn-security-bounces@irtf.org [= dtn-security-bounces@irtf.org] on beh= alf of Amy Alford [aloomis@sarn.org] Sent: Saturday, April 13, 2013 3:12 PM To: Elwyn Davies Cc: dtn-security Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions. If you think about a "fragmentation path" similar to a security path, whene= ver 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 v= alidate 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 s= unk because you can't validate the BSP blocks which apply to the whole payl= oad when you only have a fragment. In this case, you obviously need to rec= onstitute 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 probab= ly handle this with no changes), but avoids the first case because an encap= sulated fragment is not itself a fragment (so it can't be reconstituted unt= il 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 t= o handle non-security-aware nodes in the middle. On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies > 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 > wrote: > 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. > 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 From aloomis@sarn.org Tue Apr 16 17:54:18 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 0BED921F9768 for ; Tue, 16 Apr 2013 17:54:18 -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 JyZBBKfD5b-C for ; Tue, 16 Apr 2013 17:54:15 -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 AB59E21F942C for ; Tue, 16 Apr 2013 17:54:14 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id a22so497021qcs.26 for ; Tue, 16 Apr 2013 17:54:14 -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=u2AlXPsalkLgA6ROO58TVZloqSU7lRYsJw7S2S2t0YI=; b=cOk1xfFFdrUbSbInC2GUGbYOb+bJTvxNqiWNWmyOviCKwQO1RTN5IdAEq0Kp8pxADq yo0jMLA3ZKfeqwvb/13wLRVYKVB0iBmvrZUrma3bYfxcQkk+oe/wAIQrTPmKn6gjk9BO c1JbU2QLCkV6nrVCQkPOQ4ykorC0z8PVnqNNFct05B1eGmZAT9byUP/eKYRJfYpYjYkI iQENUSFlYw0vFw9emfFAS7q7Km/FjcB6wK7O+EeuN1m9guMN4o9IbhoEYn3XZr+CjDd4 VXMoDWLt0GC554FAu+lQlnKAkHYv2jW8pbX/axErcbJ16Oe9HE91SFNVqIDM+msBMR6P qbNQ== MIME-Version: 1.0 X-Received: by 10.229.135.10 with SMTP id l10mr1365967qct.82.1366160053933; Tue, 16 Apr 2013 17:54:13 -0700 (PDT) Received: by 10.49.2.41 with HTTP; Tue, 16 Apr 2013 17:54:13 -0700 (PDT) In-Reply-To: References: <20130320011114.1072992195@smtp.mail.me.com> <20130323005838.947157858@smtp.mail.me.com> <20130323213252.461319491@smtp.mail.me.com> <1365876632.5273.8820.camel@mightyatom> Date: Tue, 16 Apr 2013 20:54:13 -0400 Message-ID: From: Amy Alford To: "Burleigh, Scott C (313B)" Content-Type: multipart/alternative; boundary=00248c7690aab8b62d04da83ecdb X-Gm-Message-State: ALoCoQmG3SOkyFPj6qRjTgMAyiNNlp/Z45Avw1/G1coWvg1+GOANwyL+GJ6kCCmW57uLee0/1Amr Cc: dtn-security 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 00:54:18 -0000 --00248c7690aab8b62d04da83ecdb Content-Type: text/plain; charset=ISO-8859-1 I like the simplicity of this, but it brings up a concern I had with encapsulation. What happens to extension blocks attached to the encapsulating bundle on decapsulation? If they are simply thrown out, the age extension blocks aren't going to work. If we keep them around somehow, then we lose the simplicity of this approach. - Amy On Mon, Apr 15, 2013 at 5:16 AM, Burleigh, Scott C (313B) < scott.c.burleigh@jpl.nasa.gov> wrote: > Okay, this may or may not be optimal, but here's how I think the > proposed new BSP concepts might handle the fragmentation/security > combinations: > > - The key rule we're working with is that you can never have more than one > occurrence of any single security activity (logical block, device, > structure -- essentially, either a single physical block or two cooperating > physical blocks) in any bundle bundle. > - This implies that no ciphersuite or policy can require that a PIB or > PCB be added to a bundle that is a fragment (that is, a bundle whose > payload is a fragment of the payload of some original bundle with the same > ID). That's because the 5050 fragmentation rules require that any > extension block that precedes the payload of a bundle that is to be > fragmented must be preserved in the FIRST resulting fragment. That means > that it is always possible for a fragment to contain a payload BIB or BCB > that pertains to the original bundle -- not to itself -- and therefore in > at least one case the addition of a fragment payload BIB would result in > the bundle having two payload BIBs, a violation. > - Therefore, in the event that you want to protect a fragmentary > payload with a BIB or BCB, the only way to do so is to encapsulate the > fragment bundle in an encapsulating, non-fragmentary bundle whose payload > contains the fragment -- and then attach a payload BIB and/or BCB that > protects the encapsulating bundle's payload. > - So if fragmentation occurs and you then want to add security blocks, > the blocks will be added to encapsulating -- hence non-fragmentary -- > bundles. So in order for reassembly to happen, all of the bundles > encapsulating the fragments need to be received at the same node. That > node then necessarily has to be able to extract the fragment bundles from > the payloads of the encapsulating bundles, and at that point you've got the > pre-security fragments; reassembling the original bundle payload from those > fragments should be straightforward. > - Since there are no security destinations in the proposed simplified > BSP spec, (a) the only hop-by-hop ciphersuites are the ones for BABs and > (b) it would be a configuration nightmare (though not impossible, I guess) > to have any non-BAB-capable nodes interposed between two nodes that are BAB > neighbors. If you do have a topology where you need any sort of hop-by-hop > security association other than adjacency, then you encapsulate; the > destination of the encapsulating bundle is the intended "next hop" > destination, and now you're back in a non-problematic topology. > > I think the same principles address the other cases you identify. > > I'll admit that all of this encapsulation does seem a little > heavyweight, but in its defense I would argue that: > > - It's a simple mechanism that handles an unlimited range of cases > (including, I think, cases that nobody has thought of yet) in a common, > understandable way that is completely compatible with RFC 5050. > - The overhead of the extra primary block for the encapsulating bundle > can be kept pretty low if you're using CBHE. > - The cases we're talking about are entirely plausible for some > operational environments, but for the bulk of secure DTN communications > activity I think they are not likely. It makes more sense, to me, to > optimize overhead for the common case so long as there's still a way to > support all of the more complex cases. > > Scott > ------------------------------ > *From:* Amy Alford [aloomis@sarn.org] > *Sent:* Sunday, April 14, 2013 1:50 PM > *To:* Burleigh, Scott C (313B) > *Cc:* Elwyn Davies; dtn-security > > *Subject:* Re: [dtn-security] Re(4): Including fragment offset in the > correlator doesn't prevent all fragment collisions. > > 5050 allows any node to reassemble fragments. So, if fragmentation > occurs before security blocks are added, any subsequent node may then > reassemble the bundle. > > Additionally, hop-by-hop ciphersuites may have intermediate non-security > aware nodes. These can potentially fragment/reassemble, creating the same > overlapping fragmentation path/security path scenarios. > > The example I sent out earlier in response to Peter Lovell is still a > possibility if you have a PIB ciphersuite that uses two blocks (one before > the payload and one after). BIBE does mitigate this, since we can use the > "DO_NOT_FRAGMENT" flag whenever we add a two block PIB, and then > encapsulate. Once we've encapsulated, we can fragment again. > > There's a problem with enforcing the one logical security block of each > type/target per bundle rule if a bundle is reassembled by an intermediate > node. Security blocks may have been applied to different fragments which > are then recombined in such a way that there is more than one logical > security block of the same type/target. These may apply to overlapping > payload regions, or even the same payload region (depending on how the > recombining node handles receiving duplicate fragments over different > links). > > These are the cases I've thought of. I'm nervous that there's enough > complexity in the intersection of fragmentation/encapsulation/BSP that it's > hard to be confident that all the possible combinations will work correctly. > > - Amy > > > On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott C (313B) < > scott.c.burleigh@jpl.nasa.gov> wrote: > >> Amy, I certainly agree on the potential for Bad Things happening when >> fragmentation and security aren't cleanly nested. Can you say a little >> more about how the proposed new BSP draft's support for security sources >> could expose nodes to these problems? >> >> Scott >> ------------------------------ >> *From:* dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] on >> behalf of Amy Alford [aloomis@sarn.org] >> *Sent:* Saturday, April 13, 2013 3:12 PM >> *To:* Elwyn Davies >> *Cc:* dtn-security >> *Subject:* Re: [dtn-security] Re(4): Including fragment offset in the >> correlator doesn't prevent all fragment collisions. >> >> 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 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 wrote: >>> > 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. >>> > 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 >>> >>> >> > --00248c7690aab8b62d04da83ecdb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I like the simplicity of this, but it brings up a concern = I had with encapsulation. =A0What happens to extension blocks attached to t= he encapsulating bundle on decapsulation? =A0If they are simply thrown out,= the age extension blocks aren't going to work. =A0If we keep them arou= nd somehow, then we lose the simplicity of this approach.
- Amy




On Mon, Apr 15, 2013 at 5:16 AM, Burl= eigh, Scott C (313B) <scott.c.burleigh@jpl.nasa.gov> wrote:
Okay, this m= ay or may not be optimal, but here's how I think the proposed new BSP c= oncepts might handle the fragmentation/security combinations:
  • The key rule we're working with is that you can never have more tha= n=A0one occurrence of any single security ac= tivity (logical block, device, structure -- essentially, either a single ph= ysical block or two cooperating physical blocks) in any bundle bundle.
  • This implies that no ciphersu= ite or policy can require that a PIB or PCB be added to a bundle that is a = fragment (that is, a bundle whose payload is a fragment of the payload of s= ome original bundle with the same ID). =A0That's because the 5050 fragm= entation rules require that any extension block that precedes the payload of a bund= le that is to be fragmented must be preserved in the FIRST resulting fragme= nt. =A0That means that it is always possible for a fragment to contain a pa= yload BIB or BCB that pertains to the original bundle -- not to itself -- and therefore in at least one case= the addition of a fragment payload BIB would result in the bundle having t= wo payload BIBs, a violation.
  • Therefore, in the event that you want= to protect a fragmentary payload with a BIB or BCB, the only way to do so = is to encapsulate the fragment bundle in an encapsulating, non-fragmentary = bundle whose payload contains the fragment -- and then attach a payload BIB and/or BCB that protects the encapsulating bundle's payload.
    • <= li>So if fragmentation occurs and you then want to add security blocks, the= blocks will be added to encapsulating -- hence non-fragmentary -- bundles.= =A0So in order for reassembly to happen, all of the bundles encapsulating = the fragments need to be received at the same node. =A0That node then necessarily has to be able to extract = the fragment bundles from the payloads of the encapsulating bundles, and at= that point you've got the pre-security fragments; reassembling the ori= ginal bundle payload from those fragments should be straightforward.
  • Since there are no security destination= s in the proposed simplified BSP spec, (a) the only hop-by-hop ciphersuites= are the ones for BABs and (b) it would be a configuration nightmare (thoug= h not impossible, I guess) to have any non-BAB-capable nodes interposed between two nodes that are BAB neighbors. =A0If you do have a topology whe= re you need any sort of hop-by-hop security association other than adjacenc= y, then you encapsulate; the destination of the encapsulating bundle is the= intended "next hop" destination, and now you're back in a non-problematic topology.
I think the same principles address the othe= r cases you identify.

I'll admit that all of this encapsu= lation does seem a little heavyweight, but in its defense I would argue tha= t:
  • It's a simple mechanism that handles an unlimited range of cases (i= ncluding, I think, cases that nobody has thought of yet) in a common, under= standable way that is completely compatible with RFC 5050.
  • The over= head of the extra primary block for the encapsulating bundle can be kept pr= etty low if you're using CBHE.
  • The cases we're talking about are entirely plausible for some opera= tional environments, but for the bulk of secure DTN communications activity= I think they are not =A0likely. =A0It makes more sense, to me, to optimize= overhead for the common case so long as there's still a way to support all of the more complex cases.
Scott
Fro= m: Amy Alford [al= oomis@sarn.org]
Sent: Sunday, April 14, 2013 1:50 PM
To: Burleigh, Scott C (313B)
Cc: Elwyn Davies; dtn-security

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

5050 allows any node to reassemble fragments. =A0So, if fr= agmentation occurs before security blocks are added, any subsequent node ma= y then reassemble the bundle.

Additionally, hop-by-hop ciphersuites may have intermediate non-securi= ty aware nodes. =A0These can potentially fragment/reassemble, creating the = same overlapping fragmentation path/security path scenarios.

The example I sent out earlier in response to Peter Lovell is still a = possibility if you have a PIB ciphersuite that uses two blocks (one before = the payload and one after). =A0BIBE does mitigate this, since we can use th= e "DO_NOT_FRAGMENT" flag whenever we add a two block PIB, and then encapsulate. =A0Once we've encapsulat= ed, we can fragment again.

There's a problem with enforcing the one logical security block of= each type/target per bundle rule if a bundle is reassembled by an intermed= iate node. Security blocks may have been applied to different fragments whi= ch are then recombined in such a way that there is more than one logical security block of the same type/target= . =A0These may apply to overlapping payload regions, or even the same paylo= ad region (depending on how the recombining node handles receiving duplicat= e fragments over different links).

These are the cases I've thought of. =A0I'm nervous that there= 's enough complexity in the intersection of fragmentation/encapsulation= /BSP that it's hard to be confident that all the possible combinations = will work correctly.

- Amy


On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott= C (313B) <scott.c.burleigh@jpl.nasa.gov> wrote:
Amy, I certa= inly agree on the potential for Bad Things happening when fragmentation and= security aren't cleanly nested. =A0Can you say a little more about how= the proposed new BSP draft's support for security sources could expose nodes to these problems?

Scott
Fro= m: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] on behalf of = Amy Alford [aloomis@s= arn.org]
Sent: Saturday, April 13, 2013 3:12 PM
To: Elwyn Davies
Cc: dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the = correlator doesn't prevent all fragment collisions.

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

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. =A0Even 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 whi= ch apply to the whole payload when you only have a fragment. =A0In this cas= e, you obviously need to reconstitute the bundle before you remove the BSP blocks.

This doesn't even touch the headaches involved with multiple BSP i= nstances and multiple fragmentation.

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

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




On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies <elwynd@folly.o= rg.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. =A0I haven't looked in deta= il
into the code, but I suspect that there are some cases in which order
of delivery via the two different paths might lead to =A0the 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:
> =A0 =A0 =A0 =A0 Hi Amy,
>
> =A0 =A0 =A0 =A0 Amy Alford <aloomis@sarn.org> wrote:
>
> =A0 =A0 =A0 =A0 >Yes, my example was assuming a PIB ciphersuite tha= t used two
> =A0 =A0 =A0 =A0 blocks
> =A0 =A0 =A0 =A0 >(similar to BAB). =A0That case is the most problem= atic, because
> =A0 =A0 =A0 =A0 when the
> =A0 =A0 =A0 =A0 >bundle is fragmented, the two blocks will end up i= n separate
> =A0 =A0 =A0 =A0 fragments.
> =A0 =A0 =A0 =A0 > Otherwise, the correlator collision isn't a p= roblem as long
> =A0 =A0 =A0 =A0 as reassembly
> =A0 =A0 =A0 =A0 >happens at the destination.
>
> =A0 =A0 =A0 =A0 PIB is, in some ways, a more difficult scenario than P= CB. When
> =A0 =A0 =A0 =A0 a bundle with PCB arrives at the security-dest, the pa= yload is
> =A0 =A0 =A0 =A0 decrypted (and other blocks as appropriate) and the PC= B itself
> =A0 =A0 =A0 =A0 is deleted. But some folks want to have PIBs remain ev= en after
> =A0 =A0 =A0 =A0 verification, as evidence I guess. That is messy.
> Leaving PIBs on after verification is problematic anyway, if the PIB > was added after a PCB. =A0Once the PCB reaches it's security
> destination, the PIB is invalid anyhow.
>
>
> =A0 =A0 =A0 =A0 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. =A0I assume you'd still want an up front block to = warn
> nodes that are doing one pass processing that they need to start
> hashing.
>
>
> =A0 =A0 =A0 =A0 >> As you can see, this is a quite involved proc= ess. A couple
> =A0 =A0 =A0 =A0 of things are
> =A0 =A0 =A0 =A0 >> worthy of note:
> =A0 =A0 =A0 =A0 >> 1. correlators are local to their bundle
> =A0 =A0 =A0 =A0 >> 2. a block with a correlator may be encapsula= ted, with PCB
> =A0 =A0 =A0 =A0 for example.
> =A0 =A0 =A0 =A0 >> The original correlator is hidden until decap= sulation
> =A0 =A0 =A0 =A0 occurs (not shown
> =A0 =A0 =A0 =A0 >> above for sake of brevity :)
> =A0 =A0 =A0 =A0 >> 3. reassembly is a very, very complex process= .
> =A0 =A0 =A0 =A0 >>
> =A0 =A0 =A0 =A0 >I was pondering how to support these sorts of case= s (which
> =A0 =A0 =A0 =A0 end up needing
> =A0 =A0 =A0 =A0 >validation and reassembly interleaved somehow). = =A0In thinking
> =A0 =A0 =A0 =A0 about it, I
> =A0 =A0 =A0 =A0 >started running into scenarios that aren't sup= portable. =A0The
> =A0 =A0 =A0 =A0 example I gave
> =A0 =A0 =A0 =A0 >is one (which I think shows that bundles with two = block PIBs
> =A0 =A0 =A0 =A0 need to have
> =A0 =A0 =A0 =A0 >the do not fragment flag set).
> =A0 =A0 =A0 =A0 It may be sufficient to apply the
> =A0 =A0 =A0 =A0 replicate-key-info-in-every-block rule. I don't kn= ow without
> =A0 =A0 =A0 =A0 thinking about it some more.
>
>
> I think it would fix the example I gave. =A0The last fragment would > contain both the leading and trailing PIB blocks. =A0The leading block=
> could be used to match this up with the corresponding fragment (which<= br> > also has a leading PIB block but is missing the trailing one). =A0It > would be a pain in terms of processing, since defragmentation would > need to match up the corresponding fragments by comparing their
> leading PIB blocks.
>
>
>
>
> =A0 =A0 =A0 =A0 >Additionally, in general, if an intermediate node = reassembles
> =A0 =A0 =A0 =A0 fragments
> =A0 =A0 =A0 =A0 >that have had BSP blocks added after fragmentation= , we can't
> =A0 =A0 =A0 =A0 validate. =A0Too
> =A0 =A0 =A0 =A0 >much information is lost on reassembly (even if it= 's done
> =A0 =A0 =A0 =A0 sensibly). =A05050
> =A0 =A0 =A0 =A0 >allows intermediate nodes to reassemble, but doesn= 't mandate
> =A0 =A0 =A0 =A0 a procedure
> =A0 =A0 =A0 =A0 >for reassembling the extension blocks (so it may n= ot be done
> =A0 =A0 =A0 =A0 sensibly).
>
> =A0 =A0 =A0 =A0 It's not just an issue of reassembling/reordering = extension
> =A0 =A0 =A0 =A0 blocks. As the final example shows, any attempt to
> =A0 =A0 =A0 =A0 reassemble-first is doomed to failure because the two = parts
> =A0 =A0 =A0 =A0 were encrypted under different second-stage keys.
>
> =A0 =A0 =A0 =A0 It's clear to me that reassembly of bundles contai= ning
> =A0 =A0 =A0 =A0 security blocks must be done in concert with security<= br> > =A0 =A0 =A0 =A0 processing. This needs to be incorporated into any upd= ate to
> =A0 =A0 =A0 =A0 5050. And, as you say, there are cases that aren't= supportable
> =A0 =A0 =A0 =A0 with the capabilities we now have.
>
> Yes. =A0In general, nodes shouldn't reassemble a bundle if they do= n't
> understand all the extension blocks. =A0BSP aware nodes shouldn't<= br> > reassemble fragments except in concert with security processing.
>
>
>
>
> =A0 =A0 =A0 =A0 Regards.....Peter
>
>
> _______________________________________________
> dtn-security mailing list
> dtn-securit= y@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-security




--00248c7690aab8b62d04da83ecdb-- From scott.c.burleigh@jpl.nasa.gov Tue Apr 16 19:44:27 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 19BF221F96BA for ; Tue, 16 Apr 2013 19:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 r5+bTe1o5nVs for ; Tue, 16 Apr 2013 19:44:25 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9190621F93FB for ; Tue, 16 Apr 2013 19:44:08 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3H2i2Zh008761 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 16 Apr 2013 19:44:03 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.50]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.02.0342.003; Tue, 16 Apr 2013 19:44:04 -0700 From: "Burleigh, Scott C (313B)" To: Amy Alford Thread-Topic: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions. Thread-Index: AQHOKA4AwAq0n0zXUkuQfuDcUCFv7Zi3S36AgB2+HgCAAEOkAP//rp7ygAHM1ICAAEv8d4ADHLaA//+kIWo= Date: Wed, 17 Apr 2013 02:44:03 +0000 Message-ID: References: <20130320011114.1072992195@smtp.mail.me.com> <20130323005838.947157858@smtp.mail.me.com> <20130323213252.461319491@smtp.mail.me.com> <1365876632.5273.8820.camel@mightyatom> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.113] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Cc: dtn-security 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 02:44:27 -0000 I may be wrong, but I think the age extension blocks can still work, just b= ecause BIBE is a CLA. On output via BIBE you'd update the encapsulated bun= dle's age extension block just as if you were sending via TCP, and likewise= on "reception"/extraction. Sure, the encapsulated bundle might expire en = route (before extraction) but that's probably no great problem. You might = use its remaining time to live as the TTL for the encapsulating bundle to g= uard against this. But overall I think it works; am I overlooking somethin= g?=20 Scott ________________________________________ From: Amy Alford [aloomis@sarn.org] Sent: Tuesday, April 16, 2013 5:54 PM To: Burleigh, Scott C (313B) Cc: Elwyn Davies; dtn-security Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions. I like the simplicity of this, but it brings up a concern I had with encaps= ulation. What happens to extension blocks attached to the encapsulating bu= ndle on decapsulation? If they are simply thrown out, the age extension bl= ocks aren't going to work. If we keep them around somehow, then we lose th= e simplicity of this approach. - Amy On Mon, Apr 15, 2013 at 5:16 AM, Burleigh, Scott C (313B) > wrote: Okay, this may or may not be optimal, but here's how I think the proposed n= ew BSP concepts might handle the fragmentation/security combinations: * The key rule we're working with is that you can never have more than = one occurrence of any single security activity (logical block, device, stru= cture -- essentially, either a single physical block or two cooperating phy= sical blocks) in any bundle bundle. * This implies that no ciphersuite or policy can require that a PIB or = PCB be added to a bundle that is a fragment (that is, a bundle whose payloa= d is a fragment of the payload of some original bundle with the same ID). = That's because the 5050 fragmentation rules require that any extension bloc= k that precedes the payload of a bundle that is to be fragmented must be pr= eserved in the FIRST resulting fragment. That means that it is always poss= ible for a fragment to contain a payload BIB or BCB that pertains to the or= iginal bundle -- not to itself -- and therefore in at least one case the ad= dition of a fragment payload BIB would result in the bundle having two payl= oad BIBs, a violation. * Therefore, in the event that you want to protect a fragmentary payloa= d with a BIB or BCB, the only way to do so is to encapsulate the fragment b= undle in an encapsulating, non-fragmentary bundle whose payload contains th= e fragment -- and then attach a payload BIB and/or BCB that protects the en= capsulating bundle's payload. * So if fragmentation occurs and you then want to add security blocks, = the blocks will be added to encapsulating -- hence non-fragmentary -- bundl= es. So in order for reassembly to happen, all of the bundles encapsulating= the fragments need to be received at the same node. That node then necess= arily has to be able to extract the fragment bundles from the payloads of t= he encapsulating bundles, and at that point you've got the pre-security fra= gments; reassembling the original bundle payload from those fragments shoul= d be straightforward. * Since there are no security destinations in the proposed simplified B= SP spec, (a) the only hop-by-hop ciphersuites are the ones for BABs and (b)= it would be a configuration nightmare (though not impossible, I guess) to = have any non-BAB-capable nodes interposed between two nodes that are BAB ne= ighbors. If you do have a topology where you need any sort of hop-by-hop s= ecurity association other than adjacency, then you encapsulate; the destina= tion of the encapsulating bundle is the intended "next hop" destination, an= d now you're back in a non-problematic topology. I think the same principles address the other cases you identify. I'll admit that all of this encapsulation does seem a little heavyweight, b= ut in its defense I would argue that: * It's a simple mechanism that handles an unlimited range of cases (inc= luding, I think, cases that nobody has thought of yet) in a common, underst= andable way that is completely compatible with RFC 5050. * The overhead of the extra primary block for the encapsulating bundle = can be kept pretty low if you're using CBHE. * The cases we're talking about are entirely plausible for some operati= onal environments, but for the bulk of secure DTN communications activity I= think they are not likely. It makes more sense, to me, to optimize overh= ead for the common case so long as there's still a way to support all of th= e more complex cases. Scott ________________________________ From: Amy Alford [aloomis@sarn.org] Sent: Sunday, April 14, 2013 1:50 PM To: Burleigh, Scott C (313B) Cc: Elwyn Davies; dtn-security Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions. 5050 allows any node to reassemble fragments. So, if fragmentation occurs = before security blocks are added, any subsequent node may then reassemble t= he bundle. Additionally, hop-by-hop ciphersuites may have intermediate non-security aw= are nodes. These can potentially fragment/reassemble, creating the same ov= erlapping fragmentation path/security path scenarios. The example I sent out earlier in response to Peter Lovell is still a possi= bility if you have a PIB ciphersuite that uses two blocks (one before the p= ayload and one after). BIBE does mitigate this, since we can use the "DO_N= OT_FRAGMENT" flag whenever we add a two block PIB, and then encapsulate. O= nce we've encapsulated, we can fragment again. There's a problem with enforcing the one logical security block of each typ= e/target per bundle rule if a bundle is reassembled by an intermediate node= . Security blocks may have been applied to different fragments which are th= en recombined in such a way that there is more than one logical security bl= ock of the same type/target. These may apply to overlapping payload region= s, or even the same payload region (depending on how the recombining node h= andles receiving duplicate fragments over different links). These are the cases I've thought of. I'm nervous that there's enough compl= exity in the intersection of fragmentation/encapsulation/BSP that it's hard= to be confident that all the possible combinations will work correctly. - Amy On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott C (313B) > wrote: Amy, I certainly agree on the potential for Bad Things happening when fragm= entation and security aren't cleanly nested. Can you say a little more abo= ut how the proposed new BSP draft's support for security sources could expo= se nodes to these problems? Scott ________________________________ From: dtn-security-bounces@irtf.org [= dtn-security-bounces@irtf.org] on beh= alf of Amy Alford [aloomis@sarn.org] Sent: Saturday, April 13, 2013 3:12 PM To: Elwyn Davies Cc: dtn-security Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions. If you think about a "fragmentation path" similar to a security path, whene= ver 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 v= alidate 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 s= unk because you can't validate the BSP blocks which apply to the whole payl= oad when you only have a fragment. In this case, you obviously need to rec= onstitute 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 probab= ly handle this with no changes), but avoids the first case because an encap= sulated fragment is not itself a fragment (so it can't be reconstituted unt= il 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 t= o handle non-security-aware nodes in the middle. On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies > 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 > wrote: > 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. > 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 From scott.c.burleigh@jpl.nasa.gov Wed Apr 17 02:54:29 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 80C8021F8D82 for ; Wed, 17 Apr 2013 02:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UN9gtZMNfeU9 for ; Wed, 17 Apr 2013 02:54:24 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 878BA21F8D90 for ; Wed, 17 Apr 2013 02:54:22 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3H9sKMd023549 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 17 Apr 2013 02:54:21 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.50]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.100]) with mapi id 14.02.0342.003; Wed, 17 Apr 2013 02:54:20 -0700 From: "Burleigh, Scott C (313B)" To: "l.wood@surrey.ac.uk" , "aloomis@sarn.org" Thread-Topic: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions. Thread-Index: AQHOKA4AwAq0n0zXUkuQfuDcUCFv7Zi3S36AgB2+HgCAAEOkAP//rp7ygAHM1ICAAEv8d4ABsdVPgAGLOII= Date: Wed, 17 Apr 2013 09:54:19 +0000 Message-ID: References: <20130320011114.1072992195@smtp.mail.me.com> <20130323005838.947157858@smtp.mail.me.com> <20130323213252.461319491@smtp.mail.me.com> <1365876632.5273.8820.camel@mightyatom> , , , <290E20B455C66743BE178C5C84F12408223F494E66@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F12408223F494E66@EXMB01CMS.surrey.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Cc: "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 09:54:29 -0000 Thanks, Lloyd, I'm glad we agree on this. And I think you're right, the "o= uter packet" mechanism might well make integrity checking more straightforw= ard throughout.=0A= =0A= Scott=0A= ________________________________________=0A= From: l.wood@surrey.ac.uk [l.wood@surrey.ac.uk]=0A= Sent: Tuesday, April 16, 2013 3:26 AM=0A= To: Burleigh, Scott C (313B); aloomis@sarn.org=0A= Cc: dtn-security@irtf.org=0A= Subject: RE: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions.=0A= =0A= You're going to need to pursue this fragment-in-bundle and bundle-in-bundle= nesting.=0A= =0A= As well as simplifying the handling, this encapsulation can also solve the = reliability problem - outer bundle with reliability check (widely known key= ) that can be verified at each hop, inner bundle with secured contents read= able only by destination. Just like an IPsec EH packet in an Ethernet frame= with CRC that is checked by all switches...=0A= =0A= Dumping the fragment in a bundle for further transport discourages simply d= ropping fragments. Though the eventual reassembly and recursive patching to= gether of bundles of fragmented bundles of fragments of... could be interes= ting and processor-intensive, and identifying fragments that can be reassem= bled before the destination at an intermediate node is likely a lost cause.= =0A= =0A= Encapsulation is the only behaviour that is sane, tractable, and debuggable= .=0A= =0A= Lloyd Wood=0A= http://sat-net.com/L.Wood/dtn/=0A= =0A= =0A= ________________________________________=0A= From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On Beha= lf Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov]=0A= Sent: 15 April 2013 10:16=0A= To: Amy Alford=0A= Cc: dtn-security=0A= Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions.=0A= =0A= Okay, this may or may not be optimal, but here's how I think the proposed n= ew BSP concepts might handle the fragmentation/security combinations:=0A= =0A= * The key rule we're working with is that you can never have more than o= ne occurrence of any single security activity (logical block, device, struc= ture -- essentially, either a single physical block or two cooperating phys= ical blocks) in any bundle bundle.=0A= * This implies that no ciphersuite or policy can require that a PIB or P= CB be added to a bundle that is a fragment (that is, a bundle whose payload= is a fragment of the payload of some original bundle with the same ID). T= hat's because the 5050 fragmentation rules require that any extension block= that precedes the payload of a bundle that is to be fragmented must be pre= served in the FIRST resulting fragment. That means that it is always possi= ble for a fragment to contain a payload BIB or BCB that pertains to the ori= ginal bundle -- not to itself -- and therefore in at least one case the add= ition of a fragment payload BIB would result in the bundle having two paylo= ad BIBs, a violation.=0A= * Therefore, in the event that you want to protect a fragmentary payload= with a BIB or BCB, the only way to do so is to encapsulate the fragment bu= ndle in an encapsulating, non-fragmentary bundle whose payload contains the= fragment -- and then attach a payload BIB and/or BCB that protects the enc= apsulating bundle's payload.=0A= * So if fragmentation occurs and you then want to add security blocks, t= he blocks will be added to encapsulating -- hence non-fragmentary -- bundle= s. So in order for reassembly to happen, all of the bundles encapsulating = the fragments need to be received at the same node. That node then necessa= rily has to be able to extract the fragment bundles from the payloads of th= e encapsulating bundles, and at that point you've got the pre-security frag= ments; reassembling the original bundle payload from those fragments should= be straightforward.=0A= * Since there are no security destinations in the proposed simplified BS= P spec, (a) the only hop-by-hop ciphersuites are the ones for BABs and (b) = it would be a configuration nightmare (though not impossible, I guess) to h= ave any non-BAB-capable nodes interposed between two nodes that are BAB nei= ghbors. If you do have a topology where you need any sort of hop-by-hop se= curity association other than adjacency, then you encapsulate; the destinat= ion of the encapsulating bundle is the intended "next hop" destination, and= now you're back in a non-problematic topology.=0A= =0A= I think the same principles address the other cases you identify.=0A= =0A= I'll admit that all of this encapsulation does seem a little heavyweight, b= ut in its defense I would argue that:=0A= =0A= * It's a simple mechanism that handles an unlimited range of cases (incl= uding, I think, cases that nobody has thought of yet) in a common, understa= ndable way that is completely compatible with RFC 5050.=0A= * The overhead of the extra primary block for the encapsulating bundle c= an be kept pretty low if you're using CBHE.=0A= * The cases we're talking about are entirely plausible for some operatio= nal environments, but for the bulk of secure DTN communications activity I = think they are not likely. It makes more sense, to me, to optimize overhe= ad for the common case so long as there's still a way to support all of the= more complex cases.=0A= =0A= Scott=0A= ________________________________=0A= From: Amy Alford [aloomis@sarn.org]=0A= Sent: Sunday, April 14, 2013 1:50 PM=0A= To: Burleigh, Scott C (313B)=0A= Cc: Elwyn Davies; dtn-security=0A= Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions.=0A= =0A= 5050 allows any node to reassemble fragments. So, if fragmentation occurs = before security blocks are added, any subsequent node may then reassemble t= he bundle.=0A= =0A= Additionally, hop-by-hop ciphersuites may have intermediate non-security aw= are nodes. These can potentially fragment/reassemble, creating the same ov= erlapping fragmentation path/security path scenarios.=0A= =0A= The example I sent out earlier in response to Peter Lovell is still a possi= bility if you have a PIB ciphersuite that uses two blocks (one before the p= ayload and one after). BIBE does mitigate this, since we can use the "DO_N= OT_FRAGMENT" flag whenever we add a two block PIB, and then encapsulate. O= nce we've encapsulated, we can fragment again.=0A= =0A= There's a problem with enforcing the one logical security block of each typ= e/target per bundle rule if a bundle is reassembled by an intermediate node= . Security blocks may have been applied to different fragments which are th= en recombined in such a way that there is more than one logical security bl= ock of the same type/target. These may apply to overlapping payload region= s, or even the same payload region (depending on how the recombining node h= andles receiving duplicate fragments over different links).=0A= =0A= These are the cases I've thought of. I'm nervous that there's enough compl= exity in the intersection of fragmentation/encapsulation/BSP that it's hard= to be confident that all the possible combinations will work correctly.=0A= =0A= - Amy=0A= =0A= =0A= On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott C (313B) > wrote:=0A= Amy, I certainly agree on the potential for Bad Things happening when fragm= entation and security aren't cleanly nested. Can you say a little more abo= ut how the proposed new BSP draft's support for security sources could expo= se nodes to these problems?=0A= =0A= Scott=0A= ________________________________=0A= From: dtn-security-bounces@irtf.org [= dtn-security-bounces@irtf.org] on beh= alf of Amy Alford [aloomis@sarn.org]=0A= Sent: Saturday, April 13, 2013 3:12 PM=0A= To: Elwyn Davies=0A= Cc: dtn-security=0A= Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions.=0A= =0A= If you think about a "fragmentation path" similar to a security path, whene= ver fragmentation paths and security paths overlap (instead of one nesting = inside the other), Bad Things (TM) are probably going to happen in DTN2.=0A= =0A= If it's fragment -> add bsp -> defragment -> remove bsp, you're up against = the fact that defragmentation doesn't necessarily preserve enough info to v= alidate 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.=0A= =0A= If it's add bsp -> fragment -> remove bsp -> defragment, you're obviously s= unk because you can't validate the BSP blocks which apply to the whole payl= oad when you only have a fragment. In this case, you obviously need to rec= onstitute the bundle before you remove the BSP blocks.=0A= =0A= This doesn't even touch the headaches involved with multiple BSP instances = and multiple fragmentation.=0A= =0A= BiB will need to deal with the second case (the easy one - DTN2 will probab= ly handle this with no changes), but avoids the first case because an encap= sulated fragment is not itself a fragment (so it can't be reconstituted unt= il after it's been decapsulated).=0A= =0A= 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 t= o handle non-security-aware nodes in the middle.=0A= =0A= =0A= =0A= =0A= On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies > wrote:=0A= Hi.=0A= =0A= It just occurred to me that the way DTN2 handles fragment payloads=0A= probably gets very screwed up if two paths either with different=0A= encrypted security tunnels or with one encrypted and one unencrypted=0A= converge at some point after fragmentation. I haven't looked in detail=0A= into the code, but I suspect that there are some cases in which order=0A= of delivery via the two different paths might lead to the payload=0A= getting a mix of data from the two sources and becoming unintelligible.=0A= =0A= Not certaim if I am right, but may be another argument for using b-i-b=0A= encapsulation.=0A= =0A= Regards,=0A= Elwyn=0A= =0A= On Mon, 2013-03-25 at 15:58 -0400, Amy Alford wrote:=0A= >=0A= >=0A= > On Sat, Mar 23, 2013 at 5:32 PM, Peter Lovell > wrote:=0A= > Hi Amy,=0A= >=0A= > Amy Alford > wrote:=0A= >=0A= > >Yes, my example was assuming a PIB ciphersuite that used two=0A= > blocks=0A= > >(similar to BAB). That case is the most problematic, because=0A= > when the=0A= > >bundle is fragmented, the two blocks will end up in separate=0A= > fragments.=0A= > > Otherwise, the correlator collision isn't a problem as long=0A= > as reassembly=0A= > >happens at the destination.=0A= >=0A= > PIB is, in some ways, a more difficult scenario than PCB. When=0A= > a bundle with PCB arrives at the security-dest, the payload is=0A= > decrypted (and other blocks as appropriate) and the PCB itself=0A= > is deleted. But some folks want to have PIBs remain even after=0A= > verification, as evidence I guess. That is messy.=0A= > Leaving PIBs on after verification is problematic anyway, if the PIB=0A= > was added after a PCB. Once the PCB reaches it's security=0A= > destination, the PIB is invalid anyhow.=0A= >=0A= >=0A= > Is there a specific reason for a two-block PIB?=0A= >=0A= > 6257 mentions the idea of PIB ciphersuites that use a trailing block=0A= > similar to BAB. I assume you'd still want an up front block to warn=0A= > nodes that are doing one pass processing that they need to start=0A= > hashing.=0A= >=0A= >=0A= > >> As you can see, this is a quite involved process. A couple=0A= > of things are=0A= > >> worthy of note:=0A= > >> 1. correlators are local to their bundle=0A= > >> 2. a block with a correlator may be encapsulated, with PCB=0A= > for example.=0A= > >> The original correlator is hidden until decapsulation=0A= > occurs (not shown=0A= > >> above for sake of brevity :)=0A= > >> 3. reassembly is a very, very complex process.=0A= > >>=0A= > >I was pondering how to support these sorts of cases (which=0A= > end up needing=0A= > >validation and reassembly interleaved somehow). In thinking=0A= > about it, I=0A= > >started running into scenarios that aren't supportable. The=0A= > example I gave=0A= > >is one (which I think shows that bundles with two block PIBs=0A= > need to have=0A= > >the do not fragment flag set).=0A= > It may be sufficient to apply the=0A= > replicate-key-info-in-every-block rule. I don't know without=0A= > thinking about it some more.=0A= >=0A= >=0A= > I think it would fix the example I gave. The last fragment would=0A= > contain both the leading and trailing PIB blocks. The leading block=0A= > could be used to match this up with the corresponding fragment (which=0A= > also has a leading PIB block but is missing the trailing one). It=0A= > would be a pain in terms of processing, since defragmentation would=0A= > need to match up the corresponding fragments by comparing their=0A= > leading PIB blocks.=0A= >=0A= >=0A= >=0A= >=0A= > >Additionally, in general, if an intermediate node reassembles=0A= > fragments=0A= > >that have had BSP blocks added after fragmentation, we can't=0A= > validate. Too=0A= > >much information is lost on reassembly (even if it's done=0A= > sensibly). 5050=0A= > >allows intermediate nodes to reassemble, but doesn't mandate=0A= > a procedure=0A= > >for reassembling the extension blocks (so it may not be done=0A= > sensibly).=0A= >=0A= > It's not just an issue of reassembling/reordering extension=0A= > blocks. As the final example shows, any attempt to=0A= > reassemble-first is doomed to failure because the two parts=0A= > were encrypted under different second-stage keys.=0A= >=0A= > It's clear to me that reassembly of bundles containing=0A= > security blocks must be done in concert with security=0A= > processing. This needs to be incorporated into any update to=0A= > 5050. And, as you say, there are cases that aren't supportable=0A= > with the capabilities we now have.=0A= >=0A= > Yes. In general, nodes shouldn't reassemble a bundle if they don't=0A= > understand all the extension blocks. BSP aware nodes shouldn't=0A= > reassemble fragments except in concert with security processing.=0A= >=0A= >=0A= >=0A= >=0A= > Regards.....Peter=0A= >=0A= >=0A= > _______________________________________________=0A= > dtn-security mailing list=0A= > dtn-security@irtf.org=0A= > https://www.irtf.org/mailman/listinfo/dtn-security=0A= =0A= =0A= =0A= From aloomis@sarn.org Wed Apr 17 11:49:59 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 AF9CC21E8055 for ; Wed, 17 Apr 2013 11:49:59 -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 HuCEuqj2yJ72 for ; Wed, 17 Apr 2013 11:49:57 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5452321E8085 for ; Wed, 17 Apr 2013 11:49:57 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id d10so855590qca.23 for ; Wed, 17 Apr 2013 11:49:56 -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=sF0RXR9lZ8NRu8lVuB5kNTPrcW7s0TcN14kWPfBCIgs=; b=SCVfpodN1ORmGn3Iw+NkmxnnQ6WAxvsX7f8Rr6knH8Dn5h7P+Cl9CdPc8nqJjLMuD6 p3QLutnXVqP4Hfmj9t10bzhO0Oy1nPZCiKDHSug1X5WyG12MLc6hbZ4mPvYoGuZAQGeq T7ZrirzuUAgjDI9W5f59LZuGPsm3nkDqKagTRy4BN/aWIROSnShJB2C17RkCkGUneqIh PRZ6i7e0wIwNQ266Pzm1uBa8zfxTWKsEgA7rdLxtPCfJUs7HWCUgpMdfUE97Vr7H7qDR br9Rd2Bo3xuykDZ/558EkQ2joqml4sG6RJyOTZqgXs1qaS7eKV9bSx6SSulhM63vfSvX dsKg== MIME-Version: 1.0 X-Received: by 10.49.49.72 with SMTP id s8mr8417358qen.54.1366224596471; Wed, 17 Apr 2013 11:49:56 -0700 (PDT) Received: by 10.49.2.41 with HTTP; Wed, 17 Apr 2013 11:49:56 -0700 (PDT) In-Reply-To: References: <20130320011114.1072992195@smtp.mail.me.com> <20130323005838.947157858@smtp.mail.me.com> <20130323213252.461319491@smtp.mail.me.com> <1365876632.5273.8820.camel@mightyatom> Date: Wed, 17 Apr 2013 14:49:56 -0400 Message-ID: From: Amy Alford To: "Burleigh, Scott C (313B)" Content-Type: multipart/alternative; boundary=047d7b67809ec1c5dd04da92f396 X-Gm-Message-State: ALoCoQk9/UyNAsQ6vMDCwda6ynJkIJ6/NEhYtGIJqVQ7n4oKa5PTzuFit2dLKADzrmAGGW9Cbv17 Cc: dtn-security 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 18:49:59 -0000 --047d7b67809ec1c5dd04da92f396 Content-Type: text/plain; charset=ISO-8859-1 Ok, I hadn't read the age block spec before now. The spec says CLA's should provide BPAs with information to use in updating the age block. So, you're saying that BIBE is a CLA, so it should pass along info about how long the encapsulated bundle was in transit. It would get that information from either the creation timestamp on the encapsulating bundle or the age block attached to the encapsulating bundle. That makes sense. Are there any other extension blocks that may be added to an encapsulating bundle that it would be a problem to just throw out? - Amy On Tue, Apr 16, 2013 at 10:44 PM, Burleigh, Scott C (313B) < scott.c.burleigh@jpl.nasa.gov> wrote: > I may be wrong, but I think the age extension blocks can still work, just > because BIBE is a CLA. On output via BIBE you'd update the encapsulated > bundle's age extension block just as if you were sending via TCP, and > likewise on "reception"/extraction. Sure, the encapsulated bundle might > expire en route (before extraction) but that's probably no great problem. > You might use its remaining time to live as the TTL for the encapsulating > bundle to guard against this. But overall I think it works; am I > overlooking something? > > Scott > ________________________________________ > From: Amy Alford [aloomis@sarn.org] > Sent: Tuesday, April 16, 2013 5:54 PM > To: Burleigh, Scott C (313B) > Cc: Elwyn Davies; dtn-security > Subject: Re: [dtn-security] Re(4): Including fragment offset in the > correlator doesn't prevent all fragment collisions. > > I like the simplicity of this, but it brings up a concern I had with > encapsulation. What happens to extension blocks attached to the > encapsulating bundle on decapsulation? If they are simply thrown out, the > age extension blocks aren't going to work. If we keep them around somehow, > then we lose the simplicity of this approach. > - Amy > > > > > On Mon, Apr 15, 2013 at 5:16 AM, Burleigh, Scott C (313B) < > scott.c.burleigh@jpl.nasa.gov> > wrote: > Okay, this may or may not be optimal, but here's how I think the proposed > new BSP concepts might handle the fragmentation/security combinations: > > * The key rule we're working with is that you can never have more than > one occurrence of any single security activity (logical block, device, > structure -- essentially, either a single physical block or two cooperating > physical blocks) in any bundle bundle. > * This implies that no ciphersuite or policy can require that a PIB or > PCB be added to a bundle that is a fragment (that is, a bundle whose > payload is a fragment of the payload of some original bundle with the same > ID). That's because the 5050 fragmentation rules require that any > extension block that precedes the payload of a bundle that is to be > fragmented must be preserved in the FIRST resulting fragment. That means > that it is always possible for a fragment to contain a payload BIB or BCB > that pertains to the original bundle -- not to itself -- and therefore in > at least one case the addition of a fragment payload BIB would result in > the bundle having two payload BIBs, a violation. > * Therefore, in the event that you want to protect a fragmentary > payload with a BIB or BCB, the only way to do so is to encapsulate the > fragment bundle in an encapsulating, non-fragmentary bundle whose payload > contains the fragment -- and then attach a payload BIB and/or BCB that > protects the encapsulating bundle's payload. > * So if fragmentation occurs and you then want to add security blocks, > the blocks will be added to encapsulating -- hence non-fragmentary -- > bundles. So in order for reassembly to happen, all of the bundles > encapsulating the fragments need to be received at the same node. That > node then necessarily has to be able to extract the fragment bundles from > the payloads of the encapsulating bundles, and at that point you've got the > pre-security fragments; reassembling the original bundle payload from those > fragments should be straightforward. > * Since there are no security destinations in the proposed simplified > BSP spec, (a) the only hop-by-hop ciphersuites are the ones for BABs and > (b) it would be a configuration nightmare (though not impossible, I guess) > to have any non-BAB-capable nodes interposed between two nodes that are BAB > neighbors. If you do have a topology where you need any sort of hop-by-hop > security association other than adjacency, then you encapsulate; the > destination of the encapsulating bundle is the intended "next hop" > destination, and now you're back in a non-problematic topology. > > I think the same principles address the other cases you identify. > > I'll admit that all of this encapsulation does seem a little heavyweight, > but in its defense I would argue that: > > * It's a simple mechanism that handles an unlimited range of cases > (including, I think, cases that nobody has thought of yet) in a common, > understandable way that is completely compatible with RFC 5050. > * The overhead of the extra primary block for the encapsulating bundle > can be kept pretty low if you're using CBHE. > * The cases we're talking about are entirely plausible for some > operational environments, but for the bulk of secure DTN communications > activity I think they are not likely. It makes more sense, to me, to > optimize overhead for the common case so long as there's still a way to > support all of the more complex cases. > > Scott > ________________________________ > From: Amy Alford [aloomis@sarn.org] > Sent: Sunday, April 14, 2013 1:50 PM > To: Burleigh, Scott C (313B) > Cc: Elwyn Davies; dtn-security > > Subject: Re: [dtn-security] Re(4): Including fragment offset in the > correlator doesn't prevent all fragment collisions. > > 5050 allows any node to reassemble fragments. So, if fragmentation occurs > before security blocks are added, any subsequent node may then reassemble > the bundle. > > Additionally, hop-by-hop ciphersuites may have intermediate non-security > aware nodes. These can potentially fragment/reassemble, creating the same > overlapping fragmentation path/security path scenarios. > > The example I sent out earlier in response to Peter Lovell is still a > possibility if you have a PIB ciphersuite that uses two blocks (one before > the payload and one after). BIBE does mitigate this, since we can use the > "DO_NOT_FRAGMENT" flag whenever we add a two block PIB, and then > encapsulate. Once we've encapsulated, we can fragment again. > > There's a problem with enforcing the one logical security block of each > type/target per bundle rule if a bundle is reassembled by an intermediate > node. Security blocks may have been applied to different fragments which > are then recombined in such a way that there is more than one logical > security block of the same type/target. These may apply to overlapping > payload regions, or even the same payload region (depending on how the > recombining node handles receiving duplicate fragments over different > links). > > These are the cases I've thought of. I'm nervous that there's enough > complexity in the intersection of fragmentation/encapsulation/BSP that it's > hard to be confident that all the possible combinations will work correctly. > > - Amy > > > On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott C (313B) < > scott.c.burleigh@jpl.nasa.gov> > wrote: > Amy, I certainly agree on the potential for Bad Things happening when > fragmentation and security aren't cleanly nested. Can you say a little > more about how the proposed new BSP draft's support for security sources > could expose nodes to these problems? > > Scott > ________________________________ > From: dtn-security-bounces@irtf.org > [dtn-security-bounces@irtf.org] on > behalf of Amy Alford [aloomis@sarn.org] > Sent: Saturday, April 13, 2013 3:12 PM > To: Elwyn Davies > Cc: dtn-security > Subject: Re: [dtn-security] Re(4): Including fragment offset in the > correlator doesn't prevent all fragment collisions. > > 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 > 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 > > > > > --047d7b67809ec1c5dd04da92f396 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ok, I hadn't read the age block spec before now. The s= pec says CLA's should provide BPAs with information to use in updating = the age block. =A0So, you're saying that BIBE is a CLA, so it should pa= ss along info about how long the encapsulated bundle was in transit. =A0It = would get that information from either the creation timestamp on the encaps= ulating bundle or the age block attached to the encapsulating bundle. =A0
That makes sense. =A0Are there any other extension blo= cks that may be added to an encapsulating bundle that it would be a problem= to just throw out?
- Amy


On Tue, Apr 16, 2013 at 10:44 PM, Burlei= gh, Scott C (313B) <scott.c.burleigh@jpl.nasa.gov> wrote:
I may be wrong, but I think the age extensio= n blocks can still work, just because BIBE is a CLA. =A0On output via BIBE = you'd update the encapsulated bundle's age extension block just as = if you were sending via TCP, and likewise on "reception"/extracti= on. =A0Sure, the encapsulated bundle might expire en route (before extracti= on) but that's probably no great problem. =A0You might use its remainin= g time to live as the TTL for the encapsulating bundle to guard against thi= s. =A0But overall I think it works; am I overlooking something?

Scott
________________________________________
From: Amy Alford [aloomis@sarn.org]=
Sent: Tuesday, April 16, 2013 5:54 PM
To: Burleigh, Scott C (313B)
Cc: Elwyn Davies; dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions.

I like the simplicity of this, but it brings up a c= oncern I had with encapsulation. =A0What happens to extension blocks attach= ed to the encapsulating bundle on decapsulation? =A0If they are simply thro= wn out, the age extension blocks aren't going to work. =A0If we keep th= em around somehow, then we lose the simplicity of this approach.
- Amy




On Mon, Apr 15, 2013 at 5:16 AM, Burleigh, Scott C = (313B) <scott.c.burleig= h@jpl.nasa.gov<mailto:scott.c.burleigh@jpl.nasa.gov>> wrote:
Okay, this may or may not be optimal, but here's how I think the propos= ed new BSP concepts might handle the fragmentation/security combinations:
=A0 * =A0 The key rule we're working with is that you can never h= ave more than one occurrence of any single security activity (logical block= , device, structure -- essentially, either a single physical block or two c= ooperating physical blocks) in any bundle bundle.
=A0 * =A0 This implies that no ciphersuite or policy can require that a PIB= or PCB be added to a bundle that is a fragment (that is, a bundle whose pa= yload is a fragment of the payload of some original bundle with the same ID= ). =A0That's because the 5050 fragmentation rules require that any exte= nsion block that precedes the payload of a bundle that is to be fragmented = must be preserved in the FIRST resulting fragment. =A0That means that it is= always possible for a fragment to contain a payload BIB or BCB that pertai= ns to the original bundle -- not to itself -- and therefore in at least one= case the addition of a fragment payload BIB would result in the bundle hav= ing two payload BIBs, a violation.
=A0 * =A0 Therefore, in the event that you want to protect a fragmentary pa= yload with a BIB or BCB, the only way to do so is to encapsulate the fragme= nt bundle in an encapsulating, non-fragmentary bundle whose payload contain= s the fragment -- and then attach a payload BIB and/or BCB that protects th= e encapsulating bundle's payload.
=A0 * =A0 So if fragmentation occurs and you then want to add security bloc= ks, the blocks will be added to encapsulating -- hence non-fragmentary -- b= undles. =A0So in order for reassembly to happen, all of the bundles encapsu= lating the fragments need to be received at the same node. =A0That node the= n necessarily has to be able to extract the fragment bundles from the paylo= ads of the encapsulating bundles, and at that point you've got the pre-= security fragments; reassembling the original bundle payload from those fra= gments should be straightforward.
=A0 * =A0 Since there are no security destinations in the proposed simplifi= ed BSP spec, (a) the only hop-by-hop ciphersuites are the ones for BABs and= (b) it would be a configuration nightmare (though not impossible, I guess)= to have any non-BAB-capable nodes interposed between two nodes that are BA= B neighbors. =A0If you do have a topology where you need any sort of hop-by= -hop security association other than adjacency, then you encapsulate; the d= estination of the encapsulating bundle is the intended "next hop"= destination, and now you're back in a non-problematic topology.

I think the same principles address the other cases you identify.

I'll admit that all of this encapsulation does seem a little heavyweigh= t, but in its defense I would argue that:

=A0 * =A0 It's a simple mechanism that handles an unlimited range= of cases (including, I think, cases that nobody has thought of yet) in a c= ommon, understandable way that is completely compatible with RFC 5050.
=A0 * =A0 The overhead of the extra primary block for the encapsulating bun= dle can be kept pretty low if you're using CBHE.
=A0 * =A0 The cases we're talking about are entirely plausible for some= operational environments, but for the bulk of secure DTN communications ac= tivity I think they are not =A0likely. =A0It makes more sense, to me, to op= timize overhead for the common case so long as there's still a way to s= upport all of the more complex cases.

Scott
________________________________
From: Amy Alford [aloomis@sarn.org&= lt;mailto:aloomis@sarn.org>]
Sent: Sunday, April 14, 2013 1:50 PM
To: Burleigh, Scott C (313B)
Cc: Elwyn Davies; dtn-security

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

5050 allows any node to reassemble fragments. =A0So, if fragmentation occur= s before security blocks are added, any subsequent node may then reassemble= the bundle.

Additionally, hop-by-hop ciphersuites may have intermediate non-security aw= are nodes. =A0These can potentially fragment/reassemble, creating the same = overlapping fragmentation path/security path scenarios.

The example I sent out earlier in response to Peter Lovell is still a possi= bility if you have a PIB ciphersuite that uses two blocks (one before the p= ayload and one after). =A0BIBE does mitigate this, since we can use the &qu= ot;DO_NOT_FRAGMENT" flag whenever we add a two block PIB, and then enc= apsulate. =A0Once we've encapsulated, we can fragment again.

There's a problem with enforcing the one logical security block of each= type/target per bundle rule if a bundle is reassembled by an intermediate = node. Security blocks may have been applied to different fragments which ar= e then recombined in such a way that there is more than one logical securit= y block of the same type/target. =A0These may apply to overlapping payload = regions, or even the same payload region (depending on how the recombining = node handles receiving duplicate fragments over different links).

These are the cases I've thought of. =A0I'm nervous that there'= s enough complexity in the intersection of fragmentation/encapsulation/BSP = that it's hard to be confident that all the possible combinations will = work correctly.

- Amy


On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott C = (313B) <scott.c.burleig= h@jpl.nasa.gov<mailto:scott.c.burleigh@jpl.nasa.gov>> wrote:
Amy, I certainly agree on the potential for Bad Things happening when fragm= entation and security aren't cleanly nested. =A0Can you say a little mo= re about how the proposed new BSP draft's support for security sources = could expose nodes to these problems?

Scott
________________________________
From: dtn-security-b= ounces@irtf.org<mailto:dtn-security-bounces@irtf.org> [dtn-security-bounces@irtf.org<mailto:dtn-security-bounces@irtf.org>] o= n behalf of Amy Alford [aloomis@sarn.or= g<mailto:aloomis@sarn.org>= ;]
Sent: Saturday, April 13, 2013 3:12 PM
To: Elwyn Davies
Cc: dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions.

If you think about a "fragmentation path" similar to a security p= ath, whenever fragmentation paths and security paths overlap (instead of on= e nesting inside the other), Bad Things (TM) are probably going to happen i= n DTN2.

If it's fragment -> add bsp -> defragment -> remove bsp, you&#= 39;re up against the fact that defragmentation doesn't necessarily pres= erve enough info to validate the BSP blocks. =A0Even if it does, DTN2 curre= ntly doesn't recognize that a set of valid BSP blocks that cover the pa= yload are enough to satisfy policy requirements.

If it's add bsp -> fragment -> remove bsp -> defragment, you&#= 39;re obviously sunk because you can't validate the BSP blocks which ap= ply to the whole payload when you only have a fragment. =A0In this case, yo= u obviously need to reconstitute the bundle before you remove the BSP block= s.

This doesn't even touch the headaches involved with multiple BSP instan= ces and multiple fragmentation.

BiB will need to deal with the second case (the easy one - DTN2 will probab= ly handle this with no changes), but avoids the first case because an encap= sulated 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 t= o handle non-security-aware nodes in the middle.




On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies <<= a href=3D"mailto:elwynd@folly.org.uk">elwynd@folly.org.uk<mailto:elwynd@folly.org.uk>> wrote:<= br> 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. =A0I haven't looked in deta= il
into the code, but I suspect that there are some cases in which order
of delivery via the two different paths might lead to =A0the 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<mailto:plovell@mac.com>> wrote:
> =A0 =A0 =A0 =A0 Hi Amy,
>
> =A0 =A0 =A0 =A0 Amy Alford <aloomis@sarn.org<mailto:aloomis@sarn.org>> wrote:
>
> =A0 =A0 =A0 =A0 >Yes, my example was assuming a PIB ciphersuite tha= t used two
> =A0 =A0 =A0 =A0 blocks
> =A0 =A0 =A0 =A0 >(similar to BAB). =A0That case is the most problem= atic, because
> =A0 =A0 =A0 =A0 when the
> =A0 =A0 =A0 =A0 >bundle is fragmented, the two blocks will end up i= n separate
> =A0 =A0 =A0 =A0 fragments.
> =A0 =A0 =A0 =A0 > Otherwise, the correlator collision isn't a p= roblem as long
> =A0 =A0 =A0 =A0 as reassembly
> =A0 =A0 =A0 =A0 >happens at the destination.
>
> =A0 =A0 =A0 =A0 PIB is, in some ways, a more difficult scenario than P= CB. When
> =A0 =A0 =A0 =A0 a bundle with PCB arrives at the security-dest, the pa= yload is
> =A0 =A0 =A0 =A0 decrypted (and other blocks as appropriate) and the PC= B itself
> =A0 =A0 =A0 =A0 is deleted. But some folks want to have PIBs remain ev= en after
> =A0 =A0 =A0 =A0 verification, as evidence I guess. That is messy.
> Leaving PIBs on after verification is problematic anyway, if the PIB > was added after a PCB. =A0Once the PCB reaches it's security
> destination, the PIB is invalid anyhow.
>
>
> =A0 =A0 =A0 =A0 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. =A0I assume you'd still want an up front block to = warn
> nodes that are doing one pass processing that they need to start
> hashing.
>
>
> =A0 =A0 =A0 =A0 >> As you can see, this is a quite involved proc= ess. A couple
> =A0 =A0 =A0 =A0 of things are
> =A0 =A0 =A0 =A0 >> worthy of note:
> =A0 =A0 =A0 =A0 >> 1. correlators are local to their bundle
> =A0 =A0 =A0 =A0 >> 2. a block with a correlator may be encapsula= ted, with PCB
> =A0 =A0 =A0 =A0 for example.
> =A0 =A0 =A0 =A0 >> The original correlator is hidden until decap= sulation
> =A0 =A0 =A0 =A0 occurs (not shown
> =A0 =A0 =A0 =A0 >> above for sake of brevity :)
> =A0 =A0 =A0 =A0 >> 3. reassembly is a very, very complex process= .
> =A0 =A0 =A0 =A0 >>
> =A0 =A0 =A0 =A0 >I was pondering how to support these sorts of case= s (which
> =A0 =A0 =A0 =A0 end up needing
> =A0 =A0 =A0 =A0 >validation and reassembly interleaved somehow). = =A0In thinking
> =A0 =A0 =A0 =A0 about it, I
> =A0 =A0 =A0 =A0 >started running into scenarios that aren't sup= portable. =A0The
> =A0 =A0 =A0 =A0 example I gave
> =A0 =A0 =A0 =A0 >is one (which I think shows that bundles with two = block PIBs
> =A0 =A0 =A0 =A0 need to have
> =A0 =A0 =A0 =A0 >the do not fragment flag set).
> =A0 =A0 =A0 =A0 It may be sufficient to apply the
> =A0 =A0 =A0 =A0 replicate-key-info-in-every-block rule. I don't kn= ow without
> =A0 =A0 =A0 =A0 thinking about it some more.
>
>
> I think it would fix the example I gave. =A0The last fragment would > contain both the leading and trailing PIB blocks. =A0The leading block=
> could be used to match this up with the corresponding fragment (which<= br> > also has a leading PIB block but is missing the trailing one). =A0It > would be a pain in terms of processing, since defragmentation would > need to match up the corresponding fragments by comparing their
> leading PIB blocks.
>
>
>
>
> =A0 =A0 =A0 =A0 >Additionally, in general, if an intermediate node = reassembles
> =A0 =A0 =A0 =A0 fragments
> =A0 =A0 =A0 =A0 >that have had BSP blocks added after fragmentation= , we can't
> =A0 =A0 =A0 =A0 validate. =A0Too
> =A0 =A0 =A0 =A0 >much information is lost on reassembly (even if it= 's done
> =A0 =A0 =A0 =A0 sensibly). =A05050
> =A0 =A0 =A0 =A0 >allows intermediate nodes to reassemble, but doesn= 't mandate
> =A0 =A0 =A0 =A0 a procedure
> =A0 =A0 =A0 =A0 >for reassembling the extension blocks (so it may n= ot be done
> =A0 =A0 =A0 =A0 sensibly).
>
> =A0 =A0 =A0 =A0 It's not just an issue of reassembling/reordering = extension
> =A0 =A0 =A0 =A0 blocks. As the final example shows, any attempt to
> =A0 =A0 =A0 =A0 reassemble-first is doomed to failure because the two = parts
> =A0 =A0 =A0 =A0 were encrypted under different second-stage keys.
>
> =A0 =A0 =A0 =A0 It's clear to me that reassembly of bundles contai= ning
> =A0 =A0 =A0 =A0 security blocks must be done in concert with security<= br> > =A0 =A0 =A0 =A0 processing. This needs to be incorporated into any upd= ate to
> =A0 =A0 =A0 =A0 5050. And, as you say, there are cases that aren't= supportable
> =A0 =A0 =A0 =A0 with the capabilities we now have.
>
> Yes. =A0In general, nodes shouldn't reassemble a bundle if they do= n't
> understand all the extension blocks. =A0BSP aware nodes shouldn't<= br> > reassemble fragments except in concert with security processing.
>
>
>
>
> =A0 =A0 =A0 =A0 Regards.....Peter
>
>
> _______________________________________________
> dtn-security mailing list
> dtn-security@irtf= .org<mailto:dtn-security@ir= tf.org>
> https://www.irtf.org/mailman/listinfo/dtn-security





--047d7b67809ec1c5dd04da92f396-- From scott.c.burleigh@jpl.nasa.gov Wed Apr 17 15:16:15 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 A4D8821F85BC for ; Wed, 17 Apr 2013 15:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 PHeegw5xhheY for ; Wed, 17 Apr 2013 15:16:13 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6908721F85B3 for ; Wed, 17 Apr 2013 15:16:13 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3HMG7Ur005512 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 17 Apr 2013 15:16:07 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.50]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.02.0342.003; Wed, 17 Apr 2013 15:16:08 -0700 From: "Burleigh, Scott C (313B)" To: Amy Alford Thread-Topic: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions. Thread-Index: AQHOKA4AwAq0n0zXUkuQfuDcUCFv7Zi3S36AgB2+HgCAAEOkAP//rp7ygAHM1ICAAEv8d4ADHLaA//+kIWqAAYhsAP//w04D Date: Wed, 17 Apr 2013 22:16:08 +0000 Message-ID: References: <20130320011114.1072992195@smtp.mail.me.com> <20130323005838.947157858@smtp.mail.me.com> <20130323213252.461319491@smtp.mail.me.com> <1365876632.5273.8820.camel@mightyatom> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.114] Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B235BCE6Capembxsp40RESAD_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Cc: dtn-security 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 22:16:15 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B235BCE6Capembxsp40RESAD_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't know of any other extension blocks that would be added to an encaps= ulating bundle that ought to affect the forwarding of the encapsulated (whe= n extracted) -- again, BIBE is acting as a CLA, and we don't normally care = much about what happens to CL protocol PDUs. But maybe somebody else knows= of something I'm missing. Scott ________________________________ From: Amy Alford [aloomis@sarn.org] Sent: Wednesday, April 17, 2013 11:49 AM To: Burleigh, Scott C (313B) Cc: Elwyn Davies; dtn-security Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions. Ok, I hadn't read the age block spec before now. The spec says CLA's should= provide BPAs with information to use in updating the age block. So, you'r= e saying that BIBE is a CLA, so it should pass along info about how long th= e encapsulated bundle was in transit. It would get that information from e= ither the creation timestamp on the encapsulating bundle or the age block a= ttached to the encapsulating bundle. That makes sense. Are there any other extension blocks that may be added t= o an encapsulating bundle that it would be a problem to just throw out? - Amy On Tue, Apr 16, 2013 at 10:44 PM, Burleigh, Scott C (313B) > wrote: I may be wrong, but I think the age extension blocks can still work, just b= ecause BIBE is a CLA. On output via BIBE you'd update the encapsulated bun= dle's age extension block just as if you were sending via TCP, and likewise= on "reception"/extraction. Sure, the encapsulated bundle might expire en = route (before extraction) but that's probably no great problem. You might = use its remaining time to live as the TTL for the encapsulating bundle to g= uard against this. But overall I think it works; am I overlooking somethin= g? Scott ________________________________________ From: Amy Alford [aloomis@sarn.org] Sent: Tuesday, April 16, 2013 5:54 PM To: Burleigh, Scott C (313B) Cc: Elwyn Davies; dtn-security Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions. I like the simplicity of this, but it brings up a concern I had with encaps= ulation. What happens to extension blocks attached to the encapsulating bu= ndle on decapsulation? If they are simply thrown out, the age extension bl= ocks aren't going to work. If we keep them around somehow, then we lose th= e simplicity of this approach. - Amy On Mon, Apr 15, 2013 at 5:16 AM, Burleigh, Scott C (313B) >> wrote: Okay, this may or may not be optimal, but here's how I think the proposed n= ew BSP concepts might handle the fragmentation/security combinations: * The key rule we're working with is that you can never have more than = one occurrence of any single security activity (logical block, device, stru= cture -- essentially, either a single physical block or two cooperating phy= sical blocks) in any bundle bundle. * This implies that no ciphersuite or policy can require that a PIB or = PCB be added to a bundle that is a fragment (that is, a bundle whose payloa= d is a fragment of the payload of some original bundle with the same ID). = That's because the 5050 fragmentation rules require that any extension bloc= k that precedes the payload of a bundle that is to be fragmented must be pr= eserved in the FIRST resulting fragment. That means that it is always poss= ible for a fragment to contain a payload BIB or BCB that pertains to the or= iginal bundle -- not to itself -- and therefore in at least one case the ad= dition of a fragment payload BIB would result in the bundle having two payl= oad BIBs, a violation. * Therefore, in the event that you want to protect a fragmentary payloa= d with a BIB or BCB, the only way to do so is to encapsulate the fragment b= undle in an encapsulating, non-fragmentary bundle whose payload contains th= e fragment -- and then attach a payload BIB and/or BCB that protects the en= capsulating bundle's payload. * So if fragmentation occurs and you then want to add security blocks, = the blocks will be added to encapsulating -- hence non-fragmentary -- bundl= es. So in order for reassembly to happen, all of the bundles encapsulating= the fragments need to be received at the same node. That node then necess= arily has to be able to extract the fragment bundles from the payloads of t= he encapsulating bundles, and at that point you've got the pre-security fra= gments; reassembling the original bundle payload from those fragments shoul= d be straightforward. * Since there are no security destinations in the proposed simplified B= SP spec, (a) the only hop-by-hop ciphersuites are the ones for BABs and (b)= it would be a configuration nightmare (though not impossible, I guess) to = have any non-BAB-capable nodes interposed between two nodes that are BAB ne= ighbors. If you do have a topology where you need any sort of hop-by-hop s= ecurity association other than adjacency, then you encapsulate; the destina= tion of the encapsulating bundle is the intended "next hop" destination, an= d now you're back in a non-problematic topology. I think the same principles address the other cases you identify. I'll admit that all of this encapsulation does seem a little heavyweight, b= ut in its defense I would argue that: * It's a simple mechanism that handles an unlimited range of cases (inc= luding, I think, cases that nobody has thought of yet) in a common, underst= andable way that is completely compatible with RFC 5050. * The overhead of the extra primary block for the encapsulating bundle = can be kept pretty low if you're using CBHE. * The cases we're talking about are entirely plausible for some operati= onal environments, but for the bulk of secure DTN communications activity I= think they are not likely. It makes more sense, to me, to optimize overh= ead for the common case so long as there's still a way to support all of th= e more complex cases. Scott ________________________________ From: Amy Alford [aloomis@sarn.org>] Sent: Sunday, April 14, 2013 1:50 PM To: Burleigh, Scott C (313B) Cc: Elwyn Davies; dtn-security Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions. 5050 allows any node to reassemble fragments. So, if fragmentation occurs = before security blocks are added, any subsequent node may then reassemble t= he bundle. Additionally, hop-by-hop ciphersuites may have intermediate non-security aw= are nodes. These can potentially fragment/reassemble, creating the same ov= erlapping fragmentation path/security path scenarios. The example I sent out earlier in response to Peter Lovell is still a possi= bility if you have a PIB ciphersuite that uses two blocks (one before the p= ayload and one after). BIBE does mitigate this, since we can use the "DO_N= OT_FRAGMENT" flag whenever we add a two block PIB, and then encapsulate. O= nce we've encapsulated, we can fragment again. There's a problem with enforcing the one logical security block of each typ= e/target per bundle rule if a bundle is reassembled by an intermediate node= . Security blocks may have been applied to different fragments which are th= en recombined in such a way that there is more than one logical security bl= ock of the same type/target. These may apply to overlapping payload region= s, or even the same payload region (depending on how the recombining node h= andles receiving duplicate fragments over different links). These are the cases I've thought of. I'm nervous that there's enough compl= exity in the intersection of fragmentation/encapsulation/BSP that it's hard= to be confident that all the possible combinations will work correctly. - Amy On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott C (313B) >> wrote: Amy, I certainly agree on the potential for Bad Things happening when fragm= entation and security aren't cleanly nested. Can you say a little more abo= ut how the proposed new BSP draft's support for security sources could expo= se nodes to these problems? Scott ________________________________ From: dtn-security-bounces@irtf.org> = [dtn-security-bounces@irtf.org>] on b= ehalf of Amy Alford [aloomis@sarn.org>] Sent: Saturday, April 13, 2013 3:12 PM To: Elwyn Davies Cc: dtn-security Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions. If you think about a "fragmentation path" similar to a security path, whene= ver 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 v= alidate 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 s= unk because you can't validate the BSP blocks which apply to the whole payl= oad when you only have a fragment. In this case, you obviously need to rec= onstitute 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 probab= ly handle this with no changes), but avoids the first case because an encap= sulated fragment is not itself a fragment (so it can't be reconstituted unt= il 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 t= o handle non-security-aware nodes in the middle. On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies >= > 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 >> wrote: > 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. > 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 --_000_A5BEAD028815CB40A32A5669CF737C3B235BCE6Capembxsp40RESAD_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I don't know of any other extension blocks that would be added to an= encapsulating bundle that ought to affect the forwarding of the encapsulat= ed (when extracted) -- again, BIBE is acting as a CLA, and we don't normally care much about what happens to = CL protocol PDUs.  But maybe somebody else knows of something I'm miss= ing.

Scott
From: Amy Alford [aloomis@sarn.org]
Sent: Wednesday, April 17, 2013 11:49 AM
To: Burleigh, Scott C (313B)
Cc: Elwyn Davies; dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the = correlator doesn't prevent all fragment collisions.

Ok, I hadn't read the age block spec before now. The spec = says CLA's should provide BPAs with information to use in updating the age = block.  So, you're saying that BIBE is a CLA, so it should pass along = info about how long the encapsulated bundle was in transit.  It would get that information from either the creati= on timestamp on the encapsulating bundle or the age block attached to the e= ncapsulating bundle.  

That makes sense.  Are there any other extension block= s that may be added to an encapsulating bundle that it would be a problem t= o just throw out?
- Amy


On Tue, Apr 16, 2013 at 10:44 PM, Burleigh, Scot= t C (313B) <scott.c.burleigh@jpl.nasa.gov> wrote:
I may be wrong, but I think the age extension blocks can still work, just b= ecause BIBE is a CLA.  On output via BIBE you'd update the encapsulate= d bundle's age extension block just as if you were sending via TCP, and lik= ewise on "reception"/extraction.  Sure, the encapsulated bundle might expire en route (before extraction) but that= 's probably no great problem.  You might use its remaining time to liv= e as the TTL for the encapsulating bundle to guard against this.  But = overall I think it works; am I overlooking something?

Scott
________________________________________
From: Amy Alford [alo= omis@sarn.org]
Sent: Tuesday, April 16, 2013 5:54 PM
To: Burleigh, Scott C (313B)
Cc: Elwyn Davies; dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions.

I like the simplicity of this, but it brings up a concern= I had with encapsulation.  What happens to extension blocks attached = to the encapsulating bundle on decapsulation?  If they are simply thro= wn out, the age extension blocks aren't going to work.  If we keep them around somehow, then we lose the simplicity= of this approach.
- Amy




On Mon, Apr 15, 2013 at 5:16 AM, Burleigh, Scott C (313B)= <sco= tt.c.burleigh@jpl.nasa.gov<mailto:scott.c.burleigh@jpl.nasa.gov>> wrote:
Okay, this may or may not be optimal, but here's how I think the proposed n= ew BSP concepts might handle the fragmentation/security combinations:

  *   The key rule we're working with is that you can never have = more than one occurrence of any single security activity (logical block, de= vice, structure -- essentially, either a single physical block or two coope= rating physical blocks) in any bundle bundle.
  *   This implies that no ciphersuite or policy can require that= a PIB or PCB be added to a bundle that is a fragment (that is, a bundle wh= ose payload is a fragment of the payload of some original bundle with the s= ame ID).  That's because the 5050 fragmentation rules require that any extension block that precedes the payload of a bund= le that is to be fragmented must be preserved in the FIRST resulting fragme= nt.  That means that it is always possible for a fragment to contain a= payload BIB or BCB that pertains to the original bundle -- not to itself -- and therefore in at least one case= the addition of a fragment payload BIB would result in the bundle having t= wo payload BIBs, a violation.
  *   Therefore, in the event that you want to protect a fragment= ary payload with a BIB or BCB, the only way to do so is to encapsulate the = fragment bundle in an encapsulating, non-fragmentary bundle whose payload c= ontains the fragment -- and then attach a payload BIB and/or BCB that protects the encapsulating bundle's payload.   *   So if fragmentation occurs and you then want to add securit= y blocks, the blocks will be added to encapsulating -- hence non-fragmentar= y -- bundles.  So in order for reassembly to happen, all of the bundle= s encapsulating the fragments need to be received at the same node.  That node then necessarily has to be able to extra= ct the fragment bundles from the payloads of the encapsulating bundles, and= at that point you've got the pre-security fragments; reassembling the orig= inal bundle payload from those fragments should be straightforward.
  *   Since there are no security destinations in the proposed si= mplified BSP spec, (a) the only hop-by-hop ciphersuites are the ones for BA= Bs and (b) it would be a configuration nightmare (though not impossible, I = guess) to have any non-BAB-capable nodes interposed between two nodes that are BAB neighbors.  If you do have a topology = where you need any sort of hop-by-hop security association other than adjac= ency, then you encapsulate; the destination of the encapsulating bundle is = the intended "next hop" destination, and now you're back in a non-problematic topology.

I think the same principles address the other cases you identify.

I'll admit that all of this encapsulation does seem a little heavyweight, b= ut in its defense I would argue that:

  *   It's a simple mechanism that handles an unlimited range of = cases (including, I think, cases that nobody has thought of yet) in a commo= n, understandable way that is completely compatible with RFC 5050.
  *   The overhead of the extra primary block for the encapsulati= ng bundle can be kept pretty low if you're using CBHE.
  *   The cases we're talking about are entirely plausible for so= me operational environments, but for the bulk of secure DTN communications = activity I think they are not  likely.  It makes more sense, to m= e, to optimize overhead for the common case so long as there's still a way to support all of the more complex cases.

Scott
________________________________
From: Amy Alford [alo= omis@sarn.org<mailto:aloomis@sarn.org>]
Sent: Sunday, April 14, 2013 1:50 PM
To: Burleigh, Scott C (313B)
Cc: Elwyn Davies; dtn-security

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

5050 allows any node to reassemble fragments.  So, if fragmentation oc= curs before security blocks are added, any subsequent node may then reassem= ble the bundle.

Additionally, hop-by-hop ciphersuites may have intermediate non-security aw= are nodes.  These can potentially fragment/reassemble, creating the sa= me overlapping fragmentation path/security path scenarios.

The example I sent out earlier in response to Peter Lovell is still a possi= bility if you have a PIB ciphersuite that uses two blocks (one before the p= ayload and one after).  BIBE does mitigate this, since we can use the = "DO_NOT_FRAGMENT" flag whenever we add a two block PIB, and then encapsulate.  Once we've encapsulated, we c= an fragment again.

There's a problem with enforcing the one logical security block of each typ= e/target per bundle rule if a bundle is reassembled by an intermediate node= . Security blocks may have been applied to different fragments which are th= en recombined in such a way that there is more than one logical security block of the same type/target. &nb= sp;These may apply to overlapping payload regions, or even the same payload= region (depending on how the recombining node handles receiving duplicate = fragments over different links).

These are the cases I've thought of.  I'm nervous that there's enough = complexity in the intersection of fragmentation/encapsulation/BSP that it's= hard to be confident that all the possible combinations will work correctl= y.

- Amy


On Sat, Apr 13, 2013 at 8:25 PM, Burleigh, Scott C (313B)= <sco= tt.c.burleigh@jpl.nasa.gov<mailto:scott.c.burleigh@jpl.nasa.gov>> wrote:
Amy, I certainly agree on the potential for Bad Things happening when fragm= entation and security aren't cleanly nested.  Can you say a little mor= e about how the proposed new BSP draft's support for security sources could= expose nodes to these problems?

Scott
________________________________
From: dt= n-security-bounces@irtf.org<mailto:dtn-security-bounces@irtf.org> [dtn-securi= ty-bounces@irtf.org<mailto:dtn-security-bounces@irtf.org>] on behalf of Amy Alford [aloomis@sarn.org<mailto:aloomis@sarn.org>]
Sent: Saturday, April 13, 2013 3:12 PM
To: Elwyn Davies
Cc: dtn-security
Subject: Re: [dtn-security] Re(4): Including fragment offset in the correla= tor doesn't prevent all fragment collisions.

If you think about a "fragmentation path" similar to a security p= ath, whenever fragmentation paths and security paths overlap (instead of on= e nesting inside the other), Bad Things (TM) are probably going to happen i= n 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 does= n'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 ob= viously sunk because you can't validate the BSP blocks which apply to the w= hole payload when you only have a fragment.  In this case, you obvious= ly 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 probab= ly handle this with no changes), but avoids the first case because an encap= sulated fragment is not itself a fragment (so it can't be reconstituted unt= il 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 t= o handle non-security-aware nodes in the middle.




On Sat, Apr 13, 2013 at 2:10 PM, Elwyn Davies <elwynd@folly.org.uk&l= t;mailto:elwynd@fo= lly.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 detai= l
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<m= ailto:plovell@mac.com<= /a>>> wrote:
>         Hi Amy,
>
>         Amy Alford <aloomis@sarn.org<mail= to:aloomis@sarn.org>> wrote:
>
>         >Yes, my example was assuming a PIB cip= hersuite that used two
>         blocks
>         >(similar to BAB).  That case is t= he most problematic, because
>         when the
>         >bundle is fragmented, the two blocks w= ill end up in separate
>         fragments.
>         > Otherwise, the correlator collision i= sn't a problem as long
>         as reassembly
>         >happens at the destination.
>
>         PIB is, in some ways, a more difficult sce= nario 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 PI= Bs 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 w= arn
> nodes that are doing one pass processing that they need to start
> hashing.
>
>
>         >> As you can see, this is a quite i= nvolved 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 com= plex process.
>         >>
>         >I was pondering how to support these s= orts of cases (which
>         end up needing
>         >validation and reassembly interleaved = somehow).  In thinking
>         about it, I
>         >started running into scenarios that ar= en't supportable.  The
>         example I gave
>         >is one (which I think shows that bundl= es 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 bl= ock
> could be used to match this up with the corresponding fragment (which<= br> > also has a leading PIB block but is missing the trailing one).  I= t
> 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 interm= ediate node reassembles
>         fragments
>         >that have had BSP blocks added after f= ragmentation, we can't
>         validate.  Too
>         >much information is lost on reassembly= (even if it's done
>         sensibly).  5050
>         >allows intermediate nodes to reassembl= e, 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/reo= rdering extension
>         blocks. As the final example shows, any at= tempt to
>         reassemble-first is doomed to failure beca= use the two parts
>         were encrypted under different second-stag= e keys.
>
>         It's clear to me that reassembly of bundle= s containing
>         security blocks must be done in concert wi= th security
>         processing. This needs to be incorporated = into any update to
>         5050. And, as you say, there are cases tha= t 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-securit= y@irtf.org<mailto:dtn-security@irtf.org>
> https://www.irtf.org/mailman/listinfo/dtn-security





--_000_A5BEAD028815CB40A32A5669CF737C3B235BCE6Capembxsp40RESAD_--