[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
- [dtn-security] BSP draft issues Peter Lovell