Re: [dtn-security] A comment on BSP draft -03

"Peter Lovell" <peter.lovell@sparta.com> Fri, 20 April 2007 17:22 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 l3KHMmY04903 for <dtn-security@mailman.dtnrg.org>; Fri, 20 Apr 2007 10:22:48 -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 l3KHMlSO029530; Fri, 20 Apr 2007 12:22:47 -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 l3KHMl6Y015896; Fri, 20 Apr 2007 12:22:48 -0500
Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 13:22:47 -0400
From: Peter Lovell <peter.lovell@sparta.com>
To: dtn-security@mailman.dtnrg.org, Susan <susan@mitre.org>
Cc: Peter Lovell <peter.lovell@sparta.com>
Subject: Re: [dtn-security] A comment on BSP draft -03
Date: Fri, 20 Apr 2007 13:22:45 -0400
Message-Id: <20070420172245.2084852048@127.0.0.1>
In-Reply-To: <8E507634779E22488719233DB3DF9FF001752B28@IMCSRV4.MITRE.ORG>
References: <8E507634779E22488719233DB3DF9FF001752B28@IMCSRV4.MITRE.ORG>
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: 20 Apr 2007 17:22:47.0366 (UTC) FILETIME=[83C52660:01C78370]
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Fri, 20 Apr 2007 12:22:47 -0500 (CDT)
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/>

Hi Susan,

On Fri, Apr 20, 2007, Symington, Susan F. <susan@mitre.org> wrote:

>
>1. The EID references could contain ZERO, one or two EIDs.

That's true. I guess I was thinking of the reference code implementation
which omits the field entirely if there are no entries.


>2. I dont' think you should call it bit 6.  Just call it by the flag
>name, in case the flags change place sometime in the BP.

I had suggested that BP include short names for these, in addition to
the very-long-winded-descriptive-labels-which-lose-people's-attention-as-
they-read-to-the-end. I'll catch this next time around.


>3. I don't think that using only the ordering of the EIDs is
>sufficient.  What if only one EID is present.  How does the node know
>whether this is the security-source or the security-destination? I
>think we need some other indicator to be able to tell the difference. 

This was a KISS call on my part when we were doing the suggestion. The
only extension blocks with two EIDs are security ones, and we already
have flags in the ciphersuite field to say which are present. It's like
moving those fields from the block-specific-data into the preamble --
the same rules apply. If there are two in the list, it's sec-source then
sec-dest just as it was previously in the block data. If there's only
one, the flags in ciphersuite tell you which, and the other is null,
just as it was previously. If the count is zero then they're both null.

No other blocks presently have more than one EID, so the issue does not
come up elsewhere. If/when new blocks are defined with more, they'll
have to include some way to deal with this.

I was mindful of this issue during the discussions, and tried to get
some way to simply define a null EID. That, of course, is not the same
as "dtn:none" but more like the usage in BSP where, for example, a null
sec-dest means that sec-dest is the bundle destination. Obviously this
is not at all the same as "dtn:none" as a destination.

My suggestion was to include a single NULL byte as the start of the
dictionary. That way, a reference of {0, 0} would be guaranteed to refer
to a null EID. Unfortunately that suggestion was not adopted, so if you
need a null EID in the list then you have to actually create one and add it.

Cheers.....Peter