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

Michael Demmer <demmer@cs.berkeley.edu> Wed, 25 May 2005 15:20 UTC

Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PFK6V30452; Wed, 25 May 2005 08:20:06 -0700
Received: from demmer by pisco with local (Exim 4.50) id 1Daxfy-0003qz-D3; Wed, 25 May 2005 08:20:06 -0700
Date: Wed, 25 May 2005 08:20:06 -0700
From: Michael Demmer <demmer@cs.berkeley.edu>
To: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org
Cc: "Susan F. Symington" <susan@mitre.org>, 'Howard Weiss' <howard.weiss@sparta.com>
Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Message-ID: <20050525152006.GA7633@pisco.cs.berkeley.edu>
References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <42944BEF.7090007@cs.tcd.ie>
User-Agent: Mutt/1.4.2i
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/>

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