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

Scott Burleigh <Scott.Burleigh@jpl.nasa.gov> Wed, 25 May 2005 16:44 UTC

Received: from nmta2.jpl.nasa.gov (nmta2.jpl.nasa.gov [137.78.160.215]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PGiSV31246; Wed, 25 May 2005 09:44:28 -0700
Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta2.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4PGiLdj008004; Wed, 25 May 2005 09:44:21 -0700
Received: from [137.79.22.227] (dhcp-79-22-227.jpl.nasa.gov [137.79.22.227]) by xmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4PGiKwp031984; Wed, 25 May 2005 09:44:21 -0700
Message-ID: <4294AB20.2000301@jpl.nasa.gov>
Date: Wed, 25 May 2005 09:43:12 -0700
From: Scott Burleigh <Scott.Burleigh@jpl.nasa.gov>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org, 'Howard Weiss' <howard.weiss@sparta.com>
Subject: Re: [dtn-dev] 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="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: dhcp-79-22-227.jpl.nasa.gov [137.79.22.227]
X-Source-Sender: Scott.Burleigh@jpl.nasa.gov
X-AUTH: Internal IP
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 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.

Scott