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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 25 May 2005 09:53 UTC

Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4P9rAV28297 for <dtn-security@mailman.dtnrg.org>; Wed, 25 May 2005 02:53:10 -0700
Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 3CB5414C050; Wed, 25 May 2005 10:52:59 +0100 (IST)
Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A00375E7782; Wed, 25 May 2005 10:52:58 +0100
Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id D5FA114C04A; Wed, 25 May 2005 10:52:57 +0100 (IST)
Message-ID: <42944BEF.7090007@cs.tcd.ie>
Date: Wed, 25 May 2005 10:57:03 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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" <susan@mitre.org>
Cc: dtn-security@mailman.dtnrg.org, "'Howard Weiss'" <howard.weiss@sparta.com>
Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org>
In-Reply-To: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org>
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: smtp3.tcd.ie
X-AntiVirus-Status: MessageID = A10375E7782
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,

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.