RE: [dtn-security] 00 version of the Bundle Security Protocol Spec.

"Susan F. Symington" <susan@mitre.org> Wed, 25 May 2005 15:37 UTC

Received: from smtp-bedford.mitre.org (smtp-bedford-x.mitre.org [192.160.51.76]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PFb1V30618 for <dtn-security@mailman.dtnrg.org>; Wed, 25 May 2005 08:37:01 -0700
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id j4PFb1232703 for <dtn-security@mailman.dtnrg.org>; Wed, 25 May 2005 11:37:01 -0400
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 0068BBEFB for <dtn-security@mailman.dtnrg.org>; Wed, 25 May 2005 11:37:00 -0400 (EDT)
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.28.8]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id j4PFb0N32639; Wed, 25 May 2005 11:37:00 -0400
Message-Id: <200505251537.j4PFb0N32639@smtp-bedford.mitre.org>
Received: from mm122433-pc.mitre.org (128.29.14.10) by mailhub2.mitre.org with SMTP id 12460727; Wed, 25 May 2005 11:36:53 -0400
From: "Susan F. Symington" <susan@mitre.org>
To: 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>
Cc: dtn-security@mailman.dtnrg.org, 'Howard Weiss' <howard.weiss@sparta.com>
Subject: RE: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Date: Wed, 25 May 2005 11:36:50 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-reply-to: <42944BEF.7090007@cs.tcd.ie>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-index: AcVhD4mMCAQCrOSBS5CFH9DFMRpoZwAKwZxQ
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/>

Stephen,

1. One of the decisions that was made at the Berkeley meetings last week was
that the dictionary header would contain all endpoint ids (EIDs) that appear
in the bundle header, including the four in the primary bundle header, any
security-related EIDs, any EIDs used in a source route header, etc.

I understand your point that the security EIDs are only present in the
security headers if they are different from the source and destination EIDs.
At first I agreed with you that there would therefore be no gain in using
the dictionary header for the security EIDs. However, after thinking about
it I think that it makes sense to use the dictionary header, as decided. For
one thing, a security EID might be the same as a report-to EID. Furthermore,
if a source route header does eventually get defined, a security source or
destination may very well be the same as an EID in the source route. So, I
think there may be good reason to have the PSH-security-source and other
security fields be offsets into the dictionary header than self-contained
SDNVs.

2. Also according to last week's discussions, EIDs will be represented as a
pair of two-byte offsets in the dictionary: one byte for scheme and 1 byte
for SSP (Scheme-specific-part). If we do use the dictionary then is there
still something wrong with the encoding?  I'm not sure I see it. I don't
think there is both and offset and length to mark the start and end of each
string in the dictionary.  I believe that we are using only offsets, with
the end of each string being determined by the start of the next. (Now that
I think about it, this may be a pain (but still doable) if the offsets are
coming from lots of different headers, and not just the primary bundle
header, but that's not a security issue; its an issue of how to structure
the pointers into the dictionary header.) If there is still something wrong
with the encoding, can you please explain it?

3. Even if there is nothing incorrect about the current encoding, it seems
like we will want to make the ciphersuite field bigger. Do you want to do it
now?

-susan


*****************************************************************
PLEASE NOTE: The exchange for Susan Symington's work numbers has changed
from "883" to "983". So, her new office contact information is now:
 
703-983-7209 (voice)
708-983-7142 (fax)
 
Please make a note of this change. Thanks!
******************************************************************

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
Sent: Wednesday, May 25, 2005 5:57 AM
To: Susan F. Symington
Cc: dtn-security@mailman.dtnrg.org; 'Howard Weiss'
Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.


Hi Susan,

I think that this is fine to go, but I believe there
was one change discussed last week that might be
worth getting into the -00 version, since as currently
written the encoding doesn't quite work;-)

The current text uses 3 bits of the ciphersuite ID to
indicate presence/absence of the of src/dest/parms.

It appears (from last week's chats) that each of these is
better encoded as SDNVs contained in the BAH,PSH or CH
(since src/dest are only present when not the same as
something already present/known, so there's no major
gain in using the dictionary header). Given that, then
we can use '00'H to indicate absence at the cost of 3
bytes, but if we're adding a BAH,PSH or CH the overall
cost is probably so high that the additional 3 bytes
are acceptable.

That also solves the ciphersuite ID-size issue
since 5 bits isn't really enough, but 8 bits
probably is.

If the 3 byte overhead (call that plan A) isn't
acceptable, then I'd suggest we try plan B:

a) make the change to use SDNV-8 for src & dest and
    not use the dictionary header for these,
b) make the ciphersuite ID a 16-bit field, with the
    top three bits used for presence/absence of
    src/dest/parms, with maybe another 3 bits
    reserved and a 10-bit ciphersuite ID.

That'd involve a 1-byte overhead on all messages,
but makes messages that contain a src, dest &
parms a byte bigger than otherwise.

(I don't mind which plan we go with for now. I
suppose plan B is very slightly better since we
get those "reserved" bits:-)

All the changes for this are contained in section
3.1 since later sections always (hopefully) talk
about the fields being present/absent without getting
into encoding details.

So, if you've time before posting, I think it'd be
worthwhile, but as I say, its ok as-is for a -00 IMO.
(If you're stuck for time but want the change, you
can fire over the xml and I'll do the editing.)

Regards,
Stephen.

PS: The reason the current encoding doesn't work is that
as I understand it the "natural" encoding of endpoint
IDs can use the dictionary header so as written we're
missing some offset/length field to allow the decoder
to spot the end of the src field/start of the dest field
when both are present.