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

Scott Burleigh <> Wed, 25 May 2005 16:44 UTC

Received: from ( []) by (8.11.6/8.11.6) with ESMTP id j4PGiSV31246; Wed, 25 May 2005 09:44:28 -0700
Received: from ( []) by (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4PGiLdj008004; Wed, 25 May 2005 09:44:21 -0700
Received: from [] ( []) by (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4PGiKwp031984; Wed, 25 May 2005 09:44:21 -0700
Message-ID: <>
Date: Wed, 25 May 2005 09:43:12 -0700
From: Scott Burleigh <>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC:,, "'Howard Weiss'" <>
Subject: Re: [dtn-dev] Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: []
X-AUTH: Internal IP
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: DTN Security Discussion <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
List-Archive: <>

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.
I started off with an SDNV design that worked like this, years ago, and 
can't remember why I moved away from it in the early LTP specs; maybe 
because at that time I wanted to have a sign bit int the discriminator 
as well, and that didn't leave enough bits in the high-order nibble to 
encode the length.  (Or because we wanted to encode the encryption keys 
themselves as SDNVs, since they're numbers, and this approach didn't 
support long enough numbers.)  Anyway, I like this approach but have one 
caveat to offer: you actually can only have a maximum of 8 bytes 
following the discriminator, not 9:

Length bits      Indicated length
-----------      ----------------
000                  1
001                  2
010                  3
011                  4
100                  5
101                  6
110                  7
111                  8

So the maximum value your number can have is (2**68 - 1).

>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?)
Actually only 68 bits.

>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).
I agree with Stephen that it's actually not all that tough to keep 
SDNV-8 vs SDNV-16 straight, but I too am happy with this approach if 
it's our consensus.