[dtn-security] BSP draft issues

"Peter Lovell" <peter.lovell@sparta.com> Wed, 25 April 2007 20:42 UTC

Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l3PKgQY09699 for <dtn-security@mailman.dtnrg.org>; Wed, 25 Apr 2007 13:42:27 -0700
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l3PKgPTi020061 for <dtn-security@mailman.dtnrg.org>; Wed, 25 Apr 2007 15:42:25 -0500
Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l3PKgPUn006966 for <dtn-security@mailman.dtnrg.org>; Wed, 25 Apr 2007 15:42:26 -0500
Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 16:42:25 -0400
From: "Peter Lovell" <peter.lovell@sparta.com>
To: <dtn-security@mailman.dtnrg.org>
Date: Wed, 25 Apr 2007 16:42:24 -0400
Message-Id: <20070425204224.1395967896@127.0.0.1>
X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) <http://www.ctmdev.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Apr 2007 20:42:25.0336 (UTC) FILETIME=[3B431380:01C7877A]
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Wed, 25 Apr 2007 15:42:25 -0500 (CDT)
Subject: [dtn-security] BSP draft issues
Sender: dtn-security-admin@mailman.dtnrg.org
Errors-To: dtn-security-admin@mailman.dtnrg.org
X-BeenThere: dtn-security@mailman.dtnrg.org
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: dtn-security@mailman.dtnrg.org
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Post: <mailto:dtn-security@mailman.dtnrg.org>
List-Help: <mailto:dtn-security-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-security/>

Working through the notes from Howie's Big Red Pen, I come across a
couple of not-quite-editing questions. I'm sure I'll find more :)

Anyhow, we might be able to deal also with these before Dublin so please
let me have your opinions.


----------------
The discussion of confidentiality in section 2.4 makes mention of a way
to collect several blocks together and encrypt them as a single clump.
Do we really want to allow this, or should we have blocks encrypted on a
one-to-one basis? Because of the block-sequence issues, I would like to
remove this "collection" and have it one-to-one only.

There may have been a size-efficiency reason for doing the collection
but now we have EID-references that's much better.

------------------
In section 3.2.2 on mutable canonicalization, there's a discussion about
what's included and what isn't. In the part about the payload, it says
that we include the "block was forwarded without being processed" flag
because no-one should ever set it, as all nodes must be able to process it. 

I'm not sure that is really true. Maybe the flag isn't set, but it's not
always possible to "process" the payload block. It might be an admin
record, or encrypted, or maybe something else. 

I don't want to get into the issue of what might or might not happen to
that bit, as it's more properly a bundle protocol issue rather than BSP.
But unless someone has an objection, I'd like to treat the bit in
payload flags the same way we do for extension blocks - regard it as
mutable and exclude it from canonicalization.

------------------


Thanks.....Peter