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

Stephen Farrell <> Wed, 25 May 2005 09:53 UTC

Received: from ( []) by (8.11.6/8.11.6) with ESMTP id j4P9rAV28297 for <>; Wed, 25 May 2005 02:53:10 -0700
Received: from Vams.smtp3 ( []) by (Postfix) with SMTP id 3CB5414C050; Wed, 25 May 2005 10:52:59 +0100 (IST)
Received: from ([]) by ([]) with SMTP (gateway) id A00375E7782; Wed, 25 May 2005 10:52:58 +0100
Received: from [] ( []) by (Postfix) with ESMTP id D5FA114C04A; Wed, 25 May 2005 10:52:57 +0100 (IST)
Message-ID: <>
Date: Wed, 25 May 2005 10:57:03 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Susan F. Symington" <>
Cc:, "'Howard Weiss'" <>
Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.730)
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Action Taken:
X-AntiVirus-Status: Host:
X-AntiVirus-Status: MessageID = A10375E7782
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: DTN Security Discussion <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
List-Archive: <>

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.)


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.