[dtn-security] SDNV

John S Segui <John.S.Segui-119079@jpl.nasa.gov> Tue, 07 June 2005 21:29 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 j57LTZV04553 for <dtn-security@mailman.dtnrg.org>; Tue, 7 Jun 2005 14:29:35 -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 j57LTUoT001205 for <dtn-security@mailman.dtnrg.org>; Tue, 7 Jun 2005 14:29:30 -0700
Received: from jpl.nasa.gov (eis-msg-065.jpl.nasa.gov [137.78.160.102]) by xmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j57LTTN2027074 for <dtn-security@mailman.dtnrg.org>; Tue, 7 Jun 2005 14:29:30 -0700
Received: from [137.78.160.72] (Forwarded-For: [128.195.80.241]) by mailhost4.jpl.nasa.gov (mshttpd); Tue, 07 Jun 2005 14:29:29 -0700
From: John S Segui <John.S.Segui-119079@jpl.nasa.gov>
To: dtn-security@mailman.dtnrg.org
Message-ID: <4253247634.4763442532@jpl.nasa.gov>
Date: Tue, 07 Jun 2005 14:29:29 -0700
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004)
MIME-Version: 1.0
Content-Language: en
X-Accept-Language: en
Priority: normal
Content-Type: text/plain; charset=windows-1252
Content-Disposition: inline
X-Source-IP: eis-msg-065.jpl.nasa.gov [137.78.160.102]
X-Source-Sender: John.S.Segui-119079@jpl.nasa.gov
X-AUTH: Internal IP
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id j57LTZV04553
Subject: [dtn-security] SDNV
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/>

I am currently working on a DTN simulation project and have read the interesting email exchanges regarding SDNVs. First, I would like to say that I agree with the current push to unify SDNV-8 and SDNV-16. However, while the proposed SDNV nicely allows for relatively large length fields, it has an upper limit in length. So my question is: is there any reason SDNV should not handle variable length fields of all sizes?

One method for handling infinitely long fields is to nest SDNVs. For instance, make bit two of the SDNV discriminant byte signify whether the SDNV nests another SDNV. In this case, the “root” SDNV follows whatever agreed upon standard for root SDNV encoding but its numerical value represents the length (in bits) of the *length* field in the nested SDNV (e.g. SDNV{SDNV}, SDNV{SDNV{SDNV}}, etc.). This is somewhat similar to the proposed method of encoding the length of the following field inside an SDNV, but has the added benefit, through nesting, of allowing infinite length; thus avoiding the Y2.1K bug.

An alternative (suggested by a co-worker) is to chain SDNVs together. For instance, let bit two of the SDNV’s discriminant byte signify whether the field overflowed into another SDNV.

In conclusion, there appears no reason why we can’t have a standard fully scalable data type to handle all variable length fields, including ever-growing crypto keys. Also, neither suggested method seems more complex or simpler than the current method. Comments?

John SeGui