SDNV-new (was: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 25 May 2005 15:45 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 j4PFjOV30753; Wed, 25 May 2005 08:45:24 -0700
Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 71C6614C04D; Wed, 25 May 2005 16:45:18 +0100 (IST)
Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A01D505B68D; Wed, 25 May 2005 16:45:18 +0100
Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id 48F2014C04D; Wed, 25 May 2005 16:45:18 +0100 (IST)
Message-ID: <42949E83.9050000@cs.tcd.ie>
Date: Wed, 25 May 2005 16:49:23 +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: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org
Subject: SDNV-new (was: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.)
References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu>
In-Reply-To: <20050525152006.GA7633@pisco.cs.berkeley.edu>
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 = A11D505B68D
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/>

Michael,

I guess this could work ok. Whether its better or worse
than sdnv-8/sdnv-16 depends on the frequency with which
we're encoding values in the range 4096-65535, and of
course, my code currently does the -8/-16 thing, so if
we're making this change, we'll want to do it in LTP
at the same time.

Also - can you give some more examples of values
and how they're encoded - the description is a bit
opaque.

I don't think its really harder to code up use of
sdnv-8 or -16 though, nor are coders likely IMO to
get confused between these as long as we don't
oscillate between 'em at specification time.

All in all, I'd be for not changing since I've got
code, but, I've no problem changing to this if
that's the concensus.

Cheers,
Stephen.

Michael Demmer wrote:

> One thing that may be relevant to the security discussion (and to
> dtn-dev in general) is that I think we should use a different SDNV
> format than the ones described in the LTP spec (i.e. neither SDNV-8
> nor SDNV-16).
> 
> Here's my proposal:
> 
> If the value to be encoded is <= 127, then the high-order bit of the
> discriminator is set to zero and the remaining 7 bits encode the
> value. This is unchanged from the existing SDNV-8 format.
> 
> If the value is larger than 127, then the high-order bit of the
> discriminator is set to one, the next three bits indicate how many
> length bytes there are, and the next four bits encode the high-order
> nibble of the length value. Since there must be at least one
> subsequent byte to encode the length (implied since the high order bit
> is one), then we can use the three bits to indicate 1-9 bytes of
> length that follow.
> 
> For some concreteness, the value ranges and number of bytes needed to
> encode them are:
> 
> 0       - 127		1 byte
> 128     - 4095		2 bytes
> 4096    - 1048675	3 bytes
> 1048576 - 268435455	4 bytes
> ...
> 
> The attractive thing to me about this is that since we're going to use
> one of these to encode the length of each header, then it's likely
> that most of the time, either one or two bytes will do. In contrast,
> an SDNV-8 requires three bytes (one discriminator and two length) for
> all values between 256 and 65536. So really, what we're talking about
> is the range between 256 and 4096, which actually seems pretty likely
> to occur.
> 
> Now, as I can see it, the only drawback of this approach versus either
> the SDNV-8 or SDNV-16 is that it has only 4 + (9 * 8) = 76 bits for
> the length encoding. This seems more than sufficient for any expected
> value, as the maximum value is 7.5 x 10^22, which is big enough that I
> don't even know the word for it. (Out of curiosity, does anyone know
> if there is a prefix like peta- or tera- for that size number?)
> 
> Finally, while in some cases, it can be argued that using one of the
> other encodings may save a byte in the average case, for
> implementation and specification clarity, I would advocate that all
> bundle protocols that use SDNVs should use the same one (this one).
> 
> -m
> 
> _______________________________________________
> dtn-security mailing list
> dtn-security@mailman.dtnrg.org
> http://mailman.dtnrg.org/mailman/listinfo/dtn-security
> 
>