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

Peter Lovell <plovell@mac.com> Sat, 23 March 2013 21:32 UTC

Return-Path: <plovell@mac.com>
X-Original-To: dtn-security@ietfa.amsl.com
Delivered-To: dtn-security@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 44B3921F8951 for <dtn-security@ietfa.amsl.com>; Sat, 23 Mar 2013 14:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VNTwQJ3VSOlL for <dtn-security@ietfa.amsl.com>; Sat, 23 Mar 2013 14:32:57 -0700 (PDT)
Received: from st11p00mm-asmtp003.mac.com (st11p00mm-asmtpout003.mac.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7DACF21F8B96 for <dtn-security@irtf.org>; Sat, 23 Mar 2013 14:32:57 -0700 (PDT)
Received: from [] (pool-96-241-42-32.washdc.fios.verizon.net []) by st11p00mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-23.01( 64bit (built Aug 10 2011)) with ESMTPSA id <0MK400KR1UIN8V50@st11p00mm-asmtp003.mac.com> for dtn-security@irtf.org; Sat, 23 Mar 2013 21:32:52 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-23_03:2013-03-22, 2013-03-23, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1302030000 definitions=main-1303230253
From: Peter Lovell <plovell@mac.com>
To: Amy Alford <aloomis@sarn.org>
Date: Sat, 23 Mar 2013 17:32:52 -0400
Message-id: <20130323213252.461319491@smtp.mail.me.com>
In-reply-to: <CAB9rx+-kKNEUH0VWA_ffrcHfh59eSAxbgHNXWhkm+BrC44rqWw@mail.gmail.com>
References: <CAB9rx+85HHsNj=EhmsqhCdtY5k=S4p1Jgzz4VsmEC+43ERygWA@mail.gmail.com> <20130320011114.1072992195@smtp.mail.me.com> <CAB9rx+_EK7u8kkDhscBdqnGHYSeoROTSfhNaALZUodMt4em=_Q@mail.gmail.com> <20130323005838.947157858@smtp.mail.me.com> <CAB9rx+-kKNEUH0VWA_ffrcHfh59eSAxbgHNXWhkm+BrC44rqWw@mail.gmail.com>
X-Mailer: CTM PowerMail version 6.1.5b1 build 4653 English (intel) <http://www.ctmdev.com>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable
Cc: dtn-security <dtn-security@irtf.org>
Subject: [dtn-security] Re(4): Including fragment offset in the correlator doesn't prevent all fragment collisions.
X-BeenThere: dtn-security@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." <dtn-security.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-security>
List-Post: <mailto:dtn-security@irtf.org>
List-Help: <mailto:dtn-security-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Mar 2013 21:32:58 -0000

Hi Amy,

Amy Alford <aloomis@sarn.org> wrote:

>Yes, my example was assuming a PIB ciphersuite that used two blocks
>(similar to BAB).  That case is the most problematic, because when the
>bundle is fragmented, the two blocks will end up in separate fragments.
> Otherwise, the correlator collision isn't a problem as long as reassembly
>happens at the destination.

PIB is, in some ways, a more difficult scenario than PCB. When a bundle with PCB arrives at the security-dest, the payload is decrypted (and other blocks as appropriate) and the PCB itself is deleted. But some folks want to have PIBs remain even after verification, as evidence I guess. That is messy.

Is there a specific reason for a two-block PIB?

>> As you can see, this is a quite involved process. A couple of things are
>> worthy of note:
>> 1. correlators are local to their bundle
>> 2. a block with a correlator may be encapsulated, with PCB for example.
>> The original correlator is hidden until decapsulation occurs (not shown
>> above for sake of brevity :)
>> 3. reassembly is a very, very complex process.
>I was pondering how to support these sorts of cases (which end up needing
>validation and reassembly interleaved somehow).  In thinking about it, I
>started running into scenarios that aren't supportable.  The example I gave
>is one (which I think shows that bundles with two block PIBs need to have
>the do not fragment flag set).

It may be sufficient to apply the replicate-key-info-in-every-block rule. I don't know without thinking about it some more.

>Additionally, in general, if an intermediate node reassembles fragments
>that have had BSP blocks added after fragmentation, we can't validate.  Too
>much information is lost on reassembly (even if it's done sensibly).  5050
>allows intermediate nodes to reassemble, but doesn't mandate a procedure
>for reassembling the extension blocks (so it may not be done sensibly).

It's not just an issue of reassembling/reordering extension blocks. As the final example shows, any attempt to reassemble-first is doomed to failure because the two parts were encrypted under different second-stage keys. 

It's clear to me that reassembly of bundles containing security blocks must be done in concert with security processing. This needs to be incorporated into any update to 5050. And, as you say, there are cases that aren't supportable with the capabilities we now have.