Re: [dtn-security] RE: Bundle Security Protocol: one more item

Stephen Farrell <> Fri, 17 November 2006 16:05 UTC

Received: from ( []) by (8.11.6/8.11.6) with ESMTP id kAHG5WY18425 for <>; Fri, 17 Nov 2006 08:05:32 -0800
Received: from Vams.imx2 ( []) by (Postfix) with SMTP id 30FD36826E; Fri, 17 Nov 2006 16:05:25 +0000 (GMT)
Received: from ([]) by ([]) with SMTP (gateway) id A00B392D836; Fri, 17 Nov 2006 16:05:25 +0000
Received: from [] ( []) by (Postfix) with ESMTP id 271A36826E; Fri, 17 Nov 2006 16:05:25 +0000 (GMT)
Message-ID: <>
Date: Fri, 17 Nov 2006 16:06:19 +0000
From: Stephen Farrell <>
User-Agent: Thunderbird (Windows/20061025)
MIME-Version: 1.0
Cc: Peter Lovell <>, Howard Weiss <>
Subject: Re: [dtn-security] RE: Bundle Security Protocol: one more item
References: <8E507634779E22488719233DB3DF9FF001229708@IMCSRV4.MITRE.ORG>
In-Reply-To: <8E507634779E22488719233DB3DF9FF001229708@IMCSRV4.MITRE.ORG>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A10B392D836
X-AntiVirus-Status: Host:
X-AntiVirus-Status: Action Taken:
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.56.3 VDF=8.1400)
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: DTN Security Discussion <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
List-Archive: <>

Symington, Susan F. wrote:
> I don't understand the replay threat. What do you mean by, "It means an
> attacker could force
> the processing of blocks in PSB's bundles and could replay those"?

Maybe not too big a deal but if its not digested, then a bad guy
can keep modifying this bit on all the bundles he sees emerging
from a forwarded and in that way affect the operation of the DTN,
maybe consuming resources or forcing wrong routes or whatever.

> I agree that we need to put in a statement saying that this bit should
> be masked in the PSB and CB (what about the BAB?) so that it is omitted
> from the mutable canonical form.  I don't believe that this bit should
> be masked in the primary bundle block, since every node is required to
> be able to process this block.

Why on earth would the primary block have such a bit? Since that'd carry
no useful information at all, I've no problem with it being in or out of

The BAB emitter can do whatever it wants to with this. Doesn't matter
since the BAB will be checked before anyone is supposed to get a chance
to muck with any flag so its ok to include this in BAB digesting.